Pull all strings out and into a single js file for localization

http://openlayers.org/pipermail/dev/2007-July/001017.html

added patch for i18n support.

Language is automatically set from navigator.language value, but I couldn't find a way to get access to the accept-language request headers in the client. It seems these are only available on the server.

Not sure if the French strings file is encoded correctly in the patch. These strings files need to be stored as UTF-8.

updated patch to include support for regional language codes (e.g. en-CA), added NaturalDocs comments, added a test case for the translate method

Thanks for the work on this Mike. I've got some general comments I'd like to discuss - perhaps in IRC. Regarding this patch, what do you think about using the existing OpenLayers.String.format instead of introducing the formatMessage function? Then your translate signature could look something like:

OpenLayers.String.translate(key, context);

Where you'd have "named args" in the context instead of positional ones. In long templates or in templates that want to repeat a variable, named arguments are a bit handier than positional ones.

In addition, I wonder if we can have an i18n function right in the OpenLayers namespace. So, the following would do the same as your current translate:

OpenLayers.i18n(key, context);

Finally, I do like the suggestion that we tack dictionaries on to individual components. This is what I'd like to discuss more on IRC. I do see value in having a global dictionary, but I also think it makes sense to maintain translation relative to some context. As a simple example, one control may want to capitalize "Layer" and another might want to print "layer". We have to have a whole lot of forethought to pick keys that make sense in all cases. This job becomes easier when your context is limited (to a single control).

I think a static property on classes that use strings makes sense. If others like this idea, we could have an i18n method on all classes. If an instance comes from a class with a static "lang" property, then its i18n method looks there. If that property doesn't exist, i18n falls back to the global dictionary. Then your calls to translate (in code that belongs to a particular class) is shortened to:

this.i18n(key, context);

An alternative would be to stick "lang" properties on the prototypes. Then we'd get inheritance (with all it's blessings and curses), and people could customize strings by setting their own "lang" property in the familiar options argument to a constructor.

Personally, I like the name "lang" or OpenLayers.Language over OpenLayers.Strings. Would be good to get a chance to discuss again on IRC.

updated patch to address some comments above: - now uses OL.String.format with hash argument instead of positional template

Others can add an OpenLayers.i18n alias if desired.

As discussed on IRC, adding i18n to individual classes to be deferred to later releases

I like the namespace OpenLayers.Langen?, etc. to store the data. That seems like a saner place to put them; the "Event"/"Events" dichotomy has hurt us in the past, and I'd like to not repeat that mistake.

moved OpenLayers.Strings to OpenLayers.Lang

Thanks for your work on this madair. I'm reviewing now.

reworked i18n patch

Ok, I've reworked this enough that I'd like another set of eyes on it for a review.

I moved everything relevant to i18n into the OpenLayers.Lang namespace. This adds the following to our API:

• OpenLayers.Lang.defaultCode - Default language code.

• OpenLayers.Lang.setCode - Used for setting language codes. With no argument, you get the browser default, or if no dictionary exists for that, you get OpenLayers.Lang.defaultCode.

• OpenLayers.Lang.getCode - Used to retrieve the current language code.

• OpenLayers.Lang.translate - Used to look up a key from the current language dictionary and optionally format based on some context.

• OpenLayers.i18n - Alias for OpenLayers.Lang.translate

The reason to add the accessor method was to have it run only once per language code change. In the previous patch, the language code selection was run once for each translate. I also like the idea that all this goes in the Lang namespace instead of being split between Lang and String.

I've also cut down the dictionaries so they only contain relevant keys. To add to a regional dictionary, we can inherit from the primary.

I think this is good to go. Additional review appreciated. (Tests pass in FF/Safari.)

I am totally convinced that this is now as it should be. Plus, it can easily be expanded later to also do some l10n stuff, using OpenLayers.Number.Format (e.g. for the scale).

Thank you madair and tschaub for the great work!

There might be problems with the single-file build, so I uploaded a new patch that adds a @requires for Lang/en.js to OpenLayers.js.

I saw that the patch pulls out /some/ console messages, but not /all/. I think this is ok. In my opinion, console messages do not have to be translated at all, because the user will not see them. In my new patch all language resources that are only used in console messages are commented as //console message. The idea is that contributors who want to create language files for other languages do not have to translate those.

I hope you agree with those minor changes. Feel free to commit.

(In [6313]) Adding framework for internationalization support. The new OpenLayers.Lang.translate method takes a key and looks for a value in a dictionary based on the current language setting. Set a new language code with OpenLayers.Lang.setCode. Get the current code with OpenLayers.Lang.getCode. Thanks to Mike Adair for the lead on this one. r=ahocevar,me (closes #109)