[RFC] Feature Proposal - Add languages: tags for name rendering (2nd revision)

General talk Tagging general discussion
,
41

That specific key name is weird, but the concept does make sense. It would be useful and valid geodata to indicate the languages that are signed locally and would nicely deal with cases like the Europe node where the concept clearly doesn’t apply (since the locally signed languages differ depending on where you are in Europe).

42

nul points from the taginfo jury.

1 Like
43

Place names and street names in minority and regional languages recognized in Poland follow after the Polish name on signs, by law. Dz.U. 2005 nr 17 poz. 141 (PDF link for the law as amended), Art. 12, section 5.

See Wikimedia Commons for some example photos.

law wording and rough translation

Art. 12
1. Dodatkowe tradycyjne nazwy w języku mniejszości mogą być
używane obok:
1) urzędowych nazw miejscowości i obiektów fizjograficznych,
2) nazw ulic
– ustalonych w języku polskim na podstawie odrębnych przepisów.

5. Dodatkowe nazwy, o których mowa w ust. 1, umieszczane są po nazwie
w języku polskim i nie mogą być stosowane samodzielnie.

Rough translation:

1. Additional traditional names in minority languages may be used in addition to:
1) official names of places and natural features,
2) street names
set in Polish language based on separate regulations.
[…]
5. Additional names as defined by section 1 are placed after the name in Polish language, and cannot be used standalone."

Also related to this proposal, section 2 of Art. 12 of same law indicates that these additional names can only be used in certain municipalities as prescribed elsewhere (in practice 20% of population counted in the census as minority/regional language), and section 4 indicates that they can be used throughout the municipality or only in some of its settlements.

I’m not sure this is a good idea. If a government administering a given administrative area (e.g. a city) makes it their policy to put up multilingual road signs, then that’s most easily and intuitively tagged on the city boundary, even if this is merely a policy and not a law or bylaw.
Separately tagging every single street in e.g. Ottawa with languages:presentation_order=fr;en would be truly something.

44

My understanding is that this is what the proposal really intends to achieve. If correct (@aseigo would have to confirm), your help formulating and phrasing it would be appreciated.

(For starters, we’d probably want to put in something to explicitly say this won’t apply to areas that have no administration, like international waters (unless someone wants to tackle cases like the Baltic with 9 languages in name). That would also apply to Europe the continent.)

45

I would call it something like languages:displayed, which should also naturally exclude water features.

46

If so, it would be basically a reprise of the information that the twice-rejected name:language=*/language:*=* proposal sought to encode, combined with the rejected default:language=* proposal and de facto default_language=* approach of encoding defaults on boundary relations. Maybe three wrongs can make a right, and I mean that kindly. The big question is whether people will really view this mechanism as an alternative to name=*, given the lingering resistance to tagging redundant name:*=* tags in some countries.

47

… and we can’t expect to handwave them :slight_smile:

… yeah, I did, further down the paragraph

“What will be the impact of this proposal on Morocco? Hong Kong? Nunavut? Eritrea? India? Please give specific examples of tags that are proposed to be applied.”

No, but, like, more than three western countries described in text (ok, you get half a point for noting that there’s a lot of languages in South Africa).

I looked around the map as we have right now for something like 3 minutes and noted some regions that currently use multiple scripts in name. It’s not an extensive list and I’m not an expert by any means. But I think these are the kind of regions that a proposal like this should consider, because they empirically demonstrated the need is already there, and a global proposal would affect them.

Or, if you don’t know enough about them and don’t think they’re relevant for your goals, then explicitly restrict your proposal in scope.

I am largely in favour of the idea in this proposal, but I do think that if it’s not written well, you’ll find out some of its problems at voting time: “Oppose, what about this region?”, “Oppose, unclear how you’d tag $thing”. People will come out of the woodwork with their pet examples, and it helps to look like you’ve considered a bit more than three countries for a proposal about names.

Sorry to be blunt, but have you checked any recently accepted proposals to see what is generally expected? Or any rejected proposals to see why they were rejected? The template in Proposal process - OpenStreetMap Wiki includes sections “Tagging” and “Examples” the latter of which suggests to contain “Examples of what elements should be tagged: real-world images, openstreetmap.org screenshots, links to OpenStreetMap elements that use the proposed tagging.” The proposal is unlikely to succeed in voting without these. If you’re unfamiliar with the OSM proposal process, it’s better to mention this and look around. Or, if you don’t intend to bring it to voting soon and are hoping mostly to collect feedback on the technical feasibility of the idea, it might also be useful to state this explicitly. (That was also why I asked what stage you think this proposal is at.)

Then I would suggest stating so in the proposal. “This proposal does not define the content of name tag as this is a large and potentially unresolvable issue and solving it is not necessary for goals of this proposal” or something.

48

To be frank, it’s not clear to me why this proposal is a “reprise” of those ones, but thank you for linking those for context of past discussions about names and languages.

(My thoughts after skimming the past ones, based on my understanding of this one:

The latter two seemed to be metadata about the contents of the name tag, whereas this proposal ignores name tag altogether as an intractable mess, and instead defines what the feature name should be based on presentation_order and name:<lang> tags.)

Can you link us a bit about that? Are these countries multilingual?

49

Thanks. Despite being a national(?) law, tagging it there would lead us to the StVO example, because it doesn’t apply everywhere, but only where it is registered to be. Also, the relevant language might change too. And also not everything, just old buildings and traditional street names.
But we are OSM, and probably everything around it is fine to use the same ordering. The StVO defaults also don’t apply everywhere in Germany.

Someone already tagged the name tags, so…
Anyway, abstracting that away is probably best for this proposal. Figuring out a way to record what actual signage on the ground shows is probably out of scope.
In essence, this proposal wants to simplify and standardise tagging and construction of specific structured names. To have some connection to reality, that structure is based on laws and local conventions. But at the end of the day, it is a fictional name more or less solely intended for abstract maps.
Which is OK. But the proposal doesn’t acknowledge this at all, probably because it is the current default. Nevermind that this default is not real itself.

Sorry for the rant, I need a few days off this discussion…

50

Yes it is a national law (it’s part of a law on ethnic minorities and regional language), and yes it’s clear to me that the new presentation_order tag would only be tagged on municipality or place relations where it applies - anything else seems like weird legal hangups about who makes the rule vs where it applies.

Yes but not every street in Ottawa has the same name.

No, not really. It’s a way to indicate which of the names should be displayed (or spoken). It standardizes construction of labels, not names.

51

Yes, to be clear, those older proposals were only related in spirit. The technique of reconstructing a name=*-like value without using name=* wasn’t part of those proposals, but it was discussed before and after them, including in the blog posts I linked.

The lingering resistance to name:*=* comes from mappers who believe their countries to be monolingual for all practical purposes. This mailing list post summarizes the sentiment well, as does a followup concession. But it comes up quite frequently. I’m totally fine with ignoring this sentiment apart from some humor at its expense. That said, we all draw the line somewhere. Not many mappers savor the thought of pairing absolutely every name=* in a region with a name:*=*, especially if they edit with a more manual editor such as JOSM. It’s also fair to ask whether some kinds of features have mostly untranslatable names, such as shops and graves.

If any data consumer is going to go through the trouble of implementing support for these relation-based tags in postprocessing, then they aren’t going to do it one way for multilingual countries and another way for monolingual countries, and a blend of both for monolingual feature types in multilingual countries. The experiment in the latter blog post went out of its way to hide the label entirely if a redundant name tag is absent, but that’s very opinionated. Consumer-facing data consumers won’t do that willingly.

1 Like
52

However, I applaud the creativity in translating an entire legal code to a Turing-complete programming language.

and right now it is only covering few of the prescriptions, it would/will become quite unwieldy when more stuff is codified, e.g. various parking prescriptions like you may not park outside marked stalls in a living street, or minimum parking distance from railway crossings or road crossings.

1 Like
53

They are the same as the other examples provided in the proposal.

A list of prescriptions for local mappers in the proposal oversteps the bounds of the proposal, which is about what tags we can use not what the content of them would be, and I would expect it to create even more rabbit-hole discussion.

What is included are use case exemplars. It is not intended, nor can it be, a representative list of specific places in the world people speak multiple languages and include them in their naming and signage.

What is included are:

  • a First Nations example to show how the tags allow adapting to language changes in a specific region;
  • an city where language preferences change across the city’s boundaries;
  • two consistently multi-lingual cities which are self-consistent, but inconsistent with each other;
  • a capitol city with a different language order than the names within it (an interesting edge case);
  • and a multilingual country with a large number of languages where the different languages are spoken in different regions

As use-case exemplars, it does not matter where they exist, but that these are use cases that need to be accommodated.

If use cases different from the ones above are identified in the real world, then examples for those can be taken into consideration and added to the proposal.

If that helps you, I’m happy to add it.

54

Why shouldn’t languages:displayed:self be applied to rivers forming an language border? See https://wiki.openstreetmap.org/wiki/Multilingual_names#Shared_boundary_features

Example: Way: ‪Le Rhin / Rhein‬ (‪99035781‬) | OpenStreetMap

55

Quick note: I’ve updated the proposal with various clarifications, including:

  • It does not define how name should (let alone “must”) be used
  • That the examples provided are use cases, and I moved the use case for the self tag to there as well.
  • How to suggest new use cases for inclusion.

Hopefully this will help communicate the intent more effectively.

56

I agree that in such cases the :self tag would be appropriate.

This is something that the local mapping community can identify, of course, so that we don’t need to find the “one size fits all” set of rules while still offering useful and sufficient tools.

57

The proposal currently attaches the two keys to boundary=administrative and boundary=aboriginal_lands. boundary=political political_division=linguistic_community might be a natural fit for the proposed keys too, but note the caveat about Catalan.