It sounds like there is general approval for (and no complaints about) this type of i18n solution. I'll gladly commit with a thumbs up from a reviewer.
http://trac.geoext.org/ticket/352 Thanks, Tim On 11/20/10 9:56 AM, Cédric MOULLET wrote: > Thanks both for yous answers. > Cédric > PS: I also agree that the runtime language change is more a demo > function than a real use case... > > On Fri, Nov 19, 2010 at 9:31 PM, Tim Schaub <[email protected] > <mailto:[email protected]>> wrote: > > On 11/19/10 2:40 AM, Eric Lemoine wrote: > > On Thursday, November 18, 2010, Cédric > MOULLET<[email protected] <mailto:[email protected]>> > wrote: > >> Thanks Tim for this proposal. > >> I like the way it's done. > >> I have two minor questions: > >> - Will it be possible to change the language without to have to > reload the page ? > >> - The GeoExt translation framework will have to coexist with the > OpenLayers or ExtJS translation framework. Do you see any issue with > that ? > > > > > > Hi Cédric > > > > Fredj and I have taken a look at Tim's patch. And it seems to us that > > Tim's patch isn't that different from Fredj's. Both change the > strings > > in the prototypes, and both allow custom internationalization, at > > instantiation time or at type creation time, and possibly with > > OpenLayers.i18n. Here are examples of custom internationalization > that > > still work: > > > > new GeoExt.tree.BaseLayerContainer({ > > text: OpenLayers.i18n("toto") > > }); > > > > MyClass = Ext.extend(GeoExt.tree.BaseLayerContainer, { > > text: OpenLayers.i18n("titi") > > }); > > > > And yes, Tim's patch is a step towards being able to change the > > language without reloading the page. But we'd still need our GeoExt > > components, and/or the application code to listen to "localize" and > > rerender the UI with new strings. But with Ext not supporting this > > doing it at the application level will be required. I've personally > > never been convinced by "change the language without reloading the > > page", mostly because of the extra complexity it requires on the > > client code. > > > > Thanks for the answers Eric - right in line with my thinking. > > With the "framework" patch, as Eric mentioned, we at least have the > option of changing the language at runtime. While this would allow the > switch-after-rendering case, this would have to be handled at the > application level as Eric mentions (listening for "localize" and either > re-rendering specific elements or destroying and re-initializing entire > components). I think the more common case that this also supports is to > allow the user to choose the language before components are initialized > (using one build of your app to support multiple languages) - the Ext JS > language files aren't particularly well suited for this. > > In addition to playing well with OpenLayers/Ext JS localization > solutions, the GeoExt.Lang singleton could also be used to localize > non-GeoExt components. > > E.g. > > GeoExt.Lang.add("fr", { > "My.App.Widget.prototype": { > prop: "valeur" > } > }); > > Tim > > > Cheers, > > > > > > > > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > [email protected] <mailto:[email protected]> > http://www.geoext.org/cgi-bin/mailman/listinfo/dev > > > > > -- > Welcome to my world: http://www.cedricmoullet.com/ > My Linked In profile: http://www.linkedin.com/in/cedricmoullet > Twitter: http://twitter.com/cedricmoullet > Home sweet home: > http://map.geo.admin.ch/?crosshair=bowl&zoom=11&X=185241.24219&Y=561288.90625&bgOpacity=0&selectedNode=node_ch.swisstopo.fixpunkte-lage1 > <http://map.geo.admin.ch/?crosshair=bowl&zoom=11&X=185241.24219&Y=561288.90625&bgOpacity=0&selectedNode=node_ch.swisstopo.fixpunkte-lage1> > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list [email protected] http://www.geoext.org/cgi-bin/mailman/listinfo/dev
