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]> wrote: > On 11/19/10 2:40 AM, Eric Lemoine wrote: > > On Thursday, November 18, 2010, Cédric MOULLET<[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] > 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
_______________________________________________ Dev mailing list [email protected] http://www.geoext.org/cgi-bin/mailman/listinfo/dev
