Hi all, it looks cool but it seems quite verbose and "codish" as well (see http://extjs.cachefly.net/ext-3.2.1/src/locale/ext-lang-fr.js). Don't you think that non-technical people (for instance clients doing translations) will get a little lost or put some mess?
alex 2010/5/28 Eric Lemoine <[email protected]>: > 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
