We have been trying to use Django's built-in i18n support in our templates, but there is only one, partial translation (to Spanish) and so changing the language currently has little effect, and there may be places where the English text is not marked translatable. There is documentation on using the i18n system <http://docs.djangoproject.com/en/1.2/topics/i18n/> and creating localizations<http://docs.djangoproject.com/en/1.2/topics/i18n/localization/> in the official Django manual.
I would recommend creating a git checkout of the sources from http://github.com/GeoNode/geonode/ and following the README instructions to set up a development environment. Since the GeoNodea project contains more than just the Django application, you'll need to 'cd' into the proper directory before running the Django localization tools: $ cd src/GeoNodePy/geonode/ $ django-admin.py makemessages -l it This will generate some dictionaries for the Italian translation in GNU gettext's .po format. You can edit these directly in a text editor if you are so inclined, or there are a number of GUI tools to help with editing them listed at the end of the Wikipedia article on gettext<http://en.wikipedia.org/wiki/GNU_gettext> . If you aren't able to get a development build running I can set up the dictionaries and you can just edit them... But you won't be able to see the translations in context until the demo site is updated with the new dictionaries. Hope this helps. -- David Winslow OpenGeo - http://opengeo.org/ On Sat, Oct 30, 2010 at 10:27 AM, Luca Casagrande <[email protected] > wrote: > Hello folks, > anyone is working on the localization of GeoNode? > Don't know which is the best approach to this task..any idea? > > Ciao > Luca > Il 30/10/2010 15:33, Matt Bertrand ha scritto: > > Hi, > > > > I'm working on a GeoNode customization as well. Some of the features > > I need to add are customizable header banners for user-created maps, > > querying and highlighting selected features on the map, user defined > > layer categories, and displaying the layer tree organized by category. > > (http://github.com/mbertrand/cga-worldmap). This is for the next > > version of "WorldMap", a web mapping platform used by Harvard's Center > > for Geographic Analysis. We decided to use GeoNode as the basis for > > it since it already has many of the features we were hoping to > > include, such as data uploads, permission controls, style editing, etc. > > > > So far I haven't overridden any existing patterns in urls.py, but I > > have added some new ones. I've needed to modify several of the > > default templates, and I've quite a few changes to the views and > > models. I also added new functions to the GeoExplorer javascript file > > that renders the map view (for searching, querying, and highlighting > > layers). I've been merging the latest code from geonode every few > > days, and so far the merge conflicts have been pretty trivial so far, > > though they won't necessarily continue to be so simple. > > > > Thanks for the useful tips! > > > > -Matt > > > > > > On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote: > > > >> Thanks! There are a couple of good hints how to approach our issue - > >> duplicating the template dir structure and changing the template dir > >> setting seems like a good way to start. I also like the idea of havin > >> g a fallback to the default geonode. > >> > >> A colleague pointed me to the class based views discussion in Django > >> Development > >> http://docs.djangoproject.com/en/dev/topics/class-based-views/ > >> > >> From what I read there, this seems to solve exactly what I'm trying > >> to do. > >> > >> Christian > >> > >> On Oct 28, 2010, at 8:09 PM, David Winslow wrote: > >> > >>> Well, we haven't done a lot of heavily customized applications, but > >>> in the future I think it would be great t o have a good plan for > >>> people who want to dig into Django a bit and use GeoNode as a > >>> platform for their own tools. So I'm glad to hear you're looking > >>> into it. > >>> > >>> In previous experiments with having an alternative theme building > >>> off the core GeoNode, we had a setup where the alternate site had > >>> its own se ttings.py, where early in the Python file, there was a > >>> line like: > >>> > >>> from geonode.settings import * > >>> > >>> > >>> Then we modified various values as needed (INSTALLED_APPS = > >>> INSTALLED_APPS + ('myapp',)). I think this approach worked ok, but > >>> it was a little cumbersome to keep the customized site up to date > >>> with the main site as new pages and apps were added. I'm not sure > >>> what a better solution might be... we have started to recognize a > >>> "local_settings.py" file next to the GeoNode settin gs to > >>> accommodate site-specific changes in a file that won't be > >>> overwritten on updates, but I don't think that approach works well > >>> if you want to add extra Django apps to the site. > >>> > >>> A similar approach *should* work pretty well for the urls.py though. > >>> You can just import geonode.urls in your urls.py and write > >>> "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to have the > >>> GeoNode URLs used as a fallback if none of your URL patterns match a > >>> request. > >>> > >>> Django also has a nice system for overriding templates. If you > >>> override TEMPLATE_DIRS to add an extra directory containing your > >>> customized templates before the directories it already uses, then > >>> those templates will override. So you would have templates in places > >>> like like [/opt/mysite/geonode/login.html] and your settings would > >>> have an entry like: > >>> > >>> TEMPLATE_DIRS = "/opt/mysite/", \ > >>> > >>> path_extrapolate('geonode/templates'), \ > >>> > >>> path_extrapolate('geonode/maps/templates'), \ > >>> > >>> > >>> path_extrapolate('django/contrib/admin/templates', 'django'), > >>> > >>> > >>> Don't worry about the path_extrapolate function there, it duplicates > >>> some path-munging functionality already present in the Django > >>> template system and will probably be going away in a release soon > >>> after 1.0. 1.1, along with other Pinax integration and general > >>> adoption of Django idioms, should also be using the > >>> django-staticfiles > >>> <http://docs.djangoproject.com/en/1.2/howto/static-files/> app to > >>> provide simila r functionality for CSS and JavaScript resources, > >>> should you need to override or add on to what's used in GeoNode. > >>> > >>> I hope this provides you some good places to start investigating. > >>> > >>> -- > >>> David Winslow > >>> OpenGeo - http://opengeo.org/ > >>> > >>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian > >>> <[email protected] <mailto:[email protected]>> wrote: > >>> > >>> Hi, > >>> > >>> I've started customizing a GeoNode instance and was wondering if > >>> other users here are trying to do something similar. Mainly to > >>> check/discuss if the path I'm going makes sense. > >>> > >>> The g oal is to maintain maximum forward compatibility with the > >>> main GeoNode repository (painless future updates/merges). At the > >>> same time, we obviously want a custom design for and add other > >>> functionality (Django apps) to our GeoNode instance. > >>> > >>> So far I've thought about a few approaches: > >>> > >>> A) override urls.py with my app's urls.py > >>> > http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16 > >>> and duplicating code from the default GeoNode apps seems like a > >>> really bad idea. > >>> > >>> B) modifying the default templates > >>> > http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12 > >>> would break forward compatibility at some point. That solution > >>> worked as quick hack to have a basic custom design online but I > >>> would rather not touch the default templates in the long run. > >>> > >>> C) specifying templates generally in urls.py > >>> > http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20 > >>> instead of hard-coding them into views would allow users to > >>> customize frontend designs, like switching templates, pretty > >>> easily. That's my favorite approach so far but doing that by > >>> myself, changing all views to that schema, would probably break > >>> forward compatibility (seamless merging with future GeoNode > >>> updates/fixes) of our instance too. > >>> > >>> Any other thoughts? > >>> > >>> Thanks, > >>> Christian > >>> > >>> Please be advised that the Massachusetts Secretary of State > >>> considers e-mail to be a public record, and therefore subject to > >>> the Massachusetts Public Records Law, M.G.L. c. 66 ? 10. > >>> > >>> > >> < /div> > > > >
