3 ms·

I wonder why translations always tend to need an extra format or framework. Is replacing or customizing translation files after deployment a thing or could it b

I wonder why translations always tend to need an extra format or framework. Is replacing or customizing translation files after deployment a thing or could it be just (generated) compile time CODE in the used language based on a simple common format (like gettext with macros)? I did A LOT of translation work and in the end the best, easiest and fastest solution always was a list / map of key value pairs, where key was a unique translation identifier and the value was the translation in one language optionally having placeholders (e.g. for numbers) combined with a simple macro (best case) / function / method similar to sprintf. Even plural forms should get their own unique identifier - automatic pluralization always failed for my use cases (russian has several different plural forms depending on the context).

svantex 2y ago
Quite so, and in the case of resx, that's exactly what you're getting. A list of key-value-pairs, no support for pluralisation either (as you say, it gets hard. I understand Polish for example is very complex, perhaps Russian is the same?). I never had a problem with resx and .net satellite assemblies and all that as far as the format goes. But it's always been an issue how to involved translators in a way that's both simple for the translators, safe for the quality and as automated as possible in bringing the translations back to the app.
- sandreas 2y ago
  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.

svantex 2y ago

Quite so, and in the case of resx, that's exactly what you're getting. A list of key-value-pairs, no support for pluralisation either (as you say, it gets hard. I understand Polish for example is very complex, perhaps Russian is the same?). I never had a problem with resx and .net satellite assemblies and all that as far as the format goes. But it's always been an issue how to involved translators in a way that's both simple for the translators, safe for the quality and as automated as possible in bringing the translations back to the app.

sandreas 2y ago
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.