The issue of localisation frameworks is one that I've been considering a lot in the last few weeks in my day job. Our application is built in perl, and perl provides a more powerful, code-allowed tool called maketext which does more or less what gettext does but with some extra bells and whistles. There are ways to use the .po file format for a maketext lexicon. Some background:
http://cpansearch.perl.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.62/docs/webl10n.html But the one thing that surprised me is that all common lexicon arrangements assume that strings should be keyed not by an abstract key (like, say, "EDIT_MENU_NAME", 'EDIT_TOOL_BUTTON_NAME") but by the string itself in the primary language ("Edit", with no option to have a second "Edit" in a different context). This struck me as troublesome during my investigations, partly because of the context difficulty that we're seeing here, but mostly because for a string like "ACME Widgets company - your source of cheap widgets", any change, even one of punctuation, or, in this example, a revision to your English language slogan, forces an update of all localised string assets, whether or not it's essential that they be adjusted (which for reasons of English punctuation or grammar or single-market motto changes is more trouble than is warranted). Has this kind of problem not arisen many times before and been solved? Dermot -- -------------------------------------- Iren sind menschlich _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
