Internationalizing a web application

1
votes

Not sure if stackoverflow is the most appropriate place for this question.

I am currently building a web application that will manage content, ecommerce and allow users to participate.

I am using php's intl extension to deal with different number formats and so on. gettext will be used to provide translations of the actual text in the application.

This question isn't really a technical one, but more as to how the user sets the language/version of the web app.

I have came up with a possible scenarios:

  • (Country regions) User selects his country and this determines his language. If the language for his country is not avaliable, default to default language.

  • (Language) User selects his own language, and he selects his own country/time zone settings. That means we can have users in say the United states reading content in Japanese.

With the first option, obviously it is quite fool-proof. The user claims he is from canada, so we display the content in english (en_ca) or french (fr_ca if avaliable).

However, not every web site built on top of the application will be big enough to warrant translations based on locale (i.e. canadian french (fr_ca) vs french french (fr_fr).

Some site would be quite small, so it doesn't matter where the user comes from, he should be able to select either French or English when browsing the site. However, this leads to another issue. If the user selects the content to be shown in french, how do we format things like numbers and currencies? We cannot directly infer his locale from the language he has chosen.

I have looked around the web at some "big" websites to look at how they do things.

  • Amazon - (Country Regions) Different sites for different countries, i.e. Amazon japan is only avaliable in japanese.
  • Microsoft - (Country Regions) Some countries have multiple languages. (fr_ca) vs (en_ca).
  • Engadget.com - (Language) English, Japanese, Chinese (both simplified and traditional).
  • FaceBook - (Language), but offers different versions of languages (fr_ca and fr_fr)

So I guess the question is, should I force all users of the web application to build their content around the countries/regions or languages? Or should I allow both scenarios?

Cheers :)

2
phplocalizationinternationalizationmultilingual
I think you should allow both scenarios, place yourself as the user and find out what you would like the most. For me personal I'd like it to go fully automatic based on my location, but customizable aswell as how I want to view the website. – Sander
You might get good answers at ux.stackexchange.com – Carson Myers
I have a feeling that is the case, is there any way I can move my question there? – F21
@phpdev I don't think so – Carson Myers
Something I really hate is when a site automatically chooses Norwegian (since I'm in Norway) and it gives me no way of switching to English (which is what I usually prefer on the web). – Svish

2 Answers

2
votes

As a professional localizer, I reccomend "language" if there is no difference in content.

The reason why Amazon or MS ask for country is that the content is different for each territory. For stuff that is not available, say in Japan, why would they want to translate it to Japanese? Plus it's misleading to the Japanese reader, even if they are on the US site.

On the flip-side, if you offer Country as the selection, then users may expect to see different content based on the coutry they choose, and that might be misleading.

These days a lot of people are mutli-lingual so if the content is the same, defaulting by location then offering the language selection on top is more user-friendly.

I hope my thoughts might help. This is a tough question and depends on many factors - there is no 'right' answer. :)

0
votes

We did something similar to this in our web app. We essentially just used the currency format of the "home" country for the language. So, if they choose French, they get France's formatting. German, Germany's formatting, etc. It won't always be the correct one but for our app we haven't had any complaints yet, so I assume that works the best if your users aren't too picky. We have a decently small userbase, however (<= 1000 visitors per instance of our app), so you may want to take this advice with a grain of salt ;)