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. Better is one central translation set accepting the drawbacks you tell.

The presets aren't that dynamic to make the method unusable.

Your suggestion can nevertheless be reached by reintegrating the translations into the presets after translation process is finished. Thought this makes a lot of scripting work and will not change the situation a lot (there will still be out-of-sync translations).

And I fear the people changing the preset file will to often destroy the translations due to improper UTF-8 settings and thinks like this (native englisch speakers tend to ignore the requirements behind ASCII charsets to often :-).

The sync-problem is the reason, why e.g. KDE has a translation fix termin. To get sync back. Contiously developing projects like josm will have to live with certain side effects.

But the only effect will be
a) English texts in the dialog for new stuff (no problem)
b) extra English entries in the menu instead of additions in the proper
   submenu. A bit disturbing, but no real issue.

Now about now default presets files:
a) when local, then it can be translated directly.
b) modified presets get translated partially.

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

When when allow translations as well:

        <item name="Streets/Trunk" icon="presets/trunk.png">
                <label text="Edit a Trunk" />
                <text key="ref" text="Reference:" default="" 
delete_if_empty="true" />
                <combo key="lanes" text="Lanes:" values="1,2,3,4,5" default="2" 
delete_if_empty="true" />
                <check key="oneway" text="Oneway:" default="on" 
delete_if_empty="true" />
        </item>

e.g. like this:

        <item De:name="Straße/Schnellstraße" icon="presets/trunk.png">
                <label De:text="Schnellstraße ändern" />
                <text key="ref" De:text="Referenz:" default="" 
delete_if_empty="true" />
                <combo key="lanes" De:text="Spuren:" values="1,2,3,4,5" default="2" 
delete_if_empty="true" />
                <check key="oneway" De:text="Einbahn:" default="on" 
delete_if_empty="true" />
        </item>

Notes about this:
a) Are keys with ":" allowed?
b) I can implement this. I do not really know how the XML parsing works in 
detail.
c) Procedure would be:
   - First try "Xx:key"
   - If not existing try "key" directly.
   - (Actually I know this will be more like replace "key" with "Xx:key"
     after the parsing :-)
   - Key is translated using the lang plugin

This way we have the advantages of the central translation and also the possibility to specify the data in the preset file.

P.S. For the MOTD fix, you removed an essential part.

The align=\"center\" makes the display of the h2 text much nicer and the DOCUMENT type is required or the text in <style> tag is displayed directly instead of beeing interpreted.

But the DOCUMENT was never there in the past, while <style> has
always been there - and I never saw the text inside <style> displayed
literally. I'll investigate.

Sure? These texts show up since the introduction of the new MOTD. Was there really this "style" replacement stuff before?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
josm-dev mailing list
[email protected]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev

Reply via email to