Live data from Hacker News

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

ericwbailey.design

221–230 of 236 posts

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

#221
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…

Open ticket is ambiguous in English anyway. It could mean the ticket to which this refers is of type open or click here to view the ticket.

I have a different complaint than most others here and that is that most UIs require me to mentally translate from software developers English to real English. It's no surprise then that translating to a completely different language is difficult and error prone.

Edit: mismatched asterisks.

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

#222
post #73
post #38

Earlier quoted context omitted.

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.

Same for country and date/time/number formats.

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

#223
My first job out of college involved template-based translations for chemical bottle labels (with information printed in English, French, German, Italian, Japanese and Spanish, with different regulations attaching to each language (jurisdictions included the US, Japan, Canada, EU, Germany and UK, each with their own specific requirements). Machine translation was still expensive and unreliable (this was 1991–3) so we had translators build up a phrasal dictionary that we could then apply rules to in order to build up the text that would appear on each label. Thanks to the regulatory regime, there was a lot of care taken in designing the system and with hand-translation of each phrase by actual human translators, no glaring errors.

Looking at after the fact attempts at internationalization, there are lots of pitfalls and it's something that needs to be done intentionally. (I'm still thinking about how to best implement the equivalent of LaTeX's \cref for finl. What works for English, doesn't work for other languages (e.g., in Czech, “in sections 3 and 4“ would be renderered “v sekcich 3 a 4” while “see sections 3 and 4” would be “viz sekce 3 a 4” although “see sections 3–10” should be “viz sekci 3–10”.

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

#224
post #142

Earlier quoted context omitted.

Congratulation: You just opened the Pandora box of locale vs language! My understanding would be that locale should dictate numerical formatting. But one could argue the opposite and also be right.

If we're opening Pandora's boxes... I've got GNOME set up in English, but my region to be the Netherlands. It will helpfully display local dates, but that also results in the month names being in Dutch.

Maybe that's what the Gnome interface limits you to (no idea) but LC_TIME and the timezone are not inherently linked under Linux.

If by "local dates" dates you mean the format rather than timezone then LC_TIME=en_DK will give you English text with RFC3339 YYYY-MM-DD formatting.

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

#225

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”.

> The actual identifier should be something like “Open a ticket (imperative, button)” The identifier should be a GUID with an option for tagging and comments for developers and translators. Other languages depend on other contexts which are not represented here, like multiple forms of "present" tense, or the current time of day. Keying translations on English-language concepts is a bad idea, as a lot of languages are…

That sounds like a nice setup.

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

#226
post #142

Earlier quoted context omitted.

If we're opening Pandora's boxes... I've got GNOME set up in English, but my region to be the Netherlands. It will helpfully display local dates, but that also results in the month names being in Dutch.

Maybe that's what the Gnome interface limits you to (no idea) but LC_TIME and the timezone are not inherently linked under Linux. If by "local dates" dates you mean the format rather than timezone then LC_TIME=en_DK will give you English text with RFC3339 YYYY-MM-DD formatting.

Unfortunately I don't really know what LC_TIME is :) But if I look through the calendar widget that drops down when I click the time in the top bar, is says e.g. that the previous month is called "augustus" and that today is "vrijdag". Looking into my "Region & Language" settings, my language is set to English (United Kingdom), and formats is set to Nederland (Nederlands), which is said to cover numbers, dates and currencies. Especially for currencies I'd prefer my local currency, but I'd prefer for numbers to use the UK system, and not quite sure what I'd like for dates as long as it's not the US system.

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

#227

Earlier quoted context omitted.

Why would anyone pick anything other than: - a Union Jack, because that’s the origin - an American flag, because it’s the largest English speaking nation - or their own flag (e.g. Australian) if the language is English?

(1) You're proposing displaying a Union Jack to users in the Republic of Ireland (2) You have a dependency on the number of states in the US. British people tolerate seeing the US flag, but it implies en-US, rather than en-GB It's much more simple to avoid these issues by using a generic "A/文" symbol

> (1) You're proposing displaying a Union Jack to users in the Republic of Ireland

Yes. They're on a website, not watching an orange march go through their town.

> (2) You have a dependency on the number of states in the US.

Eh?

> British people tolerate seeing the US flag, but it implies en-US, rather than en-GB

Who cares? It's a website.

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

#228

Earlier quoted context omitted.

If anyone in Ireland is offended at the use of a Union Jack to signify the button for English language then they need to grow up. Fast.

I don't know much about Ireland, maybe it's not that sensitive an issue there. So how about this: what's the correct flag to show for Arabic in Israel? Last time I fiddled with some automated kiosk at Ben Gurion airport I noticed they used a Jordanian flag for Arabic. That's an interesting choice, because if I had to guess most of the people choosing Arabic at that kiosk would not choose that as their flag.

They're not choosing their flag, they're choosing a language.

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

#229
post #206

Earlier quoted context omitted.

Agreed. The symbol for pricing could surely be the actual symbol though (€$¥£ etc).

It's not just about the currency, but also the value of the price. To use an example I have on my table right now, German newspapers and magazines usually target Austria and Switzerland as secondary markets and have different prices for each of them. So an issue that's 3.95 € in Germany can be 4.30 € in Austria and 6.30 CHF in Switzerland. Even though Germans and Austrians use the same currency, they don't pay the sa…

Why conflate the choice of language with the choice of currency? If there's a need to differentiate by those countries, give them that choice. If not, don't.

Or you could display everything in Korean to those with a Korean IP even though in some cases it will happen to be an Austrian who'd be thankful to see a German flag (or any flag!) on the screen to help them change the language. Then they can worry about the currency.

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

#230
post #38

Earlier quoted context omitted.

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.

In fact, the first external link in TFA is to a whole website [ http://www.flagsarenotlanguages.com/blog/why-flags-do-not-re... ] apparently dedicated to this.

First example is English:

> How will users from these countries react to an English, British or American flag?

I stopped reading right there because no one cares. If you have users that care then provide them with choices, just don't let them get stuck wandering around a page in Russian or Greek or whatever because you thought someone might be offended by a flag. Perhaps they're offended by crappy websites with no obvious way to change the language? I know I am, show me any flag from any part of the former British empire and let me get on with what I was doing.

Post reply on HN