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

[Dirk Stöcker]

On Sat, 21 Feb 2009, Dermot McNally wrote:

> 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).

Well althought from the point of a translator this seems to be strange 
when you look the other way round you find it useful. The gettext system 
allows to keep the code together, so you always see text and the relevant 
code and when code changes, the texts get corrected.

Some reason why gettext is used often and ID-based systems (like e.g. the 
Amiga had long before gettext existed and Java also has):

- much more work for software developers to setup at all
- text and code drift away a little each time the code is changed
- code is much harder to read without texts
- code is much harder to debug without texts (you don't find the source
   file that easy)
- ID based systems always require translations, whereas gettext has
   english as fallback in any case.

The normal gettext tools usually catches the text changes in original 
strings with their fuzzy strings. That reduced work for translators a lot. 
A big drawback of Launchpad is its missing support of this feature.

> Has this kind of problem not arisen many times before and been solved?

Yes, and there is a solution for code: context. There are different forms 
to supply that context:

- extra parameter for gettext code call
- Specially formed strings (e.g. "context?text"), where context is
   stripped before display.

But without need I don't want to introduce context in JOSM ATM, as I want 
to replace the gettext code in JOSM with a more space saving variant. And 
I don't like to do this with the whole full-featured gettext.

For other parts context support is another matter, as our presets XML 
format as well as the other string data sources do not know anything 
about contexts currently.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)