> People may prefer the English experience because they expect the translated version to be inferior<p>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:<p>* Flixbus' app translates "Open ticket" to "Biglietto aperto" (treating "open" as an adjective, not as an imperative verb). Correct translation should be "Apri biglietto". Nothing bad, just unnecessarily confusing (what is an "open ticket"? As opposed to a "closed" one?)<p>* EasyJet's app does the reverse and makes it much worse. The English version likely says something like "Gate close: xx:xx (am|pm)". They mis-translated this as "Gate chiuso: xx:xx", which actually means "Gate <i>has closed</i>", even though the gate is still open. So you get a small heart attack, notice the actual closing time, curse the translators, and go on with your life.
> <i>People may prefer the English experience because they expect the translated version to be inferior</i><p>There are multiple comments here about how it usually <i>is</i> inferior.<p>But even when it's <i>not</i>, there can still be reasons to stick to English.<p>I've done a lot of work with Brazilian graphic designers, and they all use Photoshop/Illustrator in English -- the Portuguese version is essentially "unusable". Not because the translations are necessarily bad, but because Photoshop has its own bespoke vocabulary.<p>E.g. what's the difference between "image" size and "canvas" size, between auto "tone" and auto "color", between "crop" and "trim", or between "vibrance" and "saturation"?<p>In layperson English these are essentially synonyms, but mean different things in Photoshop. And if you want to follow <i>any</i> Photoshop tutorial, or communicate with any designer, you need to know these "English" terms, just like every programmer needs to know "if" and "then".<p>Translating adds yet <i>another</i> layer of confusion that hinders more than it helps.<p>Of course, this is specific to professional tools that require training -- it doesn't really apply to consumer software intended for a general audience.
> People may prefer the English experience because they expect the translated version to be inferior<p>No, it is not about expectations. In +95% of cases[1] the localized[2] version is objectively worse, to the point where it often only is possible for me to understand by first translating it back to English.<p>If you give me a localized version first, and don’t give me an obvious way to permanently choose English, I’m likely gone.<p>[1] Mostly excluding the big ones (MS, Apple, etc), but quite often they fail too<p>[2] My first language is one of the smaller European languages (<20M speakers), perhaps bigger languages have higher quality.
One annoying issue with translated apps the author doesn't cover is "googlability", the fact that we often need to google an error message or menu label in order to solve a problem. This leads to a lot of bilingual people running their software in English just in case they need to paste an error message into a search engine.
From IGN's article about the difficulties of game development (<a href="https://www.ign.com/articles/turns-out-hardest-part-making-game-everything" rel="nofollow">https://www.ign.com/articles/turns-out-hardest-part-making-g...</a>):<p>“Planning ahead helps, but nothing will prepare you for German,” [Joe Mirabello] said. “German destroys your best laid plans. German will defeat you. That text field you thought would only ever need a single 10-20 character word? Nope. German has a unique word for that and it’s a hundred and twelve characters long. We even have a native German developer on our team and he refuses to translate our games into German. This is all said tongue-in-cheek, of course, just to illustrate a point, and that is; whatever scaling flexibility you think you’ve planned for in your UI to account for localization? It’s not enough. It’s never enough.”
> People may prefer the English experience because they expect the translated version to be inferior<p>Even more, bilingual people exist!<p>A translated version is <i>always</i> 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.<p>I'm a native speaker of Dutch. I'm a near-native speaker of English. Having a page with both languages interspersed is completely acceptable! Don't "helpfully" translate everything which isn't in the configured language - you're only making things worse.
> A device’s location/IP address isn’t indicative of the language preference of the person using it<p>I really don't understand why this is so popular (google being a major offender). The browser already sends the preferred language(s) as a http header.
All of this is so recognizable, but I'd add one more: Make sure the user has a way to switch the translation back to English.<p>I have some sites showing in, say, Chinese, where even the current language is a Chinese glyph. Nothing on such a page is readable for a non-Chinese speaker. So you get to click around randomly until some menu opens where you see the word 'English' which brings you to a page you can read enough to get to your own language.
Localization is treated as translation job in whole tech world, but in reality it should be a UI/UX design job. Most of localizations are awful even by translation standards though. And not because it lacks some kind of context etc, but nobody just cares – these are done by big agencies using mostly automatic process and with prices racing to the bottom.<p>PS. I have 10+ years experience with open source localization and tried to make it my job at some point. I escaped industry very quickly.
One aspect not entirely covered in the article is when you have a deeply technical piece of software and the dominant vocabularly of the technical field is in English.<p>We get many requests from users of Ardour (a crossplatform digital audio workstation) to disable automatic translation based on their system language setting, because the terms used in the original/English version are the ones they are used to.<p>It also leads to some hilarious discussions among translators (at least for those of us watching from the outside). The funniest one I recall was the Portugese and Brasilian Portugese translators discussing how to translate the word "Roll" in the context of a DAW's "transport control" (i.e. the "play" button)
Hmm, haven’t come across the language icon before: <<a href="http://www.languageicon.org/" rel="nofollow">http://www.languageicon.org/</a>>. Unfortunately, it looks rather shabbily done and very abandoned. Serving a JPEG for the large image instead of a PNG (to get an alpha channel while still being easily copyable) or SVG (for best results except for most copy-and-paste purposes), speaking of 2013 in the present tense, no HTTPS, claiming “copyright and hassle free” but it’s actually using an extremely problematic barely-specified license (claiming “a CC license” with no link, and a whole bunch of terms so that it’s a poorly-modified CC-BY-SA-NC), claiming you can download “rar or zip” and it includes SVG and more but it’s actually ZIP only with an eclectic mixture of bizarre formats (not including SVG), colours (some obviously <i>wrong</i>) and sizes, the icon itself is not aligned to any sort of sane grid and has been hand-placed and angled… all up it’s an unhappy mess. That’s <i>not</i> the way to go about trying to make a universal language icon that you want adopted. Pity, because the idea is decent (though the original article is quite correct that labels are far better than icons anyway).
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 <i>dense</i>. It's nice, if I can rely on the built-in Apple versions.<p>I've also been caught out by choosing culturally-biased icons and visual elements.<p>I've used ibabbleon.com, in the past, and I'm told they do a good job. Not too expensive, fast, and technically correct.<p>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 ... <i>iterative</i> ... process, though, as they can do things like send you translations with illegal characters, or in formats like UTF-8(BOM).
One nitpick about localization:<p>If you speak several languages, try setting your device to use one _language_ and keep your locale to US.<p>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).
A related pet peeve of mine: if you want us to volunteer time and energy correcting or adding translations for you ("Help with the translation!"), then please make it as low friction as possible. Just linking to some third party website and expecting me to make an account, email-verify, figure out how it works, all to add a couple phrases of translation, is a good way to demotivate people trying to do free work for you.
What I don't get is why some companies with obviously large marketing budgets have so poorly translated websites. Most recent example I stumbled upon: 1password's German website. It sounds so horribly bad. Everything sounds like a word by word translation of English texts. "Halten Sie Ihre Familie online sicher" - wiebitte? Nobody speaks like that. 1Password immediately feels like a scam when I read those sentences.
I went through a lot of these pains. The biggest one was undoing the misuse of localisation tools to display content differently on each geographic region, and misuse of plurals.<p>I would also add collaboration efforts, how to make localisation work with continuous integration and not go waterfall, where you make a release, and you have to wait 4-6 days to localise half a dozen strings
In case the author is here: for me, the font size was at a level where I found it was most comfortable to read after zooming out all the way to 50%. And I have neither great eyesight (I should go for new glasses... soon...) nor a retina screen with zoom or anything. Probably looks great on phones, but on desktop for me the font was set uncomfortably large.
Youtube still shows dates for "Premieres on..." in MM/DD/YY, regardless of the locale. Internationalisation and localisation are such hard problems that even the big FAANG companies fail at it.
Interesting and related: why Mozilla created Fluent, a project to translate software with: <a href="https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-system-for-natural-sounding-translations/" rel="nofollow">https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-...</a>
> Translation and localization costs money<p>If you have a fan base, you can leverage it to get some amount of translation done. A lot of users are happy to help the product they like get better. Granted, the quality will not be as good as the quality you get with professional translators.<p>The article also did not talk about the actual the translation process, which in the case of a product that is released but keeps getting updates is not trivial.<p>There are tools that exists, but I personally decided to build a workflow around git, with a python scripts that generates a status of all the translations: <a href="https://github.com/jyaif/ppl-i18n#status" rel="nofollow">https://github.com/jyaif/ppl-i18n#status</a><p>The downside is that contributors need to figure out how to use github to contribute. The upside is that it's free, you get auditability, versioning, and the barrier of entry may actually increase the quality of translations.
Not to mention messages are almost impossible to google.<p>In fact, I used to play all my games in english for the same reason: items, places, starts... When you want to know more, the only good wikis and tutorials are in english.<p>I used to write a blog in french, it became super popular. Yet, it's a shadow of what you can achieve woth an english audience.
One problem I stumbled upon frequently is codebases that did not support localized formats, but just assumed a certain format to use, for example through concatenation.<p>There are capabilities built into the programming languages, which allow to format numbers, currencies, etc. with a specific locale. There are also great resources [1] out there that provide all kinds of formats and localized names for countries, currencies, etc.<p>[1] Unicode CLDR: <a href="https://github.com/unicode-org/cldr" rel="nofollow">https://github.com/unicode-org/cldr</a>
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.<p>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”.
It’s unfortunate that <i>by default</i> a lot of systems just gather strings into a pile for translation, as if all strings are created equal. But if you have two uses of the same text with different meanings, you have to be careful (e.g. put them in separate translation tables or something). Even for single words, e.g. somewhere there’s a button named “Open” but elsewhere there is a status text indicating that the current state of something is “Open”; lots of things like that. Just because it’s the same in one language, it may not be in another.<p>It would also be nice to have more context besides, say, just a comment. For example, things in toolbars ought to be <i>short</i> (ideally one word), things in menu items might be medium (a few words tops), things in notifications might be medium-to-long, and stuff in a window might have no restrictions at all. When you start from just a string, you do not necessarily know how much space you have and <i>even if your UI can auto-resize, that doesn’t mean you’d want it to in every case</i>.
I'll add my few experiences. The primitives of UI that we use in English are often untranslatable, or need really verbose translations simply because they've been inducted into English as part of the tech UI lexicon.<p>I speak four languages fluently, and 'OK', 'Abort', 'Retry' and 'Load' are some of the hardest things to translate.
Apart from the translation itself being bad (plenty of comments here already), this is another thing that also bugs me with apps/software in Brazilian Portuguese:<p>> Words may have radically different lengths in other languages<p>Sometimes the UI gets completely screwed, and I know it'll just look better in English, if the design was originally done with English text
A few more based on my own experience:<p>* People don't always speak the language of the country they are in<p>* There are significant regional differences for a given language. As a French Canadian, I couldn't translate a website to French because it would sound wrong to someone in France. For example, we have vastly different sets of English loanwords.<p>* The order of things can be different. For instance, German addresses put the door number after the street name. This can break your layout or even your UX in subtle ways.<p>* You must choose formal or informal pronouns (tu/vous, du/Sie) and use them consistently.<p>* Labels can make no sense if you don't know what the UI is like. Context is important for translators.
Also make sure whoever translate is familiar with the profession nomenclature. To avoid phrases like "save to disk" be translated to "leftover on plate" which will be very confusing.
I used to work on the localization team at my company. It's a pretty complicated world in itself. I was nodding my head while reading this and I think the biggest surprise I ran into is how not a lot of companies do a great job at localizing for many different regions. I think this is also something where large companies have a huge lead on compared to newcomers.
I live in slovenia... for many cases, it is impossible to even translate stuff directly into our language, because we don't only have singular and plural, we also have "dual" (for two of something). We also have a lot of irregular stuff, where we count beers:<p>- eno pivo (one beer)<p>- dve pivi (two beers)<p>- tri piva (three beers)<p>- štiri piva (four beers)<p>- pet piv (five (or more) beers)<p>How the hell do you put this into strings.xml?!
I see a lot of bad translations to brazilian portuguese even on big companies/services. It was always obvious to me that they could get better conversion rates if they fixed it. It's tricky, but not that hard compared to the benefit.