[OpenLayers-Dev] OpenLayers Internationalization

Steven M. Ottens steven at minst.net
Fri Jul 13 04:33:43 EDT 2007


Hi chris,

Gertjan wrote the i18n support for mapbuilder, so it might be 
interesting to discuss it with him as well.
We use a mbGetMessage function (/lib/util/Util.js) which gets called 
with either just the message key or together with some extra parameters:

alert(mbGetMessage("noTargetModelTool", targetModelName, toolRef.id));

corresponds with:
<noTargetContext>Error finding targetContext: {0} for: {1}</noTargetContext>

All the strings are located in a widgetText.xml document, which is 
located in the skin/<lang>/ folder

Regards
Steven


Christopher Schmidt wrote:
> Couple questions for internationalization:
>
> Current strings included in the OpenLayers Library which are likely
> candidates for i18n (incomplete):
>
> Ajax.js:37:    alert("Unhandled request return " + request.statusText);
> Control/OverviewMap.js:537:                alert('The overview map only
> works when it is in the same projection as the main map');
> Format/GeoRSS.js:124:          alert("Couldn't parse " +
> geometry.CLASS_NAME);
> Format/WFS.js:126:        if (!feature.fid) { alert("Can't update a
> feature for which there is no FID."); }
> Format/WFS.js:161:            alert("Can't update a feature for which
> there is no FID."); 
> Format.js:42:        alert("Read not implemented.");
> Format.js:56:        alert("Write not implemented.");
> Layer/GML.js:129:        alert("Error in loading GML file "+this.url);
> Layer/Vector.js:172:            alert(message);
>      var message = "Your browser does not support vector rendering. " +
>                    "Currently supported renderers are:\n";
>      message += this.renderers.join("\n");
>
>
> Layer/WFS.js:376:  
>             this.commitReport('WFS Transaction: SUCCESS', response);
>             this.commitReport('WFS Transaction: FAILED', response);
>                         
>
>  * How much support do we need for interpolation in text? I think that
>    the answer for this at the moment is "none" -- that is, all
>    translated text will be literal, exact matches for the time being,
>    with no interpolation of variables into the middle of strings. This
>    may change in the future. Depending on how it changes, more complex
>    support for pluralization may also be needed. For the time being, I'd
>    like to ignore all of this and just pretend that we want simple
>    string translations unless someone tells me otherwise.
>  * In general, translation libraries use a short function name to
>    indicate "translate this string." (I think a common use in C is the
>    "_" function, via the gettext library or what have you.) In
>    OpenLayers, we try not to squash other people's namespaces. I'd like
>    to use OpenLayers._ for translation, as opposed to
>    OpenLayers.Strings._ or something similar.
>  * I think the simplest thing to do is to have a single Javascript file
>    with the Strings in it (lib/OpenLayers/Strings.js), and a default
>    language. Then, to change the language, all you need to do is
>    something like:
>
>      OpenLayers.Strings.language = "fr";
>
>    before you start working with the UI. Does this seem sane? the 
>    file might look something like this:
>
>    OpenLayers.Strings = {
>      'en': {
>        // Message reported via alert when WFS transaction succeeds
>        'olLayerWFSSuccessMessage': 'WFS Transaction: SUCCESS'
>      },
>      'es': {
>        'olLayerWFSSuccessMessage': 'WFS Transaction: e`xito!'
>      },
>      '1337': {
>        'olLayerWFSSuccessMessage': '5|_|CC35'
>      
>      
>    }  
>    OpenLayers.Strings.language = 'en';
>   
>    Is there anything that anyone can think of that would make this
>    totally infeasible?
>
> Regards,
>   






More information about the Dev mailing list