The WebApp Wizard Web development made magical

24Aug/101

How to localize your JS

i18n (internationalization) and l10n (localization) are two major concerns in today's web. And JS isn't an exception to the rule. So here I propose a few ways to manage that essential task.

Simple JS files

The way I generally use. A single file per language, containing all the translated strings for all my JS. Variables respect the naming convention: "i18n_english_word", to distinguish them from other "standard" variables. Looks like this, for a French translation example:

<code>
var i18n_ok = 'OK',
    i18n_cancel = 'Annuler',
    i18n_yes = 'Oui',
    i18n_no = 'Non',
    i18n_close = 'Fermer';
</code>

I usually suffix the filename with "_fr_FR.js" for a French translation file, "_en_US.js" for an American English translation file, and so on.

I use this technique because I usually don't have tons of strings to translate in my JS code, so it is sufficient. Moreover, there is absolutely no overhead on server side, compared to the other solutions I present here.

Getting data from your server

I would say that in most cases, that's clearly overkill, and it will slow down quite badly your application. Just do some Ajax requests to get the translated strings. The advantage is that it blends totally in your server-side localization architecture. You can get the same translations as the ones you get in your PHP code from your database for example.

I am really not a fan of this solution.

Generated JS files

Maybe that's the best compromise. It would consist of a PHP script that generates the JS file we were talking about in the first section of this article. That PHP script would be "included" as a JS file in your HTML, like any other JS file, in a <script> tag. For the experience to be more seamless, I recommend you add this in a .htaccess file, or in your Apache configuration:

<filesMatch ".js$">
    AddHandler application/x-httpd-php .js
    php_value auto_prepend_file "jsheader.php"
</filesMatch>

jsheader.php would then contain at least the following, and would be located in your document root (or wherever you want as long as it is in the PHP include path):

<?php
header("Content-type: application/x-javascript; charset: UTF-8");
?>

All this will make your JS files interpretated by PHP. I guess that causes a small overhead on server side, but I think that's worth it. You can now write your blah_fr_FR.js with something like this:

var
<?php
$strings = getTranslatedStringsForLanguage('fr_FR');
$vars = '';
foreach ($strings as $s) {
    $vars .= $s->i18n_id . ' = ' . $s->translatedText . ', ';
}

// Delete the last ', '
$vars = mb_substr($vars, 0, mb_strlen($vars) - 2);

echo $vars;
?>
;

This will generate a file like the one we saw at the beginning. As Apache is told that .js files should be interpretated as PHP, that works perfectly fine. And as it is still a .js file, which is generated with the right headers, it is totally seamless from the browser/webdesigner point of view.

Yes, you ask to generate a file to be included as JS, and, depending on your architecture, that could take some time. But using simple caching techniques, this overhead can become insignificant. I encourage you to see what Steve Souders has to say about website performance.

I think we found a pretty elegant solution here. :-) Comments are very welcome to share different techniques.

Comments (1) Trackbacks (1)
  1. If you’re interested to localize software, I warmly recommend the web-based localization platform http://poeditor.com/


Leave a comment

(required)

You can use basic HTML to enlighten your comments. If you want to post some code, please use the <pre> tag. You can also use syntax coloring by adding class="syntax [language]". <pre class="syntax js"> will color your code as if it was JS code for instance.