undefined | Better HN

0 pointsygra4y ago0 comments

That's actually a nice idea in forcing even the default language to be handled by the same workflows, processes, and tools as the other languages. I've found that in a lot of those cases there simply is lots of context missing from the strings that should be translated. If all you get is the English text without any indication of how and where it's used in the UI, you're bound to make such mistakes in the translation.

For example, it took me a while to figure out why Word 2007 in its German version used the word »Gliederung« for the stroke of a shape. But translating »outline« in a word processor to mean »document outline« instead of »shape outline« is actually quite understandable.

Back then I tried thinking about automatic or semi-automatic solutions to get a bit more context for the translator. The trouble is that most UI toolkits make it very hard to impossible to solve this, unless the developer actually knows enough about the problem to always include context and a description. Qt has (had? That was pre-QML, I think) a nice mode in its translator UI where the XML UI description could be used to show the string in its UI context. Windows Forms had a way of changing the form's language and simply replacing all strings directly in the designer (which has the problem that the translator might accidentally destroy all layout). Most things that are used just from source code have no visual way of relating strings to UI at all.

0 comments

smoe4y ago

In most places I worked that used translation systems, all languages where translations including the default one. Within code using message keys like "thing.title", "thing.add_action", "thing.on_save_error", etc or something like that.

I really like this approach because it makes the code and especially templates much more readable. You usually don't care about the verbose form of the text that should be displayed and those type of keys give you just enough information to understand what it is.

Problem is, it makes it harder to outsource the translations, and well, as it is known, naming things is hard.

DougWebb4y ago

Oh, cool. You just reminded me of a feature I had built into my web app many years ago when we implemented translations. We accepted internal commands in our search box, and one of the commands told the app to display the language text identifiers alongside the language text. It was a great mode for developers, QA, and translators. Developers and QA could easily locate text that needed to be put into the language system, and translators could work page by page to find the identifiers they needed to translate.