How Are You Accomplishing Your i18n?

cobrabyte asks: "My team has recently been given the task of implementing internationalization (i18n) in our MySQL databases (PHP-interfaced). Essentially, for every article X, we need it presented in any number of languages (once translated). As we were working on gathering the necessary procedures, we were very surprised to find that there's not much organized information regarding i18n using MySQL and PHP. Is the topic of i18n too new to garner any usable info?"

Comments

How Are You Accomplishing Your i18n?

[pyrrhonist]

How Are You Accomplishing Your i18n?

By p09g.

Have your looked at PEAR?

[33degrees]

I haven't tried any of them, but PEAR has a number of packages for dealing with internationalization. You might want to try looking there for insight.

i18nHTML

[Mind Booster Noori]

Well, I think you're looking for this.

That's not just i18n.

[truedfx]

My team has recently been given the task of implementing internationalization (i18n) in our MySQL databases (PHP-interfaced). Essentially, for every article X, we need it presented in any number of languages (once translated).

Let's check that link, shall we?

The distinction between internationalization and localization is subtle but important. Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale. Subjects unique to localization include:

* Language translation,

Re:What's the question?

[plcurechax]

-without using some crappy 'BabelFish' layer

Ask any government that supports multiple official languages (Canada, Switzerland, ...). You translate into the other language(s) using professional translators. Period. You can give them the most powerful automatic translation tools available, and multiple language dictionarys (e.g. English-French) but in the end you need a human professional translator to make translations worth reading.

-without having to write a complete localized version for each language.

You need to make the content management system (CMS) language aware, and you need to localize all your templates. Then you need to add a key to your article database for language, so the user can retrieve article 101 in either english or french. (think a long the lines of http://localhost/cms/display.php?article=101&lang= en ).

I know nothing about PHP programming, so I cannot comment on that, or MySQL (main gotcha I expect is datatype, UTF-8, iso8859-1, vs. windowspage1574). Two articles I found useful in general about internationalization are

UTF-8 and Unicode FAQ for Unix/Linux by Markus Kahn
How do I have to modify my software?
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
http://www.joelonsoftware.com/articles/Unicode.htm l

Smarty + preparse plugin

[DamienMcKenna]

I did this in 2003 for a CMS+ecommerse system I did for a company. You had Smarty templates which had things like {productstr1} in them. The text strings were referenced by language and string ID, and if the string didn't have a specific version for your language it defaulted to English. This string was loaded from the database in a preparse plugin and was cached in a per-language directory. It worked ok, a bit kludgy but sufficient to get the job done.

Damien

It is just you

[bluGill]

The problem is you speak English. There is a good chance that you speak no other language. Since nearly everything is written in English first these days, you don't care about these issues.

Many of those who care about i18n do not speak English at all! To these people even spelling the word out gives no help. In fact it is less helpful because they have to learn this large symbol. (There is no reason to assume they even know the Latin alphabit, so they will not think to learn each letter separately)

Of those who speak English, many do not speak it fluently. Often they speak English as a first year student ("hello, my name is"), and they know how to look words up in their English-whatever dictionary.

Of course English is the dominate second language in the world. There are plenty of people who speak English fluently as a second language. They often have trouble with the creative spelling English came up with. Words with 20 letters are hard for anyone to spell, so it would be no surprise if they have trouble spelling it.

The goal is one symbol that is easy for everyone to recognize. No matter what language the page is written in, if you see "i18n", you know you are in a location where people are interested in translation. This is often enough for some educated clicking to find the same information in your language.

i18n may not be a good abbreviation. However can you come up with a way to represent the concept to all 6+billion people on earth?

Re:It is just you

[pla]

Of course English is the dominate second language in the world.

In IT, English holds the majority by far. And Spanish doesn't even come in second - You have Japanese and German as distant seconds, with Hebrew and French as dark-horse thirds.

Attempts at internationalization simply hinder the adoption of English as the next ubiquitous academic language. Much like Greek and Latin during the Roman empire - The rabble may all speak Spanish, but those who want to appear educated speak English. Of course, Latin later went on to hold the same place, so perhaps some day Spanish will function as the language of the academic elite.

Personally, I don't have great hope of us not blowing up the planet before then. So I code with English as my target language. Speak it, or don't use my programs, doesn't much matter to me


Many of those who care about i18n do not speak English at all!

I don't think that needs an exclamation mark - It doesn't come as a particular surprise to anyone. If you speak English, you don't have the least interest in "internationalization", which basically means "Make it accessible to people who don't speak English".


And I don't write this as a xenophobic rant... I regularly use programs written by Japanese coders, and a few in German. And do I sit around complaining about how those coders, who already have given me something I find useful, should do extra work unrelated to the purpose of the program to make those programs more friendly to me? No. I recognized my inability to read the menus and such as a shortcoming in myself, and made the effort to learn enough Japanese and German (albeit very little) to navigate those programs.

Or to put that another way - If Bill Gates only spoke Italian, a LOT more people would have learned at least a basic proficiency in it by now.

Some answers

[JavaRob]

I18n/localization is one of those tasks that has *lots* of questions that will need to be resolved... often you won't even know about all of the issues to resolve until you start digging into it.

I sorted out the i18n design for a project recently, so I can share some insights on the process. My project used Java/JSP, but the problems are mostly the same. One of the most important points to be made is that you *need* to sit down and design it all the way through -- this is not a "feature" that can be easily added in when you need it later (and extreme programming teams can get hosed on this one pretty easily).

Things to consider (in the sequence of a request for simplicity's sake):
1) How will you know what language a user wants (first time, and on subsequent pages)? The user should be able to select/change their preference (though you could use their browser-reported locale as a guess), and they should be able to *bookmark* the homepage in their language. You could use a cookie, and redirect from the basic homepage based on that. Personally I avoid depending on cookies where possible, I didn't want to have duplicated directory structures, and I didn't want an added param on every request, so I used multiple *subdomains*, one per supported locale. They all mapped to the same IP, same application -- but in the web application I could check the requested URL and set the locale (and build the page) correctly using that. There were links on the top of the homepage to switch languages -- which would just flip to the proper subdomain. (Important note -- this complicates getting a cert for SSL, since that's tied to the domain... keep that in mind).

Once you know what language you're using, build the page... this will probably involve getting data out of the database and displaying some of it.

First, make sure your tables support whatever character set the languages will need. Then make your data design carefully. You need to make sure that any data in the database that will show up onscreen: product descriptions, category names, and ALSO prices (you probably have to give prices in various currencies, right?).

Building the page -- you'll need more PHP-specific advice here, but the idea is that you need to get text and possibly images that are language-specific for each page. The general choices are:
* Use a single PHP file for the content (e.g., a form for registration info), and get the text displayed from locale-specific files (so for the "name" label over that field, you'd grab the proper translation).
* Maintain a separate PHP file for the content in each language, plug the proper one into the template.

The first option is better if your content is mostly short bits of text -- but if there are larger chunks of text it gets hard to read (and if the whole page is text -- like a privacy policy page, etc. -- the second option may make more sense). Personally, I supported both options.

What else? Don't forget that formatting of currency, numbers, dates, and times will vary by locale. Don't forget to review any Flash animations, dropdown menus, popup calendars, etc.. these will need to support changes based on locale. Organize your resources carefully, so that a simple substitution in the path will get you the right image, content file, etc. (e.g., images/fr_CA/whatever.gif).

HTH.