[josm-dev] Trouble translating JOSM: Same strings used in different places

Ævar Arnfjörð Bjarmason avarab at gmail.com
Sat Feb 21 21:14:54 GMT 2009


On Sat, Feb 21, 2009 at 9:03 PM, Dermot McNally <dermotm at gmail.com> wrote:
> 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?

As long as the strings of some natural language are being used as keys
you'll always run into these problems.

Perhaps it could be solved by doing the following, while still staying
with the .po format:

In the source:

    tr("EDIT_MENU_NAME")

In en.po:

    msgid "EDIT_MENU_NAME"
    msgstr "Edit"

In is.po:

    msgid "EDIT_MENU_NAME"
    msgstr "Sýsl"

The application would then be configured to never use the original
tr() strings except in some debugging mode, always switching to en.po
when you start it up.

Maybe this has already been implemented by some other application?




More information about the josm-dev mailing list