"Mail Drop Box" is not translated in German

[Vuizur]

On Android, the string "Mail Drop Box" has not been translated into German, but in the iD editor translation data a translation exists. It looks like this:

PS: Thanks a lot for the huge amount of work that went into this great app!

[mnalis]

And which version of Every Door is it ?

That was similar issue for Danish translation of "Mail Drop Box" in https://github.com/Zverik/every_door/issues/707 that was supposed to be fixed in 5.0

[mnalis]

It seems that #707 have only fixed the language displayed when adding new amenity=post_box, but the code displaying existing amenity=post_box is still confused in EveryDoor 5.1.

E.g. for German first image (adding new POI) shows Briefkasten but the second shows untranslated Mail Drop Box:

... and the same bug for Dansk

 

[riQQ]

Could this be related to streetcomplete/StreetComplete#4916?

[westnordost]

So, by the way, for StreetComplete, the issue is the following:

StreetComplete uses the iD editor presets to find the translations of map features. It just looks for the matching feature, given a set of tags and other parameters, and thus accesses the features's associated translation (, icon, etc.).

However, the app currently assumes that features are generally not specific to specific countries.

If they were country specific, it would make things much more complicated, as the country code / geo-position becomes necessary to find the feature that matches an element. This not only requires to find the geo-position (center) of any element in question (and this might be non-trivial depending on how you structure the data, as ways and relations don't own geometry), it also requires to find in which country / subdivision a position is located.

Now, turns out that the iD presets indeed contain features specific to certain countries. What features might be country specific? For example, postboxes.

Snippet from presets.json with country-specific post boxes

```json "amenity/post_box": { "icon": "temaki-post_box", "fields": [ "operator", "collection_times", "ref", "post_box/type-GB", "royal_cypher-GB" ], "moreFields": [ "access_simple", "branch_brand", "brand", "colour", "covered", "drive_through", "height", "indoor", "level", "manufacturer", "material", "post_box/type", "support", "wheelchair" ], "geometry": [ "point", "vertex" ], "tags": { "amenity": "post_box" }, "locationSet": { "exclude": [ "us" ] } }, "amenity/post_box/post_box-US": { "icon": "temaki-post_box", "locationSet": { "include": [ "us" ] }, "fields": [ "{amenity/post_box}", "drive_through" ], "moreFields": [ "{amenity/post_box}", "gnis/feature_id-US" ], "geometry": [ "point", "vertex" ], "tags": { "amenity": "post_box" }, "name": "{amenity/post_box}" }, ```

This is done to tweak the display of presets in the US, e.g. the drive_through field should always be displayed in the US.

IMO this tweak/hack is not worth the added complexity requiring consumers of the presets.json to now also need to be able to locate the element for which a search is made, I wrote it here: https://github.com/ideditor/schema-builder/issues/94 (it was won't fixed)

Anyway, your app does seem to find the preset, so maybe this is not the source of the issue.