Changes between Initial Version and Version 1 of Ticket #9611, comment 5


Ignore:
Timestamp:
2014-01-31T19:00:46+01:00 (11 years ago)
Author:
simon04

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9611, comment 5

    initial v1  
    11OK, if this is the right definition of OsmPrimitiveType, that is used in the dialog, how is the translation supposed to choose the right form?
     2{{{
     3#!java
    24public enum OsmPrimitiveType {
    35            NODE (marktr(/* ICON(data/) */"node"), Node.class, NodeData.class),
    46            WAY  (marktr(/* ICON(data/) */"way"), Way.class, WayData.class),
    57            RELATION (marktr(/* ICON(data/) */"relation"), Relation.class, RelationData.class),
     8}}}
    69
    710
    811In our sk.po file the translation looks like this:
     12{{{
    913#: ../core/src/org/openstreetmap/josm/data/osm/OsmPrimitiveType.java:13
    1014#: ../core/src/org/openstreetmap/josm/data/validation/util/NameVisitor.java:47
    … …  
    1519msgstr[1] "bod"
    1620msgstr[2] "body"
     21}}}
    1722
    1823As 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.
    19 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.
     24There 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.
    2025
    2126The order of the plural forms in our sk.po file also seems strange and poedit complains about it.
    2227This is set in the file header as
     28{{{
    2329"Plural-Forms: nplurals=3; plural=(n==1) ? 1 : (n>=2 && n<=4) ? 2 : 0;\n"
     30}}}
    2431I don't know who or which app sets it and if it is any problem.
    2532The natural order of the forms would be:
     33{{{
    2634msgstr[0] "bod"
    2735msgstr[1] "body"
    2836msgstr[2] "bodov"
     37}}}
    2938
    3039So incidentally, this ordering could fix this bug, but I think it should be fixed properly in the string itself and its context.