Introduction

Last day, we began talking about i18n (Internationalization) and L10n (localization).
Internationalization was adding to an application the ability to process international texts.
Localization was making an application work for a given locale, where a locale was a set of preferences which might include language, region, time zone, number display, currency, etc.
We said how Unicode could help with Internationalization.
We explained how UTF-8 works, how to get UTF-8 to play nice with PHP, Mysql, and Javascript.
Today, we are going to look at some aspects of Localization.

Text Direction

One preference which varies from locale to locale is text-direction.
For instance, English, French, etc are left to right languages, Arabic and Hebrew are right to left languages. Some languages like Chinese and Japanese were traditionally top down and right to left.
Ancient Egyptian hieroglyphics used both directions: An inscription around a door might be left to right on one half of the door; right to left on the other half.
Eye-tracking studies have shown that the text orientation that a person is familiar with will affect how that person's eye saccade across a new image.

Text-direction: HTML and CSS

There are several things in HTML and CSS that can be used to affect the text-direction.
The <html> tag can have a dir attribute with value (ltr or rtl) as well as a lang attribute (for example en-US) to help fix the locale.
In CSS, you can set the text-align attribute to right to get the text to align to the right hand side of the screen.
For a general tag, you can also set the direction attribute to either ltr or rtl affect the order in which punctuation is written.
Unicode itself has some code points which can be used to affect text-direction. For example, U+202A,... U+202D. However, these don't work well with browsers.
Instead, you can use the unicode-bidi style attribute (which can have values: normal, embed, override) in conjunction with the bdo tag.

For example,

<p style="direction:rtl; 
unicode-bidi: bidi-override; 
text-align: right" ><bdo dir="rtl" >
This is a test.</bdo></p>

would look like:

This is a test.

If your browser supports CSS 3, there is another style directive block-progression which controls vertical alignment.
It can have values tb for a top to bottom alligned language like English, or rl for a language like Chinese or Japanese, or lr for a language like Mongolian.
Usually, you would have a separate CSS file used for each direction you want. Or you could have a class selectors like html-ltr, html-rtl to control it.
You would also in PHP, based on the locale set the dir and lang attribute of the HTML tag.

gettext

We next look at how we could set up the development environment of our web project to allow for text from more than one locale.
We will first look at how to manage static text.
One common tool to use to do this is gettext.
There are also some open source tools such as Pootle with web interfaces for managing the kind of files used with gettext.
The basic idea of gettext is that the developer whenever they need to output a string that might need to be localized they call a function gettext() with a string which says what needs to be translated. For example,
```
gettext("translate_me"); // you could also use _("translate_me");
```
The function gettext uses the current locale, textdomain, bindtextdomain to locate a .mo binary file which contains a string write for "translate_me" for that locale.

So you might have in your html file commands like:

setlocale(LC_ALL, 'en_US'); // say locale
bindtextdomain("myMoFile", "./locale"); // say locale dir
textdomain("myMoFile"); // say .mo file
_("translate_me"); // looks for ./locale/en_US/LC_MESSAGES/myMoFile.mo
                   // to find the translation.

How do we create .mo files? .po files

There are a few steps to create a .mo file for a given locale.
First, we have to extract all the things we need to translate from a given file.
To do this we use the command xgettext:
```
xgettext -L PHP filename.php
```
This will generate a messages.po file. If we want, myMoFile.po we could have done: -d myMoFile

Inside this file we have lines like:

#: filename.php:6
msgid "translate_me"
msgstr ""

You would give this file to your localizers to fill in a msgstr to translate each msgid.

From .po files to .mo files, more on msgid's.

Once we have a fully translated .po file we are ready to generate a .mo file from it.
To do this we use a command like:
```
msgfmt -o myMoFile.mo myMoFile.po
```
We then place the .mo file in the correct directory and we have one file translated to one locale.
It can become hard to maintain if you use msgid's which are just English strings.
It would be bad if several files in your project had the same msgid "Next"; and where next might be translated in different ways to a locale depending on context.
Instead, you should a naming convention for id's which specifies things like: namespace_pagename_name_additional .
gettext has support for things like pluralizations, and messages that involve formatted text that I will not go into.

Dynamic String Translation

gettext has the advantage that it is fast.
Unfortunately, it doesn't work well in situations where you are dynamically adding new things to your application which need to be translate.
For instance, you might have a web form through which employees add new products and descriptions.
These description still need to be translated.
To handle this, you probably would need to go to a slower approach involving using an SQL database.
You might have a table of Products with ID as a key and another table Locales which have a LOCALE_ID and LOCALE_STRING (ex: en_US).
Finally, you could use a table like with columns like: ID, LOCALE_ID, TRANSLATION to store the given locale's translation of product information.

Localization

Outline

Introduction

Text Direction

Text-direction: HTML and CSS

gettext

How do we create .mo files? .po files

From .po files to .mo files, more on msgid's.

Dynamic String Translation