views:

134

answers:

4

I have a web application that uses TONS of javascript, and as usual, there are a lot of textual constants that will be displayed to the user embedded in the code itself.

What do you think is the best way to make this localizable?
I know I need to take those strings off of the code and replace them with constants, which will be defined into some external place.

For the server side, ASP.Net provides some very neat capabilities for dealing with this.
What's the best to do this in Javascript?

The best idea I have is to have a JS file with ALL the string constants of the JS of the site (i'd have different copies of this, for each language), and then on each page, I include this script first, before all the others.
This seems like the most centralized way, that also wastes the least bandwidth.

Are there any other better approaches?

Thanks!

+1  A: 

There is a gettext library but I haven't used it.

Sinan Ünür
+1  A: 

Your approach sounds good enough.

If you have lots of strings and you are concerned about the bulkiness of the file you may want to consider a script that creates a single javascript file for each language by concatenating the code javascript and the locale javascript and then applying something like Minify.

You'll waste some CPU cycles on publishing but you'll save some round trips...

Sorin Mocanu
Interesting. I'm already doing the concatenating / minifying of JS files, so this makes sense.
Daniel Magliola
+1  A: 

Your approach makes sense. Details:

I'd have the strings for each language in an object.

localized={"cat":"chat","dog":"chien"};

Then in code:

localized["cat"]

The quotations around of the keys and the array notation (rather than the more common object dot notation) are to avoid collisions with JavaScript reserved words.

Nosredna
The main problem with that is that if you give the "resource" file, in this format you mention, to a translator, you are GUARANTEED to get something back that will throw a syntax error. var strCat = "chat"; is not much better, but at least it's easier to locate the error, and an easier syntax to understand by the translator.I do like how you're wrapping them in a namespace, though, I'll see if I can find something with "the best of both worlds".
Daniel Magliola
The translator never needs to see the JSON. You can convert from the data file to JSON.
Nosredna
Yep, that's how we did it. All translated messages are stored in a namespaced Object. labels = { errorMessage: "foo", confirmMessage: "bar"}
ajm
+2  A: 

here's how we did it (in ASP.net), pretty much along the lines of what you've mentioned: 1) Created two javascript files: one which defines all javascript functions/DOM manipulations as required by the site, and, second called Messages.js: this defines all the string literals that need to be localized, something like var ALERT_MSG = "Alert message in english".

2) Created different version of the Messages.js, one for each locale that we are supporting and localized the strings. The localized js files were named using messages.locale.js naming convention (for eg. messages.fr-FR.js).

3) Included the js files within the "ScriptManager" and provided the ResourceUICultures for the Messages.js file: this ensures that the correct localized file is embedded in the html output (if you are not using ASP.net you can build this basic functionality by doing some culture sniffing and including the appropriate js file).

4) Voila!

Sachin