A Localization Horror Story: It Could Happen To You (1999) | Hacker News Reader

A Localization Horror Story: It Could Happen To You (1999)

search.cpan.org

37 pointspolm2320 comments

Localisation is one of several cases where I've come to the conclusion that frameworks that are supposed to help you end up doing more harm than good. What you really want is to express a bunch of functions that conform to a common interface: you pass in a number of files and a number of directories and you get back a user-facing string.

But we already have a very well-optimised system for expressing functions: whatever programming language we're actually working in. We already have the concept of a bundle of related functions that implements a particular polymorphic interface: a class.

Make an interface that represents what you need each translation - that is, language implementation - to provide. Write implementations of that interface, in collaboration with your translators (if your language doesn't let you write code in a way that a reasonably intelligent translator can read and verify, if not write, get a better language). Less awkward than gettext, and far more effective.

Many translators aren't comfortable with editing source code. They want to get a file, e.g. in XLIFF format [1], which they can then load into their translation management system, and then use a GUI or web based tool to enter the translations for each string, and then at the end export the updated file and send it back to the developers. Plus, the translation management system makes it easy to keep track of progress (what % of strings have been translated so far), automate review (require each translation to be signed off by a second translator), etc – but, translation management systems can't import/export source code, but they often can import/export message catalogs.

[1] https://en.wikipedia.org/wiki/XLIFF

I wonder if you could create some kind of domain-specific language that would be easier for a translator to interact with, without said translator needing to understand the nuances of the underlying programming language, or deal with anything more complicated than non-nested if/case statements.

The ICU project does that: http://userguide.icu-project.org/formatparse/messages

None of my translator friends has had anything good to say about those tools, though admittedly I know a small skewed sample of more technically-inclined types.

I wonder, are issues like these easier to manage with sentences structured like: “Number of foos scanned: 1”, or “Number of foo/bar scanned: 3/10”? I know it at least makes the plural issue go away for English (as both 1/2 work with a colon).

This is a popular trick, but it doesn't work well with more than one parameter, and reads unnatural in many languages anyway.

It is equally unnatural in all languages, therefore the best possible solution. It is worse than many impossible solutions, but they are, you know, impossible.

And, people have become used to it, so for younger people it seems perfectly normal; and everybody who hates it either doesn't use computers, or will die soon enough.

Since it does not actually hasten their death (or deaths -- a fine point), it is the clear winner.

>It is equally unnatural in all languages, therefore the best possible solution.

I don't see what logic connects statements before, and after "therefore", sorry.

Emphasis is on the word "possible". Once you rule out all the impossible solutions, the solitary one that remains is definitively the best.

Other solutions do exist, and it certainly means they are possible. There are likely solutions which not yet written in code, but possible anyway.

Apple’s Stringsdict approaches this exact problem, though unfortunately first-party documentation is limited. It’s a pretty mature mechanism and yes pretty freely within apple’s own frameworks. See “plural and gender support” here:

https://www.objc.io/issues/9-strings/string-localization/#Pl...

It seems like Mozilla Fluent is a more sophisticated and modern attempt to solve these problems. It is still very new but works with browser and node javascript.

2015: https://news.ycombinator.com/item?id=8890935

2011: https://news.ycombinator.com/item?id=2095334

See also the "Plural-Forms" documentation in the GNU gettext manual – https://www.gnu.org/software/gettext/manual/html_node/Plural... – which also talks about supporting languages with much more complex pluralisation rules than English (particularly Slavic languages and Arabic)

This is the ICU solution to it: http://userguide.icu-project.org/formatparse/messages

I'm pleasantly surprised whenever a website translated from English knows when "comment" or "reply" is a verb or a noun.

(1999)

Added. Thanks!

Reply on news.ycombinator.com