
Îñţérñåţîöñåļîžåţîöñ - pwim
http://googlewebmastercentral.blogspot.com/2011/09/internationalization.html
======
tjoff
An extremely important point that most native english speakers just doesn't
seem to get: Don't force a localized version to your users.

In many countries your users are probably going to prefer english than a
translated version for many reasons, and that's even before taking into
account that you probably can't translate it well anyway (even with a lot of
resources and effort) which makes it even worse.

Always make it ridiculously easy to switch to english, always. In many cases
you probably should make english the default even though you have a localized
version (this is especially true for web sites, few things are as annoying as
having to change language again and again and again and on every device,
browser etc. (example: youtube has this annoying message telling me that a
localized version is available that forces a page reload to dismiss (and thus
you have to reload and restart the video, true story))).

This of course depends heavily on your target audience and their culture but
just don't assume a translated page/app is a favor, you just might end up with
some confusion and a group of really outraged users (boy do I loathe
applications that assume I want a translated version - always give me the
option to change it to english during the installation).

Direct machine translations might be better than nothing for some cultures but
for some it's a slap to the face and will just make your company look
pathetic. Example: Adobe.

~~~
hasanove
> Always make it ridiculously easy to switch to english, always. In many cases
> you probably should make english the default even though you have a
> localized version (this is especially true for web sites, few things are as
> annoying as having to change language again and again and again

Yeah, like google.com. Whatever I do it just does not seem to be possible to
_permanently_ set US version of google.com as default, not local version.
Especially frustrating when traveling to other countries and getting it in
language you do not understand.

~~~
shithead
No redirection: <http://www.google.com/ncr>

Explained here:
[http://www.google.com/support/websearch/bin/answer.py?answer...](http://www.google.com/support/websearch/bin/answer.py?answer=873)

~~~
waitwhat
I have that as my homepage to make sure that the cookie is set every time, and
I still occasionally end up with search results or google products in non-
English.

~~~
darklajid
Agreed. And it annoys the hell out of me if I fire up my Android browser and
end up on a Hebrew home page, again.

Somehow I thought that we already had a mechanism to negotiate the language
between server and browser. Ah well, let's just ignore Accept-Language, shall
we?

------
hopeless
We're currently going through our internationalisation test phase for a major
release and it's been a _huge_ headache.

My one piece of generalised advice: DO NOT leave internationalisation testing
to the end of the release. Make sure you're pumping Unicode strings through
your app in unit tests. Make sure you're regularly viewing your app in other
languages using mock strings if you haven't got the translations. The earlier
you can find these defects, the easier it is to fix. There's a perception that
internationalisation defects are easy fixes, just updating a messages file.
The truth is that major parts of your app may not work unless you regularly
test it. And don't rely on the Unicode abilities of your chosen framework,
language or operating system. If you haven't tested it, it doesn't work

~~~
cfq
Here's a real life scenario:

1) Develop a project in a rush

2) Becomes successful

3) Boss/Client decides to launch it in 2/5/10/22/34/82 countries

4) Project becomes one big hack

One simple Unicode test and 10 minutes of initial thinking would've saved all
this trouble.

------
_delirium
> We can’t recommend this enough: reuse the same template for all language
> versions

This can get quite tricky, because languages don't easily map onto 1-to-1
items that can be just translated independently and stuck into a template. See
the classic "localization horror story": <http://interglacial.com/tpj/13/>
(and HN discussion: <http://news.ycombinator.com/item?id=2095334>)

~~~
pornel
It's not a problem of HTML, but the method you use to construct translation
string key names.

If you have `<button>file</button>` and use it in both "[file] a complaint"
and "save to a [file]", then you're in trouble indeed.

But you can fix that by adding context to translation keys in the template,
e.g. in TAL you can do `<button i18n:translate="'file (verb)'">file</button>`.

~~~
_delirium
It's not just an issue of polysemy (that "file" means two different things in
English), but that the structure itself may need to be different in different
languages, because languages have different grammars, and different ways of
dealing with objects/numbers/etc.

In the example I linked above, there's a whole mess of rules to capture if you
want to handle singular/plural correctly in different languages, including
those that distinguish more cases than singular and plural. It boils down to
the fact that word-for-word translation doesn't work in all but the simplest
cases: you can't translate "[a] [b] [c] [d]" by having 4 lookup tables for
[a], [b], [c], and [d] and then plugging them into a template independently.

------
jontsai
Oh yes, this is tremendously fun! I worked on i18n/g11n/l10n for Y! World Cup
and other games

Compare: <http://us.wc.fantasysports.yahoo.com/>
<http://hk.wc.fantasysports.yahoo.com/>
<http://tw.wc.fantasysports.yahoo.com/>

It's a tremendous amount of work, and you have to identify translatable
phrases AND contexts, not just strings and words. Websites that plan on
catering to multiple languages and regions should incorporate i18n from the
beginning, not an afterthought, which would require going through lots of code
with a fine-toothed comb =)

------
peng
If i18n is a priority on your project, make sure you show your designer(s)
this article. With the current trending emphasis on grids and horizontal
rhythm, left-aligned labels are quite fashionable.

An effective bandaid solution is to set left-align labels to text-align:
right; thereby visually linking the variable width label to the field.

------
st3fan
Good to see that Hacker News deals correctly with those beautiful glyphs :-)

~~~
Dylan16807
It's pretty hard to screw up copying a string from one place to another
without modification, at least when it comes to encodings without null bytes.

Some programs manage it somehow, though.

~~~
st3fan
You will be surprised actually how many web apps get this wrong.

------
pud
Good article. Now can anyone recommend a service for replacing the copy in a
site with copy in different languages, so I can use my same templates?

Like Google Website Optimizer, but replaces strings with the appropriate
language.. ?

------
itsadok
I'd be interested in knowing what made them write that IntelliJ IDEA provides
"decent solutions for bidirectional editing", considering that JetBrains'
Dmitry Jemerov has specifically said that they don't see the business case in
supporting RTL editing:

<http://youtrack.jetbrains.net/issue/IDEABKL-5572>

------
onetime123
I just want to point out that the title uses a letter which doesn't exist in
any language: t with a cedilla. It's a Unicode fuck up which plagues the
romanian language to this day. Not just on computer systems, in real life too!

------
DiabloD3
Nothing like early morning Unicode abuse. ;)

------
Mafana0
I'm a web developer with experience of technical editing, a native speaker of
Arabic, have translated many popular Firefox extensions to Arabic, and worked
in "Google in your language" project, since I speak English and German
fluently. I'm willing to help any HN member who wants to localize his
startup/website to a RTL language, for free. If you contact me, I will gladly
review the Arabic localization and RTL design and help you with the
globalization in general in my spare time. As a thank you for the community
I'm a big fan of.

