One thing that is really frustrating to deal with is localization. There is nothing funny about localizing text from your application. But this is a necessary step when you want to go for very a broad market in multiple languages. So while your there, why not having a localization infrastructure in all your front-end.

Most PHP frameworks and JS widget libraries can now be easily customized as far as localization is concerned. However your bound to have some string messages in your javascript modules. Not thinking about the localization of these little pesky messages leads to painful hours of looking through every files to find some strings that have not been localized.

Consolidating your localization architecture

Okay your widget has 2 or 3 files, each for one language, that’s a start, but why not centralized all that on the front-end? The idea here is to create one one or multiple objects, that will handle all the localization for your application.

Meaning that in your javascript application code, instead of actually writing down the localization, you will be doing a look up using a function to a single object that will be containing every language localization for this string. That also means that you need to set a variable with the current language your app is in.

Let’s try to be a little bit clearer

Here is what we are going to do.

1. First we need a way of knowing your current language state. It could be a javascript variable outputted form your framework or an attribute on your body tag, that you will store in js, for exmaple:

<body lang="fr">

of simply

currentLanguage ="fr";

2. Create a JSON object (or multiple) with all your languages translations

var globalTranslations = {
		"myquote": "English quote"
		"myquote": "Quote en francais"

The idea here is to use the current language and fallback to english if some strings are missing. So a good idea could be to separate the object in separate files per language and only load the english localization and the _insert current language_.

3. A central function that will route all messages to the current language state.

This part is little bit more complicated but, the idea is that when you need a string, your going to call the function like this : tools.getLocalisation(globalTraductions[currentLanguage], [‘validation’, ‘required’])

For example, this would look in your object for globalTraductions.en.validation.required node. The way getLocalisation is written, if the string is not found, it’s going to default to the “default language” (currently English), and if this is still undefined, it’s going to actually output the object lookup (in this case: validation required)

Download the source code View demo

That’s it

Following this pattern you never create javascript error with undefined properties, and it can also default to English or to a, somewhat, understandable state. Hope it can help you guys get your localizations going!

9 thoughts on “Managing string localization in javascript files

  1. Nice!
    One comment: usually, you don’t want to load all your “traductions” string (in traduction.js), you only load one language, for performance reason. But I guess that if you split your traductions.js file into 2 files (traduction.en.js and and only load the language you need, it will still work, right?

  2. “Complicated” seems a bit of an understatement; do you really write all that function everywhere you need a localized string?
    I’m doing this somewhat differently. First of all the proper place for the lang attribute should be the HTML element, so that it applies to the page title and META stuff too. Next step is to declare an empty ‘var lang = {};’ at the top of my script; at document.ready the script reads out the declared language, makes an Ajax call to the server with that language as a parameter and gets in return a JSON response containing the localized strings, storing them in ‘lang’. Done that it’s just a substitution task: every string in the original script is replaced by lang.name_of_string.

  3. @Saad yea that would still work, It really depend how big is your object and how you want to handle it.

    @Dejan Well the idea is to write once and never touch your localized string again, I do call this function each time, tested it in dynatrace, it take less than 1 ms to retrieve a string in ie8.

    My script is for string localization in javascript files (like form validation errors), we do not use that stuff for page title and meta, or anything like that, this is handled in the back-end.

    But you know, your way of doing seems to fit perfectly what you need, so that is cool too 😛

    Our setup is a bit user driven, and we might have missing strings in spanish, so we want that english take over if the spanish version is not there.

  4. How does SEO fit with javascript-based localization? Search engines from multiple languages will not index well in that scenario. I prefer javascript or specifically jquery to server-side any day but not realistic other than for messaging that is non-seo.

  5. You should not use this method with website content.

    This is specifically for text in warning messages, and text string across your javascript files

Comments are closed.