> Internationalization is not a feature, it’s an architecture... It’s not something extra. It doesn’t take longer. It doesn’t require additional engineers.
That feels like the wrong way to convince people. Having worked with i18n and l10n before, it absolutely is extra, takes longer, and on a very large team can absolutely bump up to an additional engineer.
Producing dynamic strings becomes much more involved and requires more testing. Handling RTL languages and layouts is another layer of things to worry about and test. Giving the translators sufficient context for each string is plenty of work, as is adjusting the design to fit strings that are longer than you'd expected. Etc. etc.
That isn't to say don't do it. It's just yet another cost-benefit calculation taking into account ease-of-use and market size. But pretending the cost isn't there doesn't fool anyone -- it just makes them think you're bad at producing realistic estimates and makes them less likely to trust you generally.
The problem with the "all engineers should internalise it into their development process" mindset is that it's held by so many groups. Your architecture should take into account internationalisation, security, accessibility, etc.
At a certain point, no single engineer can keep up with it all, and produce working and maintainable code - let alone all of them.
Unfortunately, I'm not sure what the solution is here.
I don't know what the ultimate solution is either, but it seems to me that internalizing more and more things into the development process is one of, if not the main part of growing as a developer. It's not even about being a specialist, just getting an intuition for design features that make it easier to implement i18n/l10n/a11y/security features correctly.
And performance. For the love of all that is pretty, do remember to internalize how to write non-wasteful code.
Part of growing as a developer is also knowing what you can do without, if you have 3 months to bring an mvp in front of a single language customer - i18n is the last thing on anyones mind, and delaying for even a day is a waste of precious time.
This does not mean that time is the only thing that matters, if you know that at month 6 you're going to launch in spanish - then you better look to avoid major i18n pain points, and think ahead to ensure that between months 3 and 6 there is a viable project to internationalize the product.
Maybe an MVP for an European dating platform starts at the minimum of your mother language, or say, the French market? What good is having every language if your MVP marketing budget doesn't stretch enough to warm up the dating scenes of several countries? Better hit big by divide and conquer than try to hug the continent with your legs (to use a Portuguese expression.)
Europe is more like 20 different markets than it is one big market though. Internationalization only matters if you're targeting all of those markets at once.
Hire more people or be prepared for long development times if you want all of the above. Restrict scope otherwise.
Internationalization is not a must if a single-language market is large enough for you. Tacking it on later will be painful of course. The same with security and accessibility, not having it may be acceptable in some environments.
Agreed. On the last product I worked on we had a custom UI with no translation/internationalization support and we ended up spending a total of 2 or 3 person-months adding the capability. But then there was also a huge amount of time we had to spend also giving the translators sufficient context to translate the UI because we kept getting inconsistent translations. And there were conflicting regulatory requirements for labeling and units in some places that we had to handle by displaying different assets.
We came to the conclusion that we could have spent a month implementing a tool for the translators and probably saved 2 or 3 months of back-and-forth and screenshotting.
While it's technically practical to architect for translation and internationalization, it's frequently out of scope for a first version of most products. If you're selling something for the US market, it's difficult to justify bumping your time-to-market to add support for something that you won't need for your first release. And that's not getting in to the additional complexity that it adds to the software system to have that support.
It's difficult for me to take someone seriously when they're making statements about internationalization not requiring any additional resources. It just tells me that they have no experience in any of the fields where it does require additional resources. And reading the article, I can see that the "experts" are all from web development companies where there's a framework that exists and you don't have to worry about justifying your use of Software of Unknown Pedigree to an auditor. Or where it doesn't really matter if your translation or internationalization framework doesn't work 100% of the time because it's unlikely to kill someone if a control on your UI is labeled incorrectly.
>It's difficult for me to take someone seriously when they're making statements about internationalization not requiring any additional resources.
I don't think is the intended meaning of the quote. Based on the rest of his response it sounds like he's saying, "Non-English speaking customers matter just as much to us and as an organization the default should be 'support i18n from the start'." If your default is "we must support languages other than English" then it isn't really "extra work", it is just core functionality.
Not sure why something can’t be extra work and a core feature at the same time.
Security, privacy, or accessibility are also core features for some startups but they add more work. Hell actually an accessible website is easy for Google translate to automacily translate, you might avoid doing i18n yourself completely if you have limited resources.
>Not sure why something can’t be extra work and a core feature at the same time.
This person is the chair of the internationalization team at W3C, their phrasing is intentionally trying to shift the perception from "extra work" to "default work".
Yes, it is more work if you ignore it but the person is trying to change that perception because inside organizations "extra work" is what you cut to make a deadline.
GTK and QT were handling all-in-one localisations for 2 decades with middle eastern languages, Chinese, Indic languages, and pluralisation without the need making localisations into standalone versions. That was once done by amateurs more than 2 decades ago.
Today it pains me seeing Android and Windows devs hardcoding texts letter by letter whenever they need to do more than bare basics with text layouts or handle different Chinese locales.
I think where Qt/Gtk succeeded and commercial software failed is the accent on making localisations legible over them "being pretty."
And it also causes compromises in the design of the English language version.
For example in https://blogs.msdn.microsoft.com/oldnewthing/20030929-02/?p=... Raymond Chen talks about how when a taskbar is docked vertically, the "Start" text disappears because while you can rotate English text to appear vertically, other languages are more problematic. In the same post, he also states that internationalization is why you have "1 folder(s)" "2 folder(s)" instead of "1 folder" and "2 folders".
this still doesn't work for languages with multiple plurals like Slavic languages, so how you write one word in three or more forms this way? the best thing i come over years it's abbreviating to the core, it doesn't look nice but it works "n fold." will always work unlike changing syntax to "Folders: n" which just can't be used within sentence. only way to make it right would provide different strings for multiple plurals based on value of variable and the best part it's in each language it differ, good luck with that, abbreviation it is...
Yeah, this is very true. I spent 4 years working on, AFAICT, the most widely translated site on the internet, https://www.jw.org. It’s currently at 994 languages. Handling RTL and sign languages is an especially large undertaking that can’t just be swept under the estimation padding rug. But, if your CBA allows for it, it’s well worth it.
My i18n/l10n experience is limited but I actually thought it was really positive to get everyone thinking about variable content length and appearance from the outset.
A lot of times I get designs that look great with just the right amount of lorem ipsum in there but fall apart when the real content with all its variety and imperfect.
I think sometimes having to step back and generalize helps avoid specific problems.
I would love to get a design that works straight away in even just 1 language. Usually I get one that completely falls apart once you add in things like validation messaging or other dynamic elements.
My take on internationalization is that I want to see less of it.
I am Russian living in Switzerland, where people speak French, (Swiss) German, Italian and Romansh. I often travel to Barcelona, where people speak Catalan and Spanish. I don’t want any of these languages, I want all sites in English.
This is hard to achieve, as nearly everybody uses geolinked internationalization. It is awful. Especially here in Switzerland — almost every site tries to show me the German version by default (most of Swiss cantons are German-speaking, but mine speaks French).
Please just use English. Or if you must, enable language selection in users profile, do not try to detect it from geographic location.
My pet peeve is when I have an application crash and the error message has been translated. Now googling it is extra fun, not to mention bug reporting.
Fortunatly with Linux, I usually can get the proper message with "LC_ALL=en_US.UTF8" if I can, and desire, repeat the exact same error.
Now I understand that this is done for openess and diversity. But technical terms should not be translated. I'm french, and I accept that english has won as the business language, and the IT language. Let's move on.
Honestly, we are wasting humanity potential for not having a common language. I really, really wish we would all learn english as the second language, and that all laws, forms, labels and signs would be translated to english everywhere (as an addition to the local lang, not a replacement). It's an imperfect language, but it won half of the world, and the other half will have an easier time learning it that us learning theirs. Plus it has a very simple alphabet, and is already used for science, business and international politics.
At this stage, I would gladly agree for all the french books and movies being burned and lost forever if it means one language, any language really, becomes magically the main one for humanity. We have too many communication problems.
But since magic doesn't exist, what about getting off the ego train and just adopt the imperfect status quo and make something awesome with it for a change ?
English in terms of number of speakers has already reached the point where the number of ESL speakers outstrips the number of native ones by a good margin. The simple alphabet is a plus. I wish the spelling wasn't so godawful.
One of my favorite aspects of the English language is that not only is it shameless about stealing other languages' words, but it seems to take it as a point of pride. It's a good feature to have if you want something global- it means that useful words will accumulate without regard to origin, which benefits everyone.
"We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary."
and also by extension, Greek (directly in many cases -- almost every english word that starts with 'ph' was a greek word -- but also a large portion of medical and mathematical terminology)
I suspect english words starting with 'ph' come from french, french words with 'ph' used 'ph' instead of 'f' (same sound) to emphase the fact the word borrow greek root (but who care the word come from greek, does it make it easier to learn? one more shitty rule of french).
Granted I don't have hard data on the "ph" fact, the source is pretty credible in my opinion. The fact appeared in an article written for the British Council, co-authored by Martha Peraki, a Linguistics PhD recipient from American University.
Heuristically, the "rule" passes the eyeball test: philosophy, physical, photo, phrase, philanthropy, phobia, phage, phalange, phalanx, phallic, phase, pharmacy, phantom, phenomenon, phone, photons, photosynthesis, physician, physique, phytoplankton, so on and so forth
Geographic location is incredibly ineffective anyway depending on your ISP and other factors.
Rather than defaulting to English, why not default to whatever the browser's OS is set to? At least for JS apps, there's navigator.languages, and there's an Accept-Language header for both language and locale for standard server-rendered plain ol' websites.
Geographic location really does seem like the worst possible option to use.
Rather than defaulting to English, why not default to whatever the browser's OS is set to?
As someone who develops multi-lingual web sites, I can tell you this doesn't work.
It should work, but it doesn't. We test with actual users in their home environments, and... people are messy.
- The vast majority of our users accept the default language (English) when setting up their computers, even if they don't speak English.
- In households where the parents are immigrants, very often the children set up the computer, so it's set to English, which is the child's preference, even if the parents don't speak English.
- Poor households often share a phone or a computer, and each person may not speak or prefer the default language that was chosen by the person who set up the computer.
In the idealized world that Silicon Valley imagines where 1 person uses 1 computer with 1 owner and speaks 1 language, it's fine. But in the real world, it's just a mess.
I'm not saying abandon multilingual capabilities, I'm saying Rather than defaulting to English, why not default to whatever the browser's OS is set to?.
This was in response to a comment chain suggesting that geofencing default language is a bad option, because of how inaccurate it can be.
> - In households where the parents are immigrants, very often the children set up the computer, so it's set to English, which is the child's preference, even if the parents don't speak English.
I fail to see how any default language setting will help in this scenario, assuming they've immigrated to an English-speaking geographic region.
> - The vast majority of our users accept the default language (English) when setting up their computers, even if they don't speak English.
I suppose this is one scenario where geofencing might work better than OS default language, but then again, based on my experience it's just as likely to be wrong. At least with English it'd be an interface they're accustomed to seeing, and would have better luck finding the website's language selector, rather than something more arbitrary :/
Firefox (and I suspect other browsers) allow per-profile configuration of the language, independent of the OS.
In the scenarios you describe, it's hard to see how geolocation makes things better, as it has all the same problems, except for the "installed in English because didn't change the default" where you now have a chance (but no guarantee) you'll select the correct language.
And unlike configuring the language in the browser, there's no hope geolocation could even possibly work correctly.
>In the idealized world that Silicon Valley imagines where 1 person uses 1 computer with 1 owner and speaks 1 language, it's fine. But in the real world, it's just a mess.
In Silicon Valley geolocation works fine, but it's a terrible, terrible, TERRIBLE idea everywhere else.
Defaulting to OS language can be terrible for organizations where the working language is different than a local language. Lots of programs do it and they always default to the language the OS was installed in, not the one that is currently used by the user.
I work in an international organization in Czech. The local IT team installs Windows in the local language, then sets it to English (which is fine, mostly). Half of our employees don't speak Czech well and changing weird tools to English is a constant and difficult hassle for those who haven't learned the basic words yet (printer drivers and small open source tools are the worst).
Browser language can be difficult as well. Half of the population is bi- or multilingual.. choosing which language to use for a browser (for me: German or English) affects how well Google Translate works - which I use daily. (Somehow, big American companies don't get the idea that people can live in multiple countries at the same time or speak multiple languages).
User / Domain profiles that set the language of wherever you login. The "original" installation remains in Czech.
Yes, it would be preferable to have the installations in English initially. But we weren't always international and not all of our employees speak English well (this is common for older people - former UDSSR ..., admin staff and people in roles that don't require a college education). There are still legacy tools in Czech, fully Czech teams (who obviously work partially in their native language), a need to work in the local language (procurement, legal topics,..) etc. It's just not economic to completely enforce English.
just FYI Czechia was never part of USSR and it's quite offensive to tell it to Czech person after being occupied for decades by Soviet military. that's like saying Afghanistan and Iraq are US states to people living there, just because US occupied their country
You are correct, I was sloppy writing that and apologize.
Growing up, I learned that Czechoslovakia was part of the "Eastern Bloc" and we were never taught much about the individual countries and their peoples.
Moving there taught me a lot more about the country and its neighbors' history and culture, and also my own culture.
it all comes down where you think Vienna it's, because it's for sure more eastern city than Prague, but i don't see people calling Austria eastern European country, which is political from before 1989
i have no problem ignoring central Europe when people will be consistent about geography especially regarding Austria, but since nobody it's putting Austria in eastern Europe then we have to live with Central Europe, after all Europe ends at Ural, so calling Czechia eastern Europe it's quite a stretch
people can live in multiple countries at the same time
As a silly American, can you explain how you live in multiple countries at the same time? Do you mean you, for example, live in one country and work in another?
This is a favorite topic of mine. There are several multi-country metropolitan areas in Europe, for example Malmo-Copenhagen and Görlitz/Zgorzelec. Many cities have smaller suburb cities across the border, like Strasbourg-Kehl and Geneva-Annemasse. And the Benelux countries take this to the extreme, of course.
Even Berlin, which is pretty far from the Polish border, have commuter trains to Poland. That's right, the Berlin metro ticket will take you to Poland.
I live in Spain and Switzerland. I spend most of the summer in Spain, and the rest in Switzerland. I work 100% remotely, so I can live and work anywhere (not seamlessly, as I need visas and residency permits and everything else, but still doable).
My wife is a scientist, so we travel a lot and change places of living. So far, I lived in Russia, Switzerland, Italy, Spain and Denmark, and about 2 months in the US.
As a young adult, I studied in a country (had a flatshare there) and took the train (2hrs) at the weekend and during the holidays to stay with my parents.
I guess lots of people close to borders know family situations like that (parents, partners).
Now, I have a job with 90% business travel between two countries (but same cities). Have small apartments in both. It is just more economical and comfortable that hotel room living.
There are also often reasons not to completely move to a country, even if it's close (different tax situation, having to switch social security systems which affects your retirement, wanting to stay inside a certain social security systems which requires a place of residence..)
you can live in Bratislava which it's less than hour drive from Vienna where you can work every workday, plenty of people in Europe live nearby border and spend lot of the time on both sides speaking completely different languages
Is it really the worst possible option? It’s often a pretty good guess, and accept-language is similarly unreliably set and can be fiddled with by intermediaries. Navigator.language doesn’t help you until you’ve already served and run JavaScript.
The right solution I think is to make a reasonable guess and then allow the user to control it. None of these guesses are going to work for everybody on their own.
I'm unaware of any intermediaries that fiddle with accept-language, so I can't really speak to how reliable it is. I can say that due to the ISP I use geolocation typically gets my location wrong by somewhere between 650 - 1600 km (400 and 1000 miles).
Yet Google, Microsoft and Apple use it. :( At least with Google, you can usually log in to your profile and set it to English; with Microsoft and Apple, you are out of luck.
That's one big problem on the web, IMO. Google in particular does a lot of things that are questionable UX-wisely, to put it charitably, and then a lot of web shops try to copy those things without giving them any critical thought.
This is fromt he point of view of someone that is fluent in English.
I assure you that in countries like France, Italy, Spain, etc... this is true but for a small percentage of the population.
It makes no business sense for a company not to localize a website or a service, if your market has a substantial number of non-English speakers.
But yes, for my own convenience (unironically), I wish that every website had a base English version that you could access with a single click.
For example I was looking at some Microsoft webpage with troubleshooting or API information (can't remember). By default it was shown traslated based on my location, but there was a prominent "Read this in English" switch at the top. Top marks.
The problem is not the localization. It's choosing the default language based on anything other than explicit info provided by user-agent - that is, URL and Accept-Language, in that order.
I can't speak about France, but my experience in the U.S. is that recent immigrants who can't speak English still set their computers to English.
For some it's because they're so used to the non-English versions of web pages being so bad or abbreviated that having an English page they can half read is often better than the truncated "good enough" version provided in their native tongue.
Yes, the english level is terrible in my country. Unfortuntly, translation is imperative if you want to enter the market. Which sucks, because it's a huge waste. There is not benefit to it: a UI is not like a book, you don't lose some quality in translation. In fact, most UI are worse once translated because english is a short and to the point language, which is what you want for buttons and menus.
I never understood why sites try to do geo based localization. Every browser in capable of setting the requested language in the request headers so why not use that ? Technically much simpler as well. And the user can just change the browser preferences and all sites would magically switch to the right language. Hey I can dream right ?
Developer cleverness/arrogance. “Users are stupid” mindset. Product designers thinking they know better than their users what language they want.
It’s infuriating to travel overseas and, without changing anything about my computer’s setup, having to deal with web sites overriding my chosen preferred language. Please, just stop doing this.
In my experience these are often configured wrong, because browsers are guessing settings based on the locales used by the operating system, and because users don't know how to configure it because it is really hidden away.
For the cases I see it is technical minded people that speak another language than Danish, that buy (or inherit) a laptop with Windows on Danish, so the browser infers its settings from the operating system, and now you can no longer trust this header.
But it might be just as wrong as guessing language based on IP-location, so there are not really a good out-of-the-box solution, so every website will have to build their own selector maybe with input both from the browser headers and from the IP-geolocation.
Browsers should just make it more obvious and easier to configure. But a lot of websites respect this, I've found. You'd be surprised.
Chrome makes sure to suggest translating a page. Why doesn't it suggest to change my language preferences as well? Rather than just suggesting 'ignore translating for this language' as the alternative.
A number of reasons I work for major conglomerate which has over 200 brands and operates in getting on for 200 countries.
In the USA for one brand they sell different products to the UK than the USA for another brand they use a different brand entirely in the USA to the rest of the world.
There are also legal reasons why you might need to geo target.
That displays different content, but the Accept-Language header (with locale specialization) isn't about the content, its about the language the content is displayed in.
That’s not localization, though. That’s market segmentation based on location detection, which is a different thing, strictly speaking.
I mean, they could still show me the UK-only site if they determine that I am in the UK, but show me the UK site in German, with German units, dates and time codes, etc., because that’s what my browser might tell them that I prefer.
Have you any idea how much work that is and how many things can go wrong I might have a dozen or more locales / languages and if you then want to see any locale in any language that's a huge amount of different urls
Ok so you want German content in the UK
do I show you the German locale and products legally available in Germany?
the UK locale and products legally available in the UK translated into German?
And do I age gate you based on German law or English
what happens if I show you a BOGOF offer do I obey German law or English
What happens if google messes up.
What happens if your in Quebec and I accidently show you an illegal competition
What T&C's do I show you
No need to have different urls for different languages. If you detect that the user's location is in the UK display the UK site, comply with UK laws etc... If that same user sends a German Accept-Language header, show them the UI in German. Doesn't seem much more complex that what you're already doing...
You might want to translate the url for any number of reasons mostly SEO related.
But the main problem what if google gets confused and messes up and lands you on the wrong potentially problematic url - do you want to be the developer explain to the General counsel why the company is in trouble.
Sometimes I can't buy books or movies or games in the language I prefer (English), I have to wait for (usually poor) localization. The number of times I have saw the dreaded "this product is available only for the residents of US and Canada", I can't even understand, why my money is not good enough for that.
I have now several DVDs where the first menu asks me to select one of 6-8 languages. Then it shows me the unskippable copyright ads (you wouldn't steal a car blah blah blah) localized.
Then we get to the main menu which is English only, regardless of the language you selected. The movie itself is in English, subtitled in at most 3 languages, reachable only from the remote control button (ignoring your first language selection), and sometimes these 3 are different from the 6-8 copyright ad languages.
It's fun to see the copyright ad in Russian or Italian.
It's likely not that they don't want your money, but rather that they don't have the legal right to sell you a piece of content in exchange for your money.
If I am visiting another country, I can buy a physical game or movie in a brick and mortar store. There isn’t any reason it shouldn’t work for online purchases.
If you use your laptop in another country, you'll also be able to purchase geo-locked content with your foreign IP address. (Unless they reject foreign credit cards, but that's more to prevent VPN's, and you're just a false positive.)
The way copyright gets licensed per-country is pretty dumb in the age of the internet, but it's not correct to blame individual retailers for this. They would love to have a larger customer base.
Actually, there's a lot of stuff they won't ship to you. I had to use a forwarding service to buy video games from amazon.co.jp for many years, although more recently they've started to allow foreign purchases on most video games. No idea what precipitated the change.
I imagine this is mostly a legal gray area that no one cares enough to litigate. The number of people going to foreign sites to paying international shipping prices and wait weeks for their products to arrive is too small to worry about.
Yes! When I head to docs.microsoft.com they show me a really bad machine-translated site of the C# API. And it is hard to change to the original English site. I am a software developer; I know English, thank you very much!
One of the few things where Google Search is really awful for me personally. I've set it up to get search results in German (country of residence) and English (everything else). But I haven't found a way to communicate to it that for anything technical, I have a very strong preference for the English results.
My previous job had me traveling between Germany and China; during that time, Google's ridiculous localization of search results was becoming unbearable. I ended up permanently overriding my default search engine to point to this URL: https://www.google.com/search?hl=en&q=%s.
(It broke auto-suggesting search terms in the omnibar, but the actual search results are again sane.)
This is a good idea in theory, but completely unworkable in practice. Most users do not have the skills or know-how to navigate whatever Accept-Language setting their device is exposing.
But yeah, sites should have a way to sticky it once you have a profile and log in etc., but most users aren't going through that path for most sites.
Presumably they wouldn't have to. If they are running en-US Windows, they get en-US websites. If they are running fr-CH Windows, that's the websites they get. You don't really have to worry that someone running ja Windows can't read Japanese.
(Of course, you'd still expose the option to change this from the inherited default in the browser's preferences)
Yes you do. Plenty of people using an OS in whatever language can barely speak a word of that language.
Most commonly they'll use an English OS for whatever reason and want to browse websites in their local language.
This is why you'll find that a lot of website language detection tends to discount English specifically. I.e. if your Accept-Language is "en" in France they'll probably give you French, but if it's e.g. Japanese in France they might think that's a "real" setting and give you Japanese.
Or, as I'm sure a lot of non-English speaking technical users here can attest to, they like to use an English OS UI on their laptop or phone, but speak the local language and want browsing a local website to just work. Non-technical users do that too, but have no idea how to tweak their Accept-Language independently from their OS language.
Really, do armchair commentators here think that programmers at major websites like Google that have enough data to know how people are likely to switch languages from the default haven't thought of just implementing what's literally the most simple thing you can do, which is to obey Accept-Language?
BTW. I accidentally discovered that in case of accessing google.com from non-English speaking country, `en-US` is treated as non-reliable (probably because many devices have this set as default), whereas `en-IE` for example is treated as reliable. Also appending any non-English language after `en-US` does the trick AFAIR.
Basically `en-US`-only Accept-Language seems to be treated as "perhaps default language of a device and user didn't change it, we should not rely on it" and IP-based localization is applied in that case ("in France? ok show French version").
In approaching 100% of cases the operating system pesters you to set a language+locale during setup, and the browser propagates that via Accept-Language. The advanced use case is the user who wishes a set of > 1 weighted language ranges; e.g. de-DE most preferred, then English in any culture, then Latin American Spanish.
How is having a significant number of users be served the wrong language for every site they visit, then having to navigate and create a profile and set the language for each site individually in a different way, in any way an acceptable solution either?
If for historical reasons Accept-Language needs to pass through the OS locale, which is wrong and can't be changed, why not just standardize an optional User-Requested-Language(s) header, that only appears if the user explicitly sets it in the browser?
The current solution is awful and improving it doesn't seem like rocket science but there seems to be zero interest in fixing it. Stuff like this is why closed platforms like Facebook probably have a brighter future than the open web.
Doesn't the browser pick up the OS language setting? That's going to be correct for most users.
And browsers could make the override easily discoverable in preferences (at least on MacOS, app preferences are in a standard place from the user's perspective: File -> Preferences).
That's actually not correct for most users. Most well-known case is India, where the OS language is usually set to 'English' for $REASONS, but people still prefer content in Hindi. (Or Urdu)
Guessing what language a user actually speaks is not straightforward.
It still doesn't make sense to use the same behaviour in Europe, where in my experience the OS language is almost always the preferred language of the user. (Especially on a mobile.)
1) Inertia. The Indian market is largely English-speaking, so many products came to market in English first, and now people are used to it.
2) Colonialism. Using English still marks you as "educated" and "more respectable". So, to not look like a yokel, everybody sets their UI to English. Content, which is more ephemeral, still is successful in Hindi/Urdu.
3) Localization is hard, and often the English localization is better - but content isn't localized, its first language is the native language.
IIRC, most browsers do default to the OS language. It's just not the correct choice in all cases :)
Websites doing weird things is websites trying to be smart and failing on top of that.
Same happened in Pakistan, the higher up the social ladder you go, the more likely you stumble on somebody who simply can't do written Urdu, or even speak it.
In my experience, most European sites will/should consider 'English' as default/unset/unknown. So when in German,y, if the header says French, give French . If the header says English (US or UK), give German.
What is actually a tech failure, is assuming I understand Spanish if I happen to be in Spain. That sort of ham-handed, short-sighted approach drives me nuts.
You only need "fiddling with language settings" if you want something other than how your operating system is configured.
Google actually did this at one point. I was in the Netherlands when I signed up for Google+. I don't speak Dutch and hadn't changed any of my language settings - the only way they knew was via my IP address. The UI was mostly in English, but all my circles (or whatever they were called) were named in Dutch.
I get the weirdest language bugs with Google:
- The info box on the right hand side of the search results intermittently shows up in German
- A suggested event (a football match) in the UK (where I am) had both team's names transliterated into Cyrillic
- An airport on Maps consistently shows up in either French or Finnish (or both!)
If this is too complicated, it is the fault of the user agent. That's a different issue than whether a website should respect a requested language if it is available. You're arguing that the user agents are flawed, so we should have flawed content delivery to compensate. This is how flaws get folded into systems and magnified over time. Just fix whatever flaws exist in the user agents, language selection based on http headers is a pretty good solution for the half of the problem it covers.
I think your comment is kinda funny. Reminds me of California, a lot of effort goes into to providing public services in languages people best understand[1]. Not the local language or the default language of country of origin. Someone from South America might not actually speak Spanish. They might speak Quechua for instance.
Brings up the point, 'internationalization' as a concept is utterly broken. People speak languages not countries. Also very likely that the non default language users may also be most in need.
Probably should be a list of falsehoods programmers think about language.
[1] Local school district I think at one time listed 43 languages.
I use a VPN for all traffic, using an exit server in Finland. I don't speak a word of finnish.
I have chatted with people who work on internationalization about IP based detection. The explanation I've always heard is that `Accept-Language` is all but useless. For a significant number of users the value is, incorrectly, `en-US`. Because of how unreliable `Accept-Language` is, IP based detection is unfortuantely has a much lower false positive rate.
In general, I expect a web site, if it's available in more than one language, to offer me a menu where I pick the language I want. It's easy to do and it works for everyone. Usually the languages will also be accompanied by a little flag for extra non-ambiguity.
Given how easy and robust this is... what exactly is the problem with using Accept-Language as your first guess? Maybe if more sites honored Accept-Language, users would start setting it.
You still have to pick a default region/language unless you want to force the user to make a selection before they get anywhere which is a mess UX-wise
Incorrectly... or not? I have my Accept-Language set explicitly to en-US, on purpose, in the small hope I stop getting localized results. I don't care about Polish Internet, I want results from the whole Internet.
If it's specifically that value that's a problem then I'd suggest the following heuristic: Use geolocation if `Accept-Language` is `en-US`, otherwise respect the header.
Technical users in Switzerland/Japan/wherever who want to see English pages can set their header to "en-GB" or "en-AU" to avoid getting caught in the heuristic.
Edit: I'm sure it's much more complicated than that, of course- l10n isn't my job and I don't want to be this guy https://xkcd.com/1831/
But how can the Accept-Language header be useless? I suppose almost nobody sets this header by hand and it is derived from whatever environment your browser is in.
I mean if my Windows or my phone/tablet is set to German, showing me a German UI, wouldn't then the browser use that setting for Accept-Language?
I can't understand how this would produce unreliable results unless there were some serious bugs in browser support (hopefully in the past).
Excuse me, sir. I would rather prefer it to always be German. Or French. Or Spanish. Or Italian.
Not everybody speaks English, so it's perfectly fine to try and guess the person's language first - and allow to change it later.
Also, once the UK has left the EU, English is not even going to be an official language here anymore - so I can see no reason why English should be the default in Europe.
Yes, as an English speaker living in Germany, this is also something that drives me up the wall, but has also gotten better recently. My personal favorites, the cream of the crop:
* Netflix: full site in English, subtitles (and audio tracks) for all shows available in German, English and several other languages. Only a few edge cases where the source (written) material appearing on-screen has already been hard-translated in.
* Amazon: will let you turn on full English experience, up to and including...English speaking support (both written and verbal). This is truly the cream of the crop in terms of quality of experience.
I really appreciate any German-oriented site that offers English as a possible language in spite of knowing my location. And if somewhere on your servers you already have English available, you would be silly to not make that available world-wide (where it makes sense).
Of course, these are two of the biggest tech companies, so perhaps that speaks to the cost of internationalization.
I live in Switzerland too and especially Youtube never seems to know whether to serve me ads in German, French or Italian (even though Google should know I almost exclusively consume English content).
So I can sometimes watch several videos in a row, where I get served the same ad in a different language.
But don't ads on YouTube follow the more classic advertisement 'demographics', where location is more relevant than language? And it may just be cheaper and easier to just target all of Switzerland?
This is where I feel a bit better about targeted advertising, if they're not able (as in at least not cheaply enough to be worth it) to serve me an ad in a language I understand, they still have a long way to go.
And that's in Switzerland where people have a lot of disposable income and thus must be more attractive to advertisers than most places, despite being relatively small.
My original compilers had error messages in English, German, French, and Japanese. It was a fair amount of work to make that work. I was pretty proud of it.
Turns out that I couldn't find anyone who ever used the non-English messages. Everyone preferred the English messages, because everything else with programming was in English.
So I abandoned worry about that, and haven't heard anything about it since.
(Though the compiler uses UTF-8 strings for all text.)
One problem with the translated GCC messages was that GCC didn't use error numbers at the time (still doesn't, I think, I didn't notice anyway), so it was basically impossible to reference the error except by full error message.
MSVC on the other hand always includes a warning/error number, so there less issues talking about a particular error independent of language.
Presumably you'd be fine with Russian too, but by the sound of it you've given up on ever seeing THAT. ;-)
(personally English is also often first choice, especially for tech documentation. Translations often seem to be an afterthought and can be pretty random. You need to translate randomly picked words back to the original jargon as best you can and hope you didn't miss anything. )
Yeah tech documentation is a really interesting edge case for translation, as a good chunk of it will be new vocab and/or simply invented vocab for most native English speakers reading it anyway, so it's actually a pretty philosophical question about language itself if/how that stuff can be translated to other languages at all.
It's because a huge number of people just discovered the net and they don't surf as we are used to, like they don't search as we do etc. I don't want to sound elitist, many of them don't have the experience of it. They are going to repeat all behaviors and fall in all traps since we were new on the net. I see this in the way my kids use their phones.
You are an edge case. Go to the site in English, remove the root URL from your history. So it always suggests the English version ( URL) of the website.
Best practise of a website ( eg. Google) don't suggest redirection based on an IP, which means a correct URL or cookie would suffice in most cases
I integrate German, French, English and Dutch from the start.
They are all languages used in Belgium, English as a developer.
I've gotten it pretty productive. My database doesn't require extra tables and it's fully customizable per client ( 1 extra table). Because my clients, also want to label things differently according to their use-case. I control the translations ( the default and custom ones). As long as it's logical. I agree. I stop them when they don't use general words and try to create another use-case for it. That would break the app functionality or changes expectations ( eg. Stupid example: Label Completed as invoiced because that's their end state of a ticket). Then they need to adjust to the application workflow.
I have custom parsers for languages stored in the database ( description is a multilingual column in the database for example).
According to what I know, I'm the only person I've met who goes that deep from the start. And I have real advantages with it, as long as it's an application that "my clients" own clients use. Language doesn't stop and culture, but it's also niche and even "company behavior" related.
For integrating multiple languages...
If you live in America, it's an after thought.
If you live in Belgium, it's the first thing you run into.
If you're an SMB, you need to go deeper to differentiate.
To me, the title only makes sense to me when you're mother tongue is a dominant language in the world ( reach for the stars).
What I haven't run into yet is right-to-left and Arabic, Chinese,.. ( non Latin based languages) currently.
Using USD, pounds and EUR is handled within the frameworks I use. Dot Net uses it extensively and yes, I use resx files ( which I don't like a lot, but I've wrapped them and use them as default translations of a language, clients can adjust them).
I don't need translators in the start. I can handle French, Dutch, English myselve mostly. My German isn't very good though.. ( which sucks because of the title here :p )
Ps. Yes, Changing translations is billable per hour.
As per the article, internationalisation and localisation are harder than they seem at first. But take the time to do them right and you can outsell your competitors in certain lucrative markets.
My product has many competitors. In the US, the UK, and other English-speaking regions it is a struggle to compete. But our team has experience with languages and translation so that gives us the edge in markets outside the Anglo-sphere.
Lots of the comments here are about preferring the version in English and being frustrated by software in other languages, pushed based on geography or some-such. These are valid experiences, I certainly learned from the comments and share some of the frustration. But let's all keep in mind that this is an English-language forum. Contributions, even more than readership, are from people with fluent or nearly fluent English. So, biased sample and all that. Generalize at your own risk.
As a german who used to do front-end, I'd have loved to delay those problems in to the first i18n.
A "Cart" is a "Warenkorb" or an "Einkaufswagen" and both can't be shortened at all. Oh and did you know the correct spelling for a price would be "1.999,00 €"? (with a space (which even germans find ugly), comma/dot swap and the currency behind the number).
I'm not usually an advocate of icons, but in that case, an icon of a cart would still be preferable. "Korb" looks like I can buy a basket and "Wagen" alone usually means car. These meanings may not even make sense in the specific context, but with Kruger's Fact of Life #1 in mind ("We don’t read pages. We scan them."), the first connotation is actually what matters.
> I'm not usually an advocate of icons, but in that case, an icon of a cart would still be preferable.
I think on most shopping sites, the cart button has both an icon and a label anyway.
> These meanings may not even make sense in the specific context, but with Kruger's Fact of Life #1 in mind ("We don’t read pages. We scan them."), the first connotation is actually what matters.
The first connotation depends on the context though. If you add an icon to the cart button and put it in the top right corner where people expect it, I predict that people may find it harder to identify the correct meaning than if you used "Einkaufswagen" or "Warenkorb", but only minimally.
But, in english, "Car" would be a valid (if useless) abbreviation of "Cart". Seeing "Car" next to a cart icon would be just as confusing, which is why abbreviations that are valid, common word are typically avoided. Sure, people will likely figure it out, but it will look strange, since their first thought on seeing "Wagen" will be "Why is there a car button? WTF is this for?" before eventually deducing that it is the shopping cart.
To be fair, German is just a hard language to abbreviate, the compound words really tend to work against this. I'm not a linguist, but I've always wondered if the word length is one of the reasons English has borrowed so few German words relative to the romance languages.
But "Wagen" does not mean car. It's meaning is closer to "wheeled vehicle that is not a bike". It's a hyponym to both "Auto"/car and "Einkaufswagen"/shopping cart.
The Google Images results for "Wagen"[1] illustrate that "car" is by far not the primary meaning.
In my experience watching regular (not even necessarily elderly) people use web sites and apps, the "hamburger" menu icon is practically never understood. Even the "X" (close) icon is often overlooked, particularly if the lines are very thin (in accordance with current aesthetics): "So why don't you search for shoes now?" - "There's something blocking the page, so I'm waiting for it to disappear." (It was one of these obnoxious "Please sign up for our newsletter" modals.) I am increasingly convinced that the only icons that are more or less universally understood are Rewind, Play, Pause, and Forward (within appropriate context).
The question is, though: Unless the specific icon is reasonably well-understood or visually striking, why would you even add an icon when you already have the label? It's just more noise for the visual system to parse.
My original point, however, was that if you can't use more space for your German translation than the English word "cart" takes up, I would still rather understand the cart icon than the mentioned abbreviations. (Obviously, it would be preferable to solve the underlying issue of a fixed layout.)
I like icons for visual hierarchy and fast recognition of known functions.
only very low key ui actions like edit I tend to keep without them.
I totally agree about the hamburger and (not just) old people.
Just the other day I had to decide between two proposals with and without icons and clearly voted for the one with icons.
The quote from the article's title refers to copy and yes, with English being a rather short-ish language, translated copy will fail to stay within design constraints in pretty much all other languages.
On the other hand, except for Russians (and the dozen or so Canadians and France which owns land in almost every timezone on the planet) pretty much every country on the planet has just one timezone. So creating an app for the US market brings that nasty problem.
Microsoft seems to increasingly use machine translation for their user interfaces (really caught my eye in Azure DevOps). It mostly works... until it doesn't, and the translation gives a word that's close, but not right in context. It's annoying and makes me feel like they just didn't care enough. Frankly, I'd prefer an English user interface over one that tells me "Yeah, we checked the box, but couldn't care less!"
Offtopic but how do I subscribe to the paperback copy of Increment magazine?
At the time I got a free sample of their 5th issue - Programming Languages - and asked about getting a copy of previous issues and subscribing to future ones but never heard back from them.
Unless you mean something else, locale support was already introduced in AmigaOS 2.1.
And I'm not sure what you exactly mean by "did it right". i18n and localization support is now in every OS and almost any UI framework available today.
It was really great for its time but I wouldn't know of any feature it had that isn't standard today.
I never had a 2.1 machine, so I was mistaken there. Thanks for correcting that.
To the point, I think the way the Amiga let a third party provide a localization file was easier than in todays OS more end user friendly. It was open and standardized across the OS. Not every app was cooking it's own format.
That feels like the wrong way to convince people. Having worked with i18n and l10n before, it absolutely is extra, takes longer, and on a very large team can absolutely bump up to an additional engineer.
Producing dynamic strings becomes much more involved and requires more testing. Handling RTL languages and layouts is another layer of things to worry about and test. Giving the translators sufficient context for each string is plenty of work, as is adjusting the design to fit strings that are longer than you'd expected. Etc. etc.
That isn't to say don't do it. It's just yet another cost-benefit calculation taking into account ease-of-use and market size. But pretending the cost isn't there doesn't fool anyone -- it just makes them think you're bad at producing realistic estimates and makes them less likely to trust you generally.