#18039 closed defect (fixed)
ant updatecore does not rebuild pot files and can lead to incomplete translations
| Reported by: | naoliv | Owned by: | stoecker |
|---|---|---|---|
| Priority: | major | Milestone: | 19.08 |
| Component: | Core | Version: | |
| Keywords: | i18n wood context | Cc: |
Description
At least in Brazilian Portuguese we can use the word "wood" with two different meanings (one if "wood" is a surface/material type (like timber) and the other if we are talking about a forest)
Since there is only one "wood" string, when viewing a multipolygon with natural=wood we see a wrong word being used ("madeira"):
Inside the relation editor everything is fine, where we can see references to the natural=wood preset (and no signs of the wrong "madeira" string):
Could we have, if possible, another "wood" string for this case, please?
JOSM:
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2019-08-11 22:00:20 +0200 (Sun, 11 Aug 2019) Revision:15296 Build-Date:2019-08-12 01:30:56 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (15296 pt_BR) Linux Debian GNU/Linux bullseye/sid Memory Usage: 1327 MB / 6144 MB (714 MB allocated, but free) Java version: 13-ea+30-Debian-1, Debian, OpenJDK 64-Bit Server VM Screen: :0.0 1600x900, :0.1 1280x1024 Maximum Screen Size: 1600x1024 Java ATK Wrapper package: libatk-wrapper-java:all-0.35.0-2 libcommons-compress-java: libcommons-compress-java:all-1.18-2 libcommons-logging-java: libcommons-logging-java:all-1.2-2 fonts-noto: fonts-noto:- liboauth-signpost-java: liboauth-signpost-java:all-1.2.1.2-2 VM arguments: [-Dawt.useSystemAAFontSettings=gasp] Dataset consistency test: No problems found
Attachments (0)
Change History (22)
comment:1 by , 5 years ago
| Component: | Core → Internal preset |
|---|---|
| Keywords: | i18n wood added |
| Milestone: | → 19.08 |
comment:2 by , 5 years ago
follow-up: 6 comment:3 by , 5 years ago
Also "multipolygon" should be "multipolígono"
#. relation type #: build/specialmessages.java:43 msgctxt "Relation type" msgid "multipolygon" msgstr "multipolígono"
Seems name formatter is broken?
follow-up: 5 comment:4 by , 5 years ago
| Component: | Internal preset → Core |
|---|
Replying to naoliv:
- Wood (Heat map)
- wood (Landuse type used in multipolygons)
- wood (used for material, surface,...)
- Wood (name of the natural=wood preset)
The second should be used in the tags membership dialog (your first screenshot) but that seems broken.
comment:5 by , 5 years ago
Replying to Klumbumbus:
Yes, sorry.
I was searching for the wrong string (madeira) and since I found only one entry for it, I did assume that it was being used for every "wood" translation.
follow-up: 10 comment:6 by , 5 years ago
Replying to stoecker:
Also "multipolygon" should be "multipolígono"
#. relation type #: build/specialmessages.java:43 msgctxt "Relation type" msgid "multipolygon" msgstr "multipolígono"Seems name formatter is broken?
Seems broken since r3389 ? You already noticed it 9 years ago but nothing was done to fix the issue? https://josm.openstreetmap.de/ticket/5228#comment:3
comment:7 by , 5 years ago
| Keywords: | context added |
|---|---|
| Type: | enhancement → defect |
follow-up: 11 comment:8 by , 5 years ago
The string floresta/mata nativa is not in pt_BR.lang. It seems we lose translations when we build these files?
comment:9 by , 5 years ago
| Owner: | changed from to |
|---|
Maybe convpreset.pl doesn't like a string to have / in it?
comment:10 by , 5 years ago
Replying to Don-vip:
Seems broken since r3389 ? You already noticed it 9 years ago but nothing was done to fix the issue? https://josm.openstreetmap.de/ticket/5228#comment:3
No. We added the texts in specialmessages.java and also use the trcLazy() function. There must be another reason why translation is not done. Probably somehow the translation splitting is not copying the strings right. Maybe a data file is missing in some cases. specialmessage.java must be used in the core.pot to copy these strings.
comment:11 by , 5 years ago
Replying to Don-vip:
The string
floresta/mata nativais not inpt_BR.lang. It seems we lose translations when we build these files?
It is there:
> ./langinfo.pl ~/josm/core/data/en.lang |grep 7041 7041 14 _:natural\nwood > ./langinfo.pl ~/josm/core/data/pt_BR.lang |grep 7041 7041 20 floresta/mata nativa
There must be another reason...
comment:12 by , 5 years ago
I don't have it:
$ ./langinfo.pl ../core/data/en.lang | grep 7041 7041 16 _:power\ntraction $ ./langinfo.pl ../core/data/en.lang | grep wood 682 174 Bare lower lying uncultivated land with a shrubland habitat found mainly on free-draining infertile, acidic soils, and is characterised by open, low-growing woody vegetati 6474 131 Where vegetation is dominated by grasses (Poaceae) and other herbaceous (non-woody) plants. Excludes cultivated areas and wetlands. 8329 4 wood
comment:13 by , 5 years ago
Ah sorry, I started an "ant update" before driving around. That changed the files ;-)
Can you please try if that is the case on your system as well?
follow-up: 15 comment:14 by , 5 years ago
Just did it on JOSM server, same:
josm@josm:~/auto/svn_josm/i18n$ pwd /home/josm/auto/svn_josm/i18n josm@josm:~/auto/svn_josm/i18n$ ant updatecore .. BUILD SUCCESSFUL Total time: 55 seconds josm@josm:~/auto/svn_josm/i18n$ ./langinfo.pl ../core/data/en.lang | grep wood 683 174 Bare lower lying uncultivated land with a shrubland habitat found mainly on free-draining infertile, acidic soils, and is characterised by open, low-growing woody vegetation. 6497 131 Where vegetation is dominated by grasses (Poaceae) and other herbaceous (non-woody) plants. Excludes cultivated areas and wetlands. 8401 4 wood
ant updatecore does not work maybe?
comment:15 by , 5 years ago
Replying to Don-vip:
ant updatecoredoes not work maybe?
Did an "ant updatecore" now after "ant clean" and the text was missing. Before an "ant clean" it was there.
So "ant updatecore" does not build the full files as expected. "ant update" after "ant clean" did a full build.
follow-up: 19 comment:16 by , 5 years ago
OK thanks. [o35090 should fix the problem]. Sadly it means all i18n updates I made for months were incomplete.
comment:17 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:18 by , 5 years ago
| Priority: | normal → major |
|---|---|
| Summary: | Needs a new translatable "wood" string for multipolygons → ant updatecore does not rebuild pot files and can lead to incomplete translations |
follow-up: 20 comment:19 by , 5 years ago
Replying to Don-vip:
Sadly it means all i18n updates I made for months were incomplete.
Well, and now somebody reported it and it got fixed. Everything fine.
That reminds me of a guy in OSM forum who talked about a "well-known josm bug". Well, nobody ever reported it and thus no josm developer knew about it - it was fixed a few minutes later ...
JOSM is still volunteer only open source and we have to rely on bug reports to fix issues.
follow-up: 21 comment:20 by , 5 years ago
Replying to stoecker:
That reminds me of a guy in OSM forum who talked about a "well-known josm bug". Well, nobody ever reported it and thus no josm developer knew about it - it was fixed a few minutes later ...
Haha, I hate too when people say everywhere (except here) that they're frustrated of a "well-known" JOSM bug but don't take the necessary 5 minutes to report it to us :D Good bug reports lead to good fixes. That's why I credit naoliv as a top bug reporter in my JOSM presentation :)
comment:21 by , 5 years ago
Replying to Don-vip:
Replying to stoecker:
That reminds me of a guy in OSM forum who talked about a "well-known josm bug". Well, nobody ever reported it and thus no josm developer knew about it - it was fixed a few minutes later ...
Haha, I hate too when people say everywhere (except here) that they're frustrated of a "well-known" JOSM bug but don't take the necessary 5 minutes to report it to us :D Good bug reports lead to good fixes.
Partly I can understand that. I did many bug reports in other projects and the overall results are very bad:
- ignoring, even when asking for feedback after 1-2 weeks
- auto-closed due to long ignoring, inbetween version updates (which did not fix the bugs), auto-close bots due to inactivity, ...
- complicated log-in mechanism
- hardly understandable and bureaucratic forms or procedures
Even the reports where I provided source code to fix the issue failed in approx 50% of cases
- e.g. because public domain is not enough for some, they want to force you to transfer ownership, which as a German citizen I anyway can't do
- or because they decide an issue fix is not enough, a total rework is needed, but as nobody has time for that they don't do anything
Maybe that explains why I didn't want the bug-report enforcement you proposed some time ago and instead voted for a softer variant.
I know JOSM bug tracker has its issues as well, but access to it is easy and if the bug reporter is willing to help we do our best to find and fix the problem if possible.
That's why I credit naoliv as a top bug reporter in my JOSM presentation :)
He's probably not happy about all reports he does, but I think the percentage of positive results should be good enough. What do you think naoliv?
comment:22 by , 5 years ago
Actually I don't think it's bad¹ to find and report any problems/suggestions.
Even if it takes a while to get fixed, I am aware that it's a volunteer work.
In any case, you are one of the most receptive and friendly developers/project ;-)
¹ I only don't like when I report some stupid things (which are an user issue); but even in these cases things flow in a friendly way.
We already have a wood with msgctxt "natural" in specialmessages.java in i18n directory. Seems that is not used in this case, but it should.