Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Mail Drop Box" is not translated in German #763

Open
Vuizur opened this issue Jul 27, 2024 · 4 comments
Open

"Mail Drop Box" is not translated in German #763

Vuizur opened this issue Jul 27, 2024 · 4 comments
Labels
bug Something isn't working micromapping Micromapping mode tickets
Milestone

Comments

@Vuizur
Copy link

Vuizur commented Jul 27, 2024

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:
unnamed

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

@mnalis
Copy link
Contributor

mnalis commented Jul 29, 2024

And which version of Every Door is it ?

That was similar issue for Danish translation of "Mail Drop Box" in #707 that was supposed to be fixed in 5.0

@mnalis
Copy link
Contributor

mnalis commented Jul 29, 2024

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:

small_Screenshot_20240729_040930_Every Door small_Screenshot_20240729_041515_Every Door

... and the same bug for Dansk

small_Screenshot_20240729_040833_Every Door small_Screenshot_20240729_040907_Every Door

@riQQ
Copy link

riQQ commented Jul 29, 2024

Could this be related to streetcomplete/StreetComplete#4916?

@Zverik Zverik added bug Something isn't working micromapping Micromapping mode tickets labels Sep 21, 2024
@Zverik Zverik added this to the 5.2 milestone Sep 21, 2024
@Zverik Zverik moved this to Todo in Every Door Sep 21, 2024
@Zverik Zverik modified the milestones: 5.2, 6.0 Sep 22, 2024
@westnordost
Copy link

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
    "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: ideditor/schema-builder#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working micromapping Micromapping mode tickets
Projects
Status: Todo
Development

No branches or pull requests

5 participants