Opened 7 years ago

Last modified 7 years ago

#4010 new enhancement

i18n: make map_features i18n-ed

Reported by: miurahr Owned by: potlatch-dev@…
Priority: major Milestone:
Component: potlatch2 Version:
Keywords: Cc:

Description

Now map_features is loaded from map_features.xml but it cannot switch according to language preference.

It should be selectable to load map_features-<lang>_<country>.xml by configuration or flashvars

Change History (5)

comment:2 Changed 7 years ago by TomH

This is certainly needed, though there are various approaches to doing it.

At one extreme the OSM web site could already do it by passing an appropriate parameter to the SWF based on what files are available, or we could do as your patch does and make the SWF do the job.

We may need to think about how this interacts with the resource bundling stuff, and whether we should actually be loading a zip named after the locale and then looking for map_features.xml inside it, along with the icons etc.

I'm certainly not sure that we just want to duplicate the existing english stylesheet to all the languages - it would be better to fallback to the english version somehow until there is a locale specific version. We may also want more granular fallback I guess but that's a hard problem I think.

comment:3 Changed 7 years ago by miurahr

I updated branch.
I replace not-yet-translated feature.xml to symbolic links.

This topic branch has a scenario to use SWF parameter to determine what language should be selected.

It is not interact with bundling staff because features icons don't have unique id which is needed to inject localized words.

fallback mechanism is not good for performance. To escape fallback, I make symbolic link for languages. It is easy and same effect with fallbacks.

comment:4 Changed 7 years ago by miurahr

  • Priority changed from minor to major

Merged on head, v2.3 -on flex4.5.1, of systemed's tree.
It works fine.

https://github.com/osmfj/potlatch2/tree/i18n-flex4

Transit to the one which is based on zip loading mechanism seems to be needed further work. Could we use step by step strategy support localization?

We need to work around making localized files for localization, in parallel to developing features. It would be better to start l10n work, making helper utilities to update properties and features.xml files and utility to make lang.zip files, and then i18n features that interact with zip feature.

With this topic branch, we are actually able to start translation for each languages.

comment:5 Changed 7 years ago by miurahr

any other difficulties?

Note: See TracTickets for help on using tickets.