3 ms·

That may be the case, but resx is a quite bloated XML format for a simple key value pair listing. Besides that, resx is yet another format for the same thing.

That may be the case, but resx is a quite bloated XML format for a simple key value pair listing. Besides that, resx is yet another format for the same thing. I think the solution is quite simple: - One unified key value pair format (for translators and GUI tools) - One intermediate format that is programming language specific (it could be generated code or highly integrated formats like resx) - A simple tool that can transliterate between those two formats Workflow example: - Export a unified format file from resx with placeholders for the translations - Translators: Here you go, use your GUI tools on this - Get back the translated unified format - Import a unified format file to resx

svantex 2y ago
Well, that's what the setup I have does, almost. If you consider .po/.pot to be a unified format file. I extract the original texts, comments and internal names from the resx into a .pot (Portable Object Template). This is then sent to a translator-centric web site service. A translated file is then exported, although I export it as a .po file, and then use a library and a little bit of my own code to implement an IStringLocalizer. As someone said elsewhere, more and more services do support .resx directly, so I could consider skipping the .po handling in my code, and just use the .resx. As for bloat, I find the .po format to be quite bloated, with it's use of the full texts as keys in each and every translation. I don't really like that, but in practice it appears to be working well and has been for many years. Then again, the obvious choice today would be json.