Mapillary description translation

[stoecker]

With the switch of translation system the translated descriptions in manifest are missing.

[floscher]

Thank you for reporting this!

I already implemented this, but currently it seems to skip adding the manifest entries under some circumstances.
Currently the Gradle task, that converts *.mo files to *.lang files adds the description to the manifest. If the *.lang files are already compiled, Gradle skips adding that task and also to add the multilingual description to the manifest.
So if you run ./gradlew clean jar it works as expected, if you build only with ./gradlew jar the descriptions are not added.

I'll look into this and fix this for the next release.

[floscher]

As a temporary fix I committed 325c30d.
So release v1.5.12 now has translated descriptions: MANIFEST.MF

I'll provide a more thorough fix via the gradle-josm-plugin (see floscher/gradle-josm-plugin#4).

[stoecker]

Your fix is somehow broken. The Manifest is not fully UTF-8. Maybe a linebreak occuring in the middle of an UTF-8 character?

[floscher]

Hmm, yes you are right, it looks indeed as if multibyte characters are split in two at linebreaks.

I'll fix this and take care of this in the long term fix.

Just to be sure: This didn't cause more serious malfunctions (e.g. crashes) than wrong display of the description, did it?

[floscher]

@stoecker I really don't want to shift the blame, but this is not my fault.
I give the manifest attributes correctly to Gradle, which then produces that manifest for me.
But they are not at fault either: This seems to be either a bug or a feature of Java. Gradle itself relies on the Java class java.util.jar.Manifest to generate the manifest.

The class java.util.jar.Manifest can read the format with cut UTF-8 characters just fine. And guess what, it also serializes an instance of the Manifest class like that (with broken UTF-8 characters).

I set up a minimal code example to demonstrate that: https://github.com/floscher/gradle-manifest-multibyte-demo

In the JAR File specification it says, lines should be no longer than 72 bytes, but it does not say you aren't allowed to cut characters in half. When java.util.* classes write the manifest like that, it seems that this way of writing the manifest is considered to be ok.

I agree it is very ugly that Java does it like that by default, but unfortunately the nature of this problem makes it hard to fix it myself easily.

[stoecker]

I feared that may be the case. We usually don't use the UTF-8 stuff directly in the manifest so it never was an issue. So it is a Java bug (or at least a dumb definition). Are you sure Java correctly handles this? Then I simply may adapt the server code to handle it.

[stoecker]

If possible I'd nevertheless prefer proper (human readable) files. Could you at least file a bug report for Java?

[floscher]

I am pretty sure Java handles this correctly. The Manifest class from Java can read both formats (split inside multibyte character and split between characters).
When I tested with two files that had the same content, one split inside multibyte characters and one split in between characters, the Manifest class reads them to two objects for which manifest1.getMainAttributes().equals(manifest2.getMainAttributes()) yields true.
Serialization is consistently done in the broken format.

I commented on an existing issue for Gradle about the problem that the Manifest class does not preserve the order of the attributes: gradle/gradle#2295 .

Now I'll report this as a separate issue to Gradle (maybe they switch away from the Manifest class) and open a bug for Java (is it better to submit it to OpenJDK or to Oracle?).

[stoecker]

I fixed the server code, so it works (even if ugly).

[floscher]

OK, I reported it now to Oracle and opened a new Gradle issue gradle/gradle#5225.

[stoecker]

For reference I documented behaviour of JOSM reader: https://josm.openstreetmap.de/changeset/13696/josm

[floscher]

gradle/gradle#5225 (comment) would be a fix for the JDK.