Re: Impact Calculator copied to new structure
Andreas Hocevar
see updates inline.
On Aug 15, 2011, at 14:44 , Andreas Hocevar wrote:
> Hi Ole,
>
> glad the presentation went well. See comments inline.
>
> On 2011-08-15 08:40, Ole Nielsen wrote:
>>
>> - The original version used Django's internationalisation for
>> multilingual support whereas the new version is using a javascript specific
>> model. To have consistency across the entire application, we prefer the
>> former if possible
>
> This is the Ext JS / GeoExt way of doing internationalization. We use it in all gxp applications, and it enables us to have applications that do not depend on Django. I would like to understand the reasons for preferring the Django internationalization model. The way the gxp components are translated in GeoNode is a bit awkward, with one file needed as bridge between Django and gxp, plus the translation files. Using the Ext JS / GeoExt way, you only need the translation files. So I'd prefer the Ext JS / GeoExt way, unless there is a strong reason against it that I'm currently missing.
After discussing this with Ariel off-list, I came up with the following solution:
Ariel off-list:
> #A2 We do not know how Javascript knows which language is selected and
> always get the english version
We now do. Since https://github.com/GeoNode/geonode/commit/f81f58b7bf459f323c1a2ba7cd5df7559bd9bb72, lang.js sets the language for everything that is based on GeoExt.
> As part of the refactoring, I will also be bringing the Indonesian gxp translation you contributed a while ago into gxp core, so also the non application specific widgets will be translated.
Or in other words:
Ariel off-list:
> #B1 Port all the gxp, geoext, openlayers translations back upstream,
> since we have you to commit it :) and it will be beneficial for
> others.
This is done now for gxp. You'll see now that not only the application specific parts of the application are translated, but also the components that come from upstream gxp.
Ariel off-list:
> #B2 Use Django's gettext function for application specific
> translations instead of Javascript files, because we already
> understand it, have the machinery hooked up and makes translating to
> new languages already supported by upstream projects easier.
This is done as well (again).
> #B3 Simplify the actual implementation of application specific strings
> and use gettext('my string') only at the top of our application files.
Everything is prepared for this, i.e. the application specific strings are defined using gettext at the top of the application files (currently only calculator/app/static/script/app/Risiko.js), but it requires some more efforts from a Django expert (/me looking at Ariel) to get rid of risiko/templates/lang_risiko.js.
As always, please let me know if there are any concerns or questions.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.