The WebApp Wizard Web development made magical

24Aug/107

Why I don’t localize my jQuery plugins

That's a question (I know, the title is actually the answer to that question) I've asked to myself yesterday. I mean, why do other people deliver jQuery plugins in a full-featured package, including localizations, and I don't? Take jQueryUI and the datepicker date formats for example.

At the beginning, I chose to deliver only the jQuery plugin file, and from now I will prefer to deliver a little package containing a full example (HTML + JS + CSS + PHP - if needed -). But I don't plan to deliver localizations, more than ever.

Why?

First, I don't pretend to know other languages than French well enough. That's already difficult to find the right words in your own language when it comes to describe really shortly, often in only one or two words. I prefer to let you do this job, you will probably be better than me. :-) I release my plugins in English by default (and not French) only to make sure most people will be able to understand.

Second, I have always found that already localized plugins were difficult to blend in an existent architecture. Mostly, localized plugins provide simple javascript files containing variables corresponding to the different strings, in each language. What if you want to get the data from your server? What if you want a more dynamic way to do that? And even when you're in a simple-javascript-file flavor (which I personally like), you've got work to do by yourself. Maybe you want to get all your localized strings in the same place, or maybe you would have organized that another way. OK, all that is not that difficult, but it's always a little pain anyway.

That's why I only set the basics for internationalization. All the user-displayed strings in my plugins are customizable, so you can simply pass the localized strings in parameters. The way you get these localized strings is your business, even if I do recommend a few ones.

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.