[OpenLayers-Dev] status of translation possibilities

[Cameron Shorter]

I think this is another candidate for functionality from Mapbuilder to 
be migrated to Openlayers or maybe the new Openlayers Addins directory.

Mapbuilder can then access functionality by calling Openlayers.
It would probably involve a little reformatting of code to fit the 
Openlayers style guide. Gertjan would be able to talk to this further.

Gertjan van Oosten wrote:
> As quoted from Christopher Schmidt <crschmidt at metacarta.com>:
>   
>> It needs to be more complex than this to support interpolation, and I
>> think it will need to: as the RFC says:
>>     
> [ http://trac.openlayers.org/wiki/RFC/Internationalization ]
>   
>> "The OpenLayers.String object will have an additional function,
>> translate. Translate will accept a translation key -- a single string
>> which can be used to look up the string -- and any number of additional
>> arguments. If additional arguments are passed, they will be interpolated
>> in the string in order."
>>
>> MapBuilder already has some code that does this, so we can work with
>> them to integrate those bits of it into OpenLayers.  
>>     
>
> As I wrote on the I18N thread mid-July (see below), OpenLayers can just
> copy the interpolation function I wrote for MapBuilder.  So
> interpolation capabilities are more or less a given.  The only question
> remaining is how to get the i18n'ed strings into (and out of) the
> Openlayers code.  I have never come across a real-life use case where
> you would want i18n data to be displayed in mixed-language in one
> application, so a single, global language setting would suffice for the
> majority of cases.
>
> Note that even when you have i18n texts, you still need to take into
> account that the developer adding new strings to the code and the people
> doing the translation thereof into the other supported languages are
> generally not the same.  Which means you need some sort of fall-back
> mechanism for message keys that remain as yet untranslated.  In
> MapBuilder the fall back is on the default language "en".
>
> To start off, I guess simple language tags ("en", "nl", "fr", ...) will
> suffice.  If and when people want to support language subtags ("en-GB",
> "en-US", "nl-NL", "nl-BE", "fr-FR", "fr-CA", ...) you should also
> incorporate a fall back from the subtagged language on the more general
> language tag.  For MapBuilder this is still on my TODO list; there has
> been no demand for it yet.
>
> [See http://communitymapbuilder.org/display/MAP/Add+Translations
>  for complete information on how MapBuilder does things.]
>
> Anyway, to quote myself on interpolation ;-) :
>
>
> [...] the function mbFormatMessage() I wrote, copied below from
> trunk/lib/util/Util.js for your convenience, can be used straight
> out-of-the-box to get simple interpolation.  Since at the top of the
> file it clearly states that it is LGPL, nothing is stopping you. 8-)
>
>   /**
>    * Format a message with the extra arguments. <br/>
>    * E.g. if called as: <code>mbFormatMessage("{1} is {0} {2}, {1}", "a good", "this", "test")</code><br/>
>    * the formatted message returned is: <code>"this is a good test, this"</code>
>    * @param messageFormat the message format string
>    * @param varArgs       optional extra parameters for formatting the message
>    * @return              the formatted message
>    */
>   function mbFormatMessage(messageFormat)
>   {
>     var message = messageFormat;
>     var varArgs = [].slice.call(arguments, mbFormatMessage.length);
>     for (var i in varArgs) {
>       var parm = new RegExp("\\{" + i + "\\}", "g");
>       message = message.replace(parm, varArgs[i]);
>     }
>     return message;
>   }
>
>
> Regards,
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254