improvements to the Download object dialog

[aceman]

I propose to make these improvements to the "Download object" dialog:

1. the "Object type" dropdown contains items ("nodes", "ways", "relations") in plural forms taken from a different context so the translation does not match with this label. It is actually not sure this dialog needs the plural form. The "Object type" label could also take values in singular form (1 object). That would work for my language. Not sure about others, but this needs to be sorted out.

2. The dropdown menu and the field for the object IDs are shifted downwards a bit. Could use some alignment (see attached screenshot).

3. The explanatory text (w123, n110, w12, r15) contains english abbreviations (n, w, r), which should be input verbatim, but users using translated JOSM may not understand what they mean (when to use n or w or r). Either add the explanation (n = node, w = way, r = relation) in the english string too or at least leave some space in the dialog for translators to add it (if they get the idea).

[aceman]

screenshot of the dialog

[Don-vip]

i18n impact => 14.02

[simon04]

1. I cannot reproduce: according to the source code and the German translation, the singular form of "node", "way", "relation" is used.
2. I would say, this is a look-and-feel problem.
3. Good point.

[simon04]

In 6771/josm:

see #9611 - Improve i18n in download object dialog

[simon04]

Please provide some more information on item 1 (also wrt comment:2) …

[aceman]

OK, if this is the right definition of OsmPrimitiveType, that is used in the dialog, how is the translation supposed to choose the right form?

public enum OsmPrimitiveType {
            NODE (marktr(/* ICON(data/) */"node"), Node.class, NodeData.class),
            WAY  (marktr(/* ICON(data/) */"way"), Way.class, WayData.class),
            RELATION (marktr(/* ICON(data/) */"relation"), Relation.class, RelationData.class),

In our sk.po file the translation looks like this:

#: ../core/src/org/openstreetmap/josm/data/osm/OsmPrimitiveType.java:13
#: ../core/src/org/openstreetmap/josm/data/validation/util/NameVisitor.java:47
#: ../core/src/org/openstreetmap/josm/gui/DefaultNameFormatter.java:176
msgid "node"
msgid_plural "nodes"
msgstr[0] "bodov"
msgstr[1] "bod"
msgstr[2] "body"

As there is no count specified ("how many nodes") it looks like this chooses the first form found, which incidentally is a plural form (for a number 5+) in SK language.
There is no {0} placeholder in that string so this string can't be properly translated (the current state is just a random guess) as there is no context attached and you use this string in different contexts. I have already indicated this in ticket:9110#comment:5.

The order of the plural forms in our sk.po file also seems strange and poedit complains about it.
This is set in the file header as

"Plural-Forms: nplurals=3; plural=(n==1) ? 1 : (n>=2 && n<=4) ? 2 : 0;\n"

I don't know who or which app sets it and if it is any problem.
The natural order of the forms would be:

msgstr[0] "bod"
msgstr[1] "body"
msgstr[2] "bodov"

So incidentally, this ordering could fix this bug, but I think it should be fixed properly in the string itself and its context.

I have also seen this problem (using plural form instead of singular) e.g. in the selection side pane, in the case of relations.

[simon04]

According to ​http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html the plural form is nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2. Changing this plural specification probably would fix some of the issues since the singular form would then be at position 0.

To change the form, I would assume that the following operations are needed:

• change the Plural-Forms line in the po file and change the indices in msgstr[_].
• also change the case MODE_SK in source:trunk/src/org/openstreetmap/josm/tools/I18n.java​

Dirk, would that work?

[aceman]

I would be able to fix the order in the .po file and upload to Launchpad (I have already did so in the past because the order was messed up - maybe somebody set the wrong format in the header but didn't reorder the lines). It can also be scripted by you as you just need to convert 0 -> 2, 2 -> 1, 1 -> 0 atomically.

[stoecker]

Hmm, I've taken the I18n.java from the po files. I don't know who defined these. If it is possible to correct this, please go on. I thought they are hardcoded in gettext (or in Launchpad). Your update simply means dropping MODE_SK and using MODE_CS (which sounds logical to me, as these languages have common origins).

[stoecker]

But: The po files downloaded from launchpad should be correct afterwards!

[simon04]

I'll proceed as in comment:6 and keep the downloaded sk.po unmodified file if something goes wrong.

[stoecker]

Ok, it seems this is simply wrong in launchpad. The description says it here: ​https://translations.launchpad.net/+languages/sk and for all projects I found it is like here: ​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/+details

So probably either we should simply ignore that wrong line and use and translate sk in the same order as cs or improve the .lang-building tool to reorder sk when necessary.

Transifex BTW returns the correct text in po:
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

[simon04]

Changing the plural form in ​http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/tools/I18n.java requires an i18n update for core plus all plugins (for all languages)?

[simon04]

Replying to stoecker:

Transifex BTW returns the correct text in po:
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

But doesn't fix the indices:

sk/core.po:

#: ../core/src/org/openstreetmap/josm/actions/DownloadPrimitiveAction.java:95
#, java-format
msgid "One object could not be downloaded.<br>"
msgid_plural "{0} objects could not be downloaded.<br>"
msgstr[0] "{0} objektov nebolo možné stiahnuť.<br>"
msgstr[1] "{0} objekt nemohol byť stiahnutý.<br>"
msgstr[2] "{0} objekty nebolo možné stiahnuť.<br>"

sk.po from launchpad before change:

#: ../core/src/org/openstreetmap/josm/actions/DownloadPrimitiveAction.java:95
#, java-format
msgid "One object could not be downloaded.<br>"
msgid_plural "{0} objects could not be downloaded.<br>"
msgstr[0] "{0} objektov nebolo možné stiahnuť.<br>"
msgstr[1] "{0} objekt nemohol byť stiahnutý.<br>"
msgstr[2] "{0} objekty nebolo možné stiahnuť.<br>"

modified sk.po:

#: ../core/src/org/openstreetmap/josm/actions/DownloadPrimitiveAction.java:95
#, java-format
msgid "One object could not be downloaded.<br>"
msgid_plural "{0} objects could not be downloaded.<br>"
msgstr[0] "{0} objekt nemohol byť stiahnutý.<br>"
msgstr[1] "{0} objekty nebolo možné stiahnuť.<br>"
msgstr[2] "{0} objektov nebolo možné stiahnuť.<br>"

Uploaded a sk.po with (manually) fixed indices: Here's the running example on launchpad ​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/139/+translate

Although I got a message saying "This mail is to notify you that all translations have now been imported.", the plural form on launchpad hasn't changed. Hmm …

[stoecker]

Replying to simon04:

Changing the plural form in ​http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/tools/I18n.java requires an i18n update for core plus all plugins (for all languages)?

Yes, when "en.lang" has been changed.

[stoecker]

Replying to simon04:

Replying to stoecker:

Transifex BTW returns the correct text in po:
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

But doesn't fix the indices:

I don't know if somebody really interprets that text. As said, I believe it is hardcoded.

Uploaded a sk.po with (manually) fixed indices: Here's the running example on launchpad ​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/139/+translate

Although I got a message saying "This mail is to notify you that all translations have now been imported.", the plural form on launchpad hasn't changed. Hmm …

Launchpad has an "updated string" detection. You need to have a recent download to start from (some info in the header is used for that). Best is probably to upload an totally empty translation set first and the rotated set afterwards when the empty one killed all translations. Or we speed up the Transifex migration :-)

[aceman]

I don't know which version is more correct. I translate several other projects and I have seen both versions used in them:
plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2
plural=(n==1) ? 1 : (n>=2 && n<=4) ? 2 : 0

It probably doesn't matter much, as long as you interpret the forms according to the Plural-Forms statement.

The real bug here is that you assume that form 0 is the singular form instead of properly calling something like trn(1, "node"). This assumption may also fail for other languages which maybe didn't notice it yet, or can't easily fix it (can't move singular to form 0).

[simon04]

Replying to stoecker:

You need to have a recent download to start from (some info in the header is used for that). Best is probably to upload an totally empty translation set first and the rotated set afterwards when the empty one killed all translations.

I doubt that this will make a difference since the header from the downloaded sk.po file hasn't been changed and I was able to update the German with an unmodified header earlier today.

Or we speed up the Transifex migration :-)

+1 :-)

[stoecker]

In 6796/josm:

see #9611 - proper plural selection also for single strings

[stoecker]

Hello,

The real bug here is that you assume that form 0 is the singular form

You could have said that much earlier...

[stoecker]

It probably doesn't matter much, as long as you interpret the forms according to the Plural-Forms statement.

We need to adapt i18n.pl, so that is aware of that line and detects changes!

[aceman]

Replying to stoecker:

Hello,

The real bug here is that you assume that form 0 is the singular form

You could have said that much earlier...

It is encoded in my comment 5 ;)

[aceman]

Replying to stoecker:

It probably doesn't matter much, as long as you interpret the forms according to the Plural-Forms statement.

We need to adapt i18n.pl, so that is aware of that line and detects changes!

That would be a bonus, but as long as you have set the line into the .po file initially I hope nobody will change it. But yes, poedit program invites the user to fix that line so it is possible somebody may touch it.

[aceman]

Replying to stoecker:

Hmm, I've taken the I18n.java from the po files. I don't know who defined these. If it is possible to correct this, please go on. I thought they are hardcoded in gettext (or in Launchpad). Your update simply means dropping MODE_SK and using MODE_CS (which sounds logical to me, as these languages have common origins).

I have a 'fixed' .po file and try to upload it soon to launchpad. Please see if launchpad needs to be corrected after that (so it shows the changed "plural expression" at ​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/+details).
Yes, MODE_SK and MODE_CS have the same format so you can then merge them in JOSM code.

This may not fix the real bug, but at least should prevent the poedit warning tempting users to change the plural format line and then JOSM format getting out of sync.

[aceman]

Replying to stoecker:

In 6796/josm:

see #9611 - proper plural selection also for single strings

I have now downloaded 6798 and both of the visible usages of plural form instead of singular are fixed. Without the fixing of .po file (it is in the queue yet). Thanks.
But I suggest we still try to reorder the .po file.

[aceman]

Replying to aceman:

I have a 'fixed' .po file and try to upload it soon to launchpad. Please see if launchpad needs to be corrected after that (so it shows the changed "plural expression" at ​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/+details).
Yes, MODE_SK and MODE_CS have the same format so you can then merge them in JOSM code.

The uploaded file doesn't seem to have any effect. Launchpad still displays the order wrongly (in the individual strings and also the details page).

[Don-vip]

Can we close this ticket ?

[aceman]

As long as we can't fix the plural forms order while on Launchpad I think we can close this. I confirmed the current fix works in comment 24.
Thanks.