Hi Eric,
I'm okay with taking this approach. I used it in the past, but then
switched to OpenLayers i18n, but I am happy to switch back :-)
Best regards,
Bart
> Hi
>
> Currently we don't have i18n support in GeoExt and GeoExt.ux. I think
> it would make sense to change that.
>
> We at Camptocamp have looked at how i18n works in Ext. We think it's
> both simple and efficient.
>
> So Ext includes translation files. Basically these files apply
> translated strings to the component prototypes. As an example here is
> what the ext-lang-fr.js includes for Ext.form.TextField :
>
> if(Ext.form.TextField){
> Ext.apply(Ext.form.TextField.prototype, {
> minLengthText : "La longueur minimum de ce champ est de {0}
> caractère(s)",
> maxLengthText : "La longueur maximum de ce champ est de {0}
> caractère(s)",
> blankText : "Ce champ est obligatoire",
> regexText : "",
> emptyText : null
> });
> }
>
> (See <http://extjs.cachefly.net/ext-3.2.1/src/locale/ext-lang-fr.js>
> for other examples.)
>
> As opposed to oOpenLayers (and possibly other libs) there's no need to
> use translate functions in the code. The components just define
> english (the default language) strings in their prototypes.
>
> We could use the same mechanism in GeoExt and GeoExt.ux. For GeoExt,
> as I see it, we would add a "lang" directory in lib/GeoExt/, with
> translation files in this directory. For GeoExt.ux each extension
> would include its own translation files, in lib/GeoExt.ux/lang.
>
> So far I haven't identified limitations in doing i18n the Ext way.
> What do you guys think about it?
>
> Thanks,
> _______________________________________________
> Dev mailing list
> [email protected]
> http://www.geoext.org/cgi-bin/mailman/listinfo/dev
>
_______________________________________________
Dev mailing list
[email protected]
http://www.geoext.org/cgi-bin/mailman/listinfo/dev
