Modify

Opened 6 years ago

Closed 6 years ago

#9611 closed defect (fixed)

improvements to the Download object dialog

Reported by: aceman Owned by: simon04
Priority: minor Milestone: 14.02
Component: Core Version:
Keywords: i18n Cc: stoecker

Description

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.
  1. The dropdown menu and the field for the object IDs are shifted downwards a bit. Could use some alignment (see attached screenshot).
  1. 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).

Attachments (1)

bug-download-object.png (13.1 KB) - added by aceman 6 years ago.
screenshot of the dialog

Download all attachments as: .zip

Change History (29)

Changed 6 years ago by aceman

Attachment: bug-download-object.png added

screenshot of the dialog

comment:1 Changed 6 years ago by Don-vip

Milestone: 14.02
Priority: normalminor

i18n impact => 14.02

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by simon04

In 6771/josm:

see #9611 - Improve i18n in download object dialog

comment:4 Changed 6 years ago by simon04

Owner: changed from team to aceman
Status: newneedinfo

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

comment:5 Changed 6 years ago by 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.

Last edited 6 years ago by simon04 (previous) (diff)

comment:6 Changed 6 years ago by simon04

Cc: stoecker added
Keywords: i18n added

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:

Dirk, would that work?

Last edited 6 years ago by simon04 (previous) (diff)

comment:7 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by 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).

comment:9 Changed 6 years ago by stoecker

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

comment:10 Changed 6 years ago by simon04

Owner: changed from aceman to simon04
Status: needinfonew

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

comment:11 Changed 6 years ago by 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"

Last edited 6 years ago by stoecker (previous) (diff)

comment:12 Changed 6 years ago by 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)?

comment:13 in reply to:  11 ; Changed 6 years ago by 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 …

comment:14 in reply to:  12 Changed 6 years ago by 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.

comment:15 in reply to:  13 ; Changed 6 years ago by 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 :-)

comment:16 Changed 6 years ago by 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).

Last edited 6 years ago by aceman (previous) (diff)

comment:17 in reply to:  15 Changed 6 years ago by 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 :-)

comment:18 Changed 6 years ago by stoecker

In 6796/josm:

see #9611 - proper plural selection also for single strings

comment:19 in reply to:  16 ; Changed 6 years ago by stoecker

Hello,

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

You could have said that much earlier...

comment:20 Changed 6 years ago by 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!

comment:21 in reply to:  19 Changed 6 years ago by 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 ;)

comment:22 in reply to:  20 Changed 6 years ago by 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.

comment:23 in reply to:  8 ; Changed 6 years ago by 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.

comment:24 in reply to:  18 Changed 6 years ago by 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.

comment:25 in reply to:  23 Changed 6 years ago by 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).

comment:26 Changed 6 years ago by Don-vip

Can we close this ticket ?

comment:27 Changed 6 years ago by 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.

comment:28 Changed 6 years ago by Don-vip

Resolution: fixed
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain simon04.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.