Hacker News new | ask | show | jobs
by svantex 762 days 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.
1 comments
sandreas 762 days 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
link
svantex 761 days 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.

link