Widgets i18n - replace getText by 'ext' way

[adube]

ExtJS as a good 'client-side' way of doing internationalization. GeoExt also adapted it. Each language has its own lang.js file and use the 'prototype' object of each widget to overwrite the text properties to translate.

Here's an example that sums it all up (it comes from the fr.js file from the external lib 'zoom-to') :

Ext.namespace("GeoExt.ux")
if (GeoExt.ux.ZoomTo) {
    Ext.apply(GeoExt.ux.ZoomTo.prototype, {
        zoomToText: "Zoomer",
        xCoordinateText: "Coordonnée X",
        yCoordinateText: "Coordonnée Y",
        projectionText: "Projection",
        invalidEntryText: "entrée invalide",
        widgetTitleText: "Outil de zoom sur coordonnées",
        destroyMarkerActionText: "Effacer +",
        closeActionText: "Fermer",
        zoomActionText: "Zoomer",
        errorText: "Erreur",
        missingProjectionText: "La projection est manquante.",
        missingCoordsText: "Coordonnées manquantes ou invalides.",
        outOfRangCoordsText: "Coordonnées à l'extérieur de l'extent courant."
    });
}

Doing it that way allows a reuse of the translation files without depending on a server-side component.

proposition

For all our widgets, instead of using getText, each could have a i18n folder with one file.js per language. Loading the according i18n file would need to be done in the printWidgetSource template, by checking what is the current 'locale'.

We wouldn't drop the getText support since it would still be useful for other kind of translations such as resource titles, text nodes related to data, etc. (in brief everything else but widgets).

example when getText bugging me

I had to add some features in the GeoExtPrintWidget (see ticket #165). The changes made in the .js file extended directly the GeoExt core widget. Some text needed to be added as well (messages to the user). If I had followed the 'Ext way' (which would have made sense IMHO), I would have added a fr.js file including the french translations. But I wanted to follow the 'GeoPrisma way' so I added them to the .mo/.po files.

I think that change could be proposed to the GeoExt team, but I'd rather not since it's a 'user-custom' need to display a message warning the user of what he's trying to do. Still, I'd rather made the translation the 'ext way' in order to be able to share it without having to depend on a server-side element (getText).

Since we're already using Ext and GeoExt, I think it would make sense to follow their way.

[yvesm]

Sounds logical. We need to sit down and look at the implications of changing our I18n machinery for part of the code, although it looks pretty easy to use Ext's for widgets.

[adube]

Not covered in 1.2 objectives.

[adube]

No patch, pushed to 1.6.

[adube]

No patch, pushed to 1.8.