Some bugfixes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Some bugfixes

Dirk Stöcker
Hello,

as I start to JOSM more and more, I made some patches for bugs which
disturb me.

961 [PATCH] Fix MOTD: Better i18n, works offline
960 [PATCH] i18n of presets
959 [PATCH] Error in i18n
956 [PATCH] Undo does not update command history
934 [PATCH] Fix reaction of URL-Listener

As I have only write access to the normal openstreetmap SVN and not the
one SVN of JOSM (or have I?), could please someone else apply these
patches.

The reaction on the JOSM bugtracker is very bad. The fix of #960 was
opened more than 1 month ago as bug #762 (only i18n plugin descriptions
are missing, when #960 is applied).

Also there are some useful patches in the tracker by others, which are not
applied nor commented.

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

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Some bugfixes

Frederik Ramm
Hi,

> as I start to JOSM more and more, I made some patches for bugs which
> disturb me.

This is commendable and I'm sorry that I don't currently get to look
through trac very often. I have committed your patches apart from 960
which I think requires a bit of discussion; I don't think that the
simple gettext method is quite ideal for i18n of presets - but I might
be wrong.

> As I have only write access to the normal openstreetmap SVN and not the
> one SVN of JOSM (or have I?), could please someone else apply these
> patches.

I'll contact you off-list about an SVN account.

> The reaction on the JOSM bugtracker is very bad. The fix of #960 was
> opened more than 1 month ago as bug #762 (only i18n plugin descriptions
> are missing, when #960 is applied).

I read ticket 762 when it was opened and thought I'll work on that when
I have the time... and haven't had the time since. So patches are most
welcome.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Some bugfixes

Dirk Stöcker
On Thu, 26 Jun 2008, Frederik Ramm wrote:

>> as I start to JOSM more and more, I made some patches for bugs which
>> disturb me.
>
> This is commendable and I'm sorry that I don't currently get to look
> through trac very often. I have committed your patches apart from 960
> which I think requires a bit of discussion; I don't think that the
> simple gettext method is quite ideal for i18n of presets - but I might
> be wrong.

I started to use the context based trc() first (implemented it :-), but
switched to normal tr() again, as there are no real conflicts and the
texts are translatable as they are.


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

Index: src/org/openstreetmap/josm/gui/GettingStarted.java
===================================================================
--- src/org/openstreetmap/josm/gui/GettingStarted.java  (Revision 662)
+++ src/org/openstreetmap/josm/gui/GettingStarted.java  (Arbeitskopie)
@@ -52,9 +52,10 @@
              try {
                  motdcontent = wr.read(baseurl + "/wiki/MessageOfTheDay");
              } catch (IOException ioe) {
-                motdcontent = "<html><body>\n<h1>" +
+                motdcontent = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n"
+
+                    "<html><body>\n<h1>" +
                      tr("JOSM, the Java OpenStreetMap editor") +
-                    "</h1>\n<h2>(" +
+                    "</h1>\n<h2 align=\"center\">(" +
                      tr ("Message of the day not available") +
                      ")</h2>";
              }

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.

The i18n fixes where only the additional parts of the fix I made after the
offline fixes :-)

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

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Some bugfixes

Frederik Ramm
Hi,

>> This is commendable and I'm sorry that I don't currently get to look
>> through trac very often. I have committed your patches apart from 960
>> which I think requires a bit of discussion; I don't think that the
>> simple gettext method is quite ideal for i18n of presets - but I  
>> might
>> be wrong.
>
> I started to use the context based trc() first (implemented it :-),  
> but
> switched to normal tr() again, as there are no real conflicts and the
> texts are translatable as they are.

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.

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

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"




_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Some bugfixes

Dirk Stöcker
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
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Some bugfixes

Dirk Stöcker
On Fri, 27 Jun 2008, Christoph Eckert wrote:

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

No. Why. Strings can be in both sets. Double text is only a very little
waste of space, but a large advantage in comfort (thing of old/new
versions, changed texts, ...). The i18n() translates every equal string,
which means also all the double strings in the preset file will be
translated automatically (as well as strings in own files).

What is true is, that translations in the preset files should be
preferred.

> 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:/
Well. That's what I meant with scripting. For KDE all these desktop files
and other stuff are parsed by scripts and the texts are extracted and
copied to the .po/.pot files. When these are translated scripts copy the
stuff back into the original file.

> 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=""
I would prefer "De:name" instead of "name[de]", as "De:" is used in MOTD
already.

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

Yes. That's why the mixed strategie. So only the strings not in the main
set need to be translated. This reduces confusion and space.

But you are right, that also the i18n should be extended to each key and
not only to the text keys, so maybe german signs can be used.

> 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?

No. Already done. The lang-infrastructure is working with the patch I
supplied (and the stuff I checked in in OSM svn) and I also started to
partially translate German texts (is a bit complicated, as I have to
check against the wiki for each text).

What is missing is
a) applying the patch
b) add the "Xx:key" to "key" conversion.

P.S. In my last letter I wanted to write, that I CAN'T do part b). I
don't fully understand the XML parser yet.

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