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:

putenv('LC_ALL=en_US');
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
At the top of this file there is a place to set the text encoding. Make sure to set this to UTF-8!

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.

Coding Practices

For the remainder of today I would like to go around the class and look at people's HW3 solutions.
I will try to suggest ways that your code should be improved for the next homework.
I am hoping individualized suggestions will be more impactful than if I spend too much time up here saying what to do differently in general.
That said, the next slide has some general comments.

General Coding Comments

In most settings, you will need to deploy your app at least twice -- once on your own machine, once on your deployment machine. You want your code to be as portable as possible.
You want to catch errors which can trip up deployment on various platforms and minimize time to understand and integrate new code if multiple people are working on your project.
So follow a set of coding guidelines for each language used in your project. For example, you can use the coding guidelines I developed for my own projects.
Make sure every method you write is commented. Use PHPDocs for PHP.
Do not be schizophrenic in how you name variables/functions/methods/classes. Follow the convention of your coding guidelines.
When coding in PHP make sure you have error reporting set to the highest level (-1). You can check this by making a small file like:
```
<?php $blah++; ?>
```
You should see a notice saying blah is undefined.
Test on at least two platforms. For example, Windows and OSX or Windows and Linux.
Make sure your code does not generate any notices, warnings, or errors.
Do not be sloppy initially and hope that you will go back later to fix issues -- you almost never have the time/energy to go back later. If you are aware you are doing something sub-optimally, re-code it then and there.

PHP Guidelines

Avoid require or include commands within methods or randomly in your PHP documents. Put them at the top of the given file, try to use require_once, and try to avoid using variables to say what to require.
Do not write much code out of a function or method. If you are using the MVC approach we've been discussing for the HW's then only index.php and config.php should have code that is not inside a function/method/class.

In particular, use PHP's copy mode only within a function:

class Layout
{
    var $view;

    function __contruct($view)
    {
      $this->view = $view;
      //contructor code
    }
    function render($data)
    {
      ?>
      <html>
      <head><title><?php echo $data['title']; ?></title></head>
      <body>
      <?php $this->view->render($data); ?>
      </body>
      </html>     
      <?php
    }
}

This avoids headaches such as sending HTTP headers from a sessions after some HTML has been output.

Make sure to de-reference associative arrays correctly:

echo $my_assoc['my_field'];
//not
echo $my_assoc[my_field];

Always use Unix paths not Windows paths -- on a Windows machine PHP auto-converts from the former to the latter. On a *nix machine though, PHP won't convert Windows paths to *nix.

Localization, Coding a Web Application

Outline