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

Further address-formats customization #3639

Closed
wants to merge 15 commits into from
Closed

Further address-formats customization #3639

wants to merge 15 commits into from

Conversation

MKuranowski
Copy link
Contributor

A second take on merging my fork, as the first one didn't pass tests.

A reponse to #2254.

Adds optional properites to address-formats.json:

  • dropdowns: List of fields which should have a dropdown with nearby features
  • customPlaceholders: List of fields with custom placeholders. They need to be defined same as other placeholders (in /data/presets/fields/address,json), but with id followed by country code (e.g. "postcode!us")
  • widths: An object with field widths of specified fields
    If they aren't defined, the previous defaults are used.

I've also added public bath preset and Japanese address scheme.

@bhousel
Copy link
Member

bhousel commented Dec 8, 2016

I took an initial look, but I don't really understand the need for country-specific placeholder keys like postcode!us embedded into the addressFormat dataset, and it kind of feels awkward. Unfortunately those would end up getting translated into every other language, and I think it would be very confusing for translators.

e.g. In addition to translating the word "subdistrict" they'd also need to provide a translation for "whatever-the-subdistrict-field-is-used-for-in-vietnam".

@1ec5 you had mentioned this in #2252 - is it really necessary? I'm not convinced that the added complexity in the dataset and the translation justifies the benefit of having the placeholders change depending on what part of the map someone is looking at. Put another way - displaying "Post Code" instead of "ZIP Code" is not causing anybody to enter wrong data.

@natsuyasumi, aside from that, it's better for me as a maintainer if you could split the PR up into smaller units of work.. Make 1 PR for the public baths (which seems fine, and I'd probably just merge), and a separate PR for the address changes (which warrants further discussion, and I'm really unsure about). And when you have WIP commits and reverts, a nice thing to do is rebase your tree (or cherry-pick) to remove those.... All of this stuff, I can do it for you, but I might not get around to it for a while.

@MKuranowski
Copy link
Contributor Author

Ok, I'll create seperate PRs for Public Bath scheme and for the address changes.

I see what you mean with the translations - I'll do more explanation in the new PR.

@1ec5
Copy link
Collaborator

1ec5 commented Dec 12, 2016

e.g. In addition to translating the word "subdistrict" they'd also need to provide a translation for "whatever-the-subdistrict-field-is-used-for-in-vietnam".

you had mentioned this in #2252 - is it really necessary? I'm not convinced that the added complexity in the dataset and the translation justifies the benefit of having the placeholders change depending on what part of the map someone is looking at. Put another way - displaying "Post Code" instead of "ZIP Code" is not causing anybody to enter wrong data.

Postcode isn't a great example, since the concept is nearly universal, but district and subdistrict are better examples. It's nice that OSM has dedicated addr:state and addr:province tags. But imagine if that were not the case. That's the current situation with district and subdistrict in countries where divisions and subdivisions of states/provinces are included in addresses. Each country has a different name for a division of a state/province. A user seeing "district" wouldn't know that it's also intended for the Vietnamese administrative unit known as "town" in English.

@1ec5
Copy link
Collaborator

1ec5 commented Jan 4, 2017

@bhousel, the Japanese address format added in #3712 is a perfect example of why we need the ability to translate the placeholders on a per-country basis. In Vietnamese, addr:county must be translated as “huyện” for Japan. But the same tag is also used in many other countries for administrative units that would be translated as “quận”, “hạt”, or “xứ”, where “huyện” would refer to a distinct administrative unit somewhere else in the hierarchy.

@bhousel
Copy link
Member

bhousel commented Jan 4, 2017

@bhousel, the Japanese address format added in #3712 is a perfect example of why we need the ability to translate the placeholders on a per-country basis.

Oh yeah I should have updated this ticket, but after looking at #3712, I do understand why this is important. addr:quarter and addr:province just look really out of place in a Japanese address.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants