Live data from Hacker News

What they don’t tell you when you translate your app

ericwbailey.design

71–80 of 236 posts

Re: What they don’t tell you when you translate your app

#71

Earlier quoted context omitted.

Don't German UI conventions follow the convention of using infinitive verbs for commands normally? ('öffnen' instead of 'öffne'?) [the only exception I know is the adjective "rückgängig" for "undo" ] Though even there your point still stands - they can be easily distinguished from the perfect form ('opened' (geöffnet) vs 'to open' (öffnen) ). So I guess I'm nit-picking a bit.

Native german speaker here. Have no clue about UI conventions nor grammar, but I'd expect either "Öffne Ticket" or "Ticket öffnen". "Öffnen Ticket" is wrong, just as "Ticket öffne". I suppose the Flixbus app was made by native German speakers coding in English language. That would explain why they chose "open ticket" rather than "view ticket" or similar. As some of the parent posts said, you also "open files" here, s…

Oh yes, word order is also a major problem in software translated to German. You can tell when an English speaker programmed something...

It annoyed me more than it should that Word for Mac for years had a menu command "Beenden Word" (Quit Word) where the order of the words was obviously hard coded...

Or how Siri says "In 50 Meter Sie haben Ihr Ziel erreicht." (it should be "In 50 Meter haben Sie Ihr Ziel erreicht")

In English you can just take the sentence "You have arrived at your destination" and prefix it with something like "In 50 yards", and it's a perfectly valid sentence: "In 50 yards you have arrived at our destination". It might sound a bit mechanical, but it's not wrong.

If you do the same in German, it just sounds very confusing and wrong.

Re: What they don’t tell you when you translate your app

#72
I tend to try designing the app with as much culturally-neutral iconography as possible (difficult). ISO icons are useful (although many designers hate them). I also try to leave as much as possible to the platform (Apple platforms). Again, designers tend to hate that. The problem is that every custom element requires both a visible string, and at least one "invisible" one (voiceover). It can get a bit dense. It's nice, if I can rely on the built-in Apple versions.

I've also been caught out by choosing culturally-biased icons and visual elements.

I've used ibabbleon.com, in the past, and I'm told they do a good job. Not too expensive, fast, and technically correct.

Nothing beats having the end-users do the translations, though. I have been able to do this, with some of the open-source stuff that I've done. It can be an ... iterative ... process, though, as they can do things like send you translations with illegal characters, or in formats like UTF-8(BOM).

Re: What they don’t tell you when you translate your app

#73
post #38

Earlier quoted context omitted.

Some sites, like Google, will helpfully change the language depending on your current IP address. Trying to find how to switch to English from say, Korean, when Google surely knows that I'm English and don't speak Korean (I'm reminded of this[1]) should be forced upon the chimps writing their UIs. What's wrong with using national flags? It's so easy for the user, don't designers care about us? [1] https://news.ycombi…

National flags and languages are not a 1:1 map. Some flags have multiple languages, and some languages have multiple flags. And that can be "close enough", until you for example serve English speaking people in Ireland the Union Jack. Both languages and flags can be sensitive topics in certain parts of the world.

Also, often the country and language settings need to be independently modifiable, e.g. for pricing vs. product description.

Re: What they don’t tell you when you translate your app

#74
One nitpick about localization:

If you speak several languages, try setting your device to use one _language_ and keep your locale to US.

Now you can spot which developer understands the difference between a language and a locale and which one doesn't (hint: on large enough apps you'll land on pages using the wrong one, ie determines the language using locale). Or the opposite (watch the UI quote you prices in Euro despite your locale being USD).

Re: What they don’t tell you when you translate your app

#75

One nitpick about localization: If you speak several languages, try setting your device to use one _language_ and keep your locale to US. Now you can spot which developer understands the difference between a language and a locale and which one doesn't (hint: on large enough apps you'll land on pages using the wrong one, ie determines the language using locale). Or the opposite (watch the UI quote you prices in Euro d…

If someone sets the language to (say) French but keeps their locale as English, do you write a thousand as 1,000 or 1.000? What about the reverse case?

Re: What they don’t tell you when you translate your app

#77
post #67

> People may prefer the English experience because they expect the translated version to be inferior Even more, bilingual people exist! A translated version is always worse. With a good human-made translation, it may just be a matter of making things un-Google-able or misrepresenting certain concepts. With an automatic translation, it's usually completely unusable. I'm a native speaker of Dutch. I'm a near-native spe…

Exactly! Ironically, the most Anglo-centric assumption of them all is that people are only fluent in exactly one language. Configuring anything to be truly multilingual as opposed to "in another language" has terrible UX.

Re: What they don’t tell you when you translate your app

#78
post #5

> People may prefer the English experience because they expect the translated version to be inferior As an Italian, I can relate so much to this, because translated apps will happily treat verbs as adjectives and vice versa. A couple example: * Flixbus' app translates "Open ticket" to "Biglietto aperto" (treating "open" as an adjective, not as an imperative verb). Correct translation should be "Apri biglietto". Nothi…

I think the issue is many translation databases just hold the English text and then all the translations. So the entry is “Open ticket” and then you just drop in the translation anywhere that phrase shows up. But sometimes “open” is a verb, sometimes a noun. The actual identifier should be something like “Open a ticket (imperative, button)” and then that phrase has translations, including the English “Open ticket”.

Yup. The “key” for the translation is the English phrase itself. It also makes English text changes weird because you either have to change the key across all languages to match the new English or you leave the key alone and change/add an English “translation” that is the new text.

Personally I think it is better to use a “surrogate key” that isn’t the English text itself.

Re: What they don’t tell you when you translate your app

#79
post #24

Earlier quoted context omitted.

I think the issue is many translation databases just hold the English text and then all the translations. So the entry is “Open ticket” and then you just drop in the translation anywhere that phrase shows up. But sometimes “open” is a verb, sometimes a noun. The actual identifier should be something like “Open a ticket (imperative, button)” and then that phrase has translations, including the English “Open ticket”.

Yep, there's a ton of software that wants to use the english text as the translation key, which leads to all sorts of bad results. Things like Open Ticket used as a verb to create a bug report, or open a bug report, or as an adjective to indicate a bug report is still active. Or similar when ticket means a transportation or entertainment event. If your key is the English text, you can't translate those three usages d…

I was using Qt recently and saw that example code did that English keying. It's good that they're promoting creating translatable UIs, but I don't know if it's the right thing to do if they're encouraging people to do it by using English text as the key.

Re: What they don’t tell you when you translate your app

#80

One nitpick about localization: If you speak several languages, try setting your device to use one _language_ and keep your locale to US. Now you can spot which developer understands the difference between a language and a locale and which one doesn't (hint: on large enough apps you'll land on pages using the wrong one, ie determines the language using locale). Or the opposite (watch the UI quote you prices in Euro d…

If someone sets the language to (say) French but keeps their locale as English, do you write a thousand as 1,000 or 1.000? What about the reverse case?

locale defines decimal formatting
Post reply on HN