[josm-dev] Some bugfixes

[Christoph Eckert]

Hi,

> On Fri, 27 Jun 2008, Frederik Ramm wrote:
> > I don't think *this* is the problem. The problem, in my view, is that
> > if you use tr() to translate the presets, then every preset - and
> > there are possibly many, presets are not a built-in thing, a
> > preset .xml is more like a config file! - would have to be mirrored
> > in the lang-xx plugins. I would rather have the preset translations
> > inside the preset files.
>
> Probably. But I don't think this will work. I do translations for a long
> time now and a concept as you describe will probably fail.

Maybe. But if we had the two way mechanism ("inline" translations as well as 
centralised i18n), we should ensure that no strings appear in the lang 
plugins that are already tranlated inline.

> Better is one 
> central translation set accepting the drawbacks you tell.
>
> The presets aren't that dynamic to make the method unusable.

Agreed.

[...]

> What about a two-way method. We can use the same approach, as for MOTD.

KDE already has a mechanism to translate config files (such as .desktop 
files):

Trask.desktop

Name=Trash
Name[de]=Mülleimer
Comment=Contains removed files
Comment[de]=Enthält gelöschte Dateien
Type=Link
URL=trash:/

Applied to our presets, it could look like:

<item

 name="Streets/Trunk"
 name[de]="Straßen/Schnellstraße"
 name[fr]="Voies/Voie rapide"

 icon="presets/trunk.png">
 icon[de]="presets/Schnellstraße.png">
 icon[fr]="presets/VoieRapide.png">

 <label text="Edit a Trunk" />
 <label text[de]="Schnellstraße bearbeiten" />
 <label text[fr]="Adapter Voie Rapide" />

 <text key="ref"

 text="Reference:" default=""
 text="Reference[de]:" default=""
 text="Reference[fr]:" default=""

[...]

This shows a disadvantage of inline translations: It will blow up the 
translation files and potentially make them "unreadable".

There are some further ideas concerning the presets. One is to have multiple 
preset files. They could be split into namespaces to autoselect a subset 
based on the locale setting. Additionally, users could then switch 
dynamically between the remaining presets within the preselected namespace.

Frankly, I don't know which method is best. The only thing that is out of the 
question is that we need translated presets :) . The currently best solution 
was to have both methods, "inline" translations for "SIG" presets as well as 
plugin based translations for the default presets. For the latter one, we 
needed a markup for the strings being trranslated, right?

Best regards,

ce