There are a few ongoing discussions on the OSM Community forum about the use of the name tag for features in multi-lingual contexts. The problems stem from treating the name tag as the to-be-rendered localized name.
Improvements that address the main concerns could be made by giving renderers enough information in the OSM dataset as to how to select appropriate name: tags for rendering in a given region.
A new languages:presentation_order tag for use (primarily) on administrative boundaries is proposed to do just that. A detailed description of the problem and how this tag could address the issues are found on the OSM wiki here:
This is the second revision of this proposal. Discussion of the first version of this proposal can be found here.
A big âthank-youâ to everyone who has provided feedback so far. The number of examples, interesting edge-cases, oddities, specializations, and concerns that have been collected has been fantastic and helpful! They have helped shape the second revision of this proposal
âThis proposal only affects default rendering before any application-specific user preferences are applied.â
Not really, it overstates things. Proposal on Wiki cannot achieve this.
default rendering in a given map/project/app/design may still do whatever it wants
This invented key can be at most providing some extra info, to be used by rendering, if creator of given map design decides to use it.
If map style is designed by someone they may decide to display value of amenity tag as a label (and for some types of debug it may even make sense). Or use languages:presentation_order:self - or ignore it.
Indeed, a renderer can indeed do whatever. The reason for mentioning that this does not preclude user preferences is that in the last iteration people asked specifically about this.
This proposal does not set a policy that intends to override user preferences in applications, neither by suggestion or policy.
Clearly this is a general tagging system for multi lingual named OSM features regardless of any attempt to constrain it. The question of massively multi lingual names is a valid one and needs to be addressed, not ignored.
Can you provide an example of a massively multi-lingual name in the real world? I find it easier to discuss actual examples.
FWIW, if all else fails, one simply falls back to using name.
Also note that this is intended to be a â99% solutionâ, as failing 1% of the world would be far better than failing 100% of it as OSM currently does. Perfection shouldnât be the goal here, merely âas good as can be reasonably expected, though no lessâ.
How many languages are used in any one e.g. municipality? How many languages do streets there appear in? 840? 10? 3? 2?
Papua New Guinea itself has three official languages.
There are 22 administrative divisions in Papua New Guinea. One of those with several spoken languages in a relatively small area is Milne Bay with 48 languages in under 15,000 square kilometers of land and only 276,000 +/- inhabitants. In the capitol city of Alotau, On both OSM and Google Maps, streets are labeled in one language only. Looking at images of street-level signage that I can find online, the town has signs on e.g. shops in only one or two languages.
Looking at the language usage in street and shop signage, this proposal seems to be alright for Papua New Guinea?
This isnât very surprising, really. For purely practical reasons, we tend to name things using a limited number of simultaneous languages. And those choices tend to be regionally (neighbourhood, city, province, âŠ) consistent.
It sounds like what you really want to express here is official languages. That would be a better and tighter proposal than preferred language, and doesnât have the interpretation issues that a preferred languages tag has. If so, a different key should be used.
Interestingly, the first iteration of this proposal named the key âlanguages:officialâ with a secondary âlanguages:preferredâ. Those tag names caused some confusion and argumentation around political topics that are not overly relevant to the question of âwhat languages are are used for names of places in this area?â
Due to this being a common response to the tag names, alternatives were discussed, and âpresentation_orderâ seemed to avoid socio-political discussion and be clear as to the intent, namely: âwhich languages, in which order, should be displayed for place names?â
Keeping in mind that OSM is full of non-intuitive tag names, such as âlanduse=allotmentsâ for community gardens, and that anything that references official mandates causes peopleâs hackles to rise, is languages:presentation_order at least nominally acceptable?
Even more importantly than the name of the tag: do you feel the content of these tags would be sufficient to improve rendering? (Assuming renderer adoption, of course.)
If ânoâ to either of the above, an explanation of why that is so would help me understand and improve the proposal. Cheers!
TBH, I would like to suggest more examples of suggested tagging in the proposal, because itâs hard to find potential problems with something as wide as names when you give only two practical examples.
(I know itâs a bit unkind from me and Iâm sorry, but I get the sense that those two examples are your bugbears, and that might give the impression that you havenât really thought out what the impact will be on elsewhere.)
Another nitpick-but-not-really: the proposal states that the languages:presentation_order tag âwould be applied to administrative boundariesâ, but boundary=aboriginal_lands areas arenât âadministrative boundariesâ in OSM sense (and some might not be in legal sense). Similarly, the Sorbian area doesnât precisely line up with administrative borders of municipalities, so itâs a boundary=protected_area, should that be the object tagged? And what exactly would be your tagging solution to situations like Saint-Boniface in Winnipeg â which OSM object would be tagged, or would a new one be created to represent the extent of where municipal signs are multilingual?
Finally, I would suggest to discuss how the name tag should be used in multilingual areas if this proposal was adopted, if only to avoid confusing discrepancies between maps created using the languages:presentation_order tag and maps created using the name tag. Do you see it being dropped? Then lots of QA tools would have to be updated. Do you see it being manually updated with some text format to match presentation_order names? Do you see it being left as is? Or something else altogether?
The presentation order of languages is fundamentally rendering styling and not geodata, and subject to interpretation. Whereas, a listing of official languages is actual geodata, is verifiable, and only applies to boundaries.
The suggested languages:presentation_order implicitly applies to anything with a name. So, that scope need to either be narrowed or else the proposal needs to deal with the fact that it can be applied to any named feature, such as the Europe node.
There are five practical examples given which each demonstrate different classes of challenges that arise from lacking language metadata.
Two are expanded upon as a demonstration of application, but it applies to all five examples given.
That said, How many examples would you consider sufficient?
boundary=aboriginal_lands areas arenât âadministrative boundariesâ in OSM sense (and some might not be in legal sense
That could definitely be added to the proposal if these boundaries also map to language presentation preferences.
Due to the OSM outage at the moment, I canât check on taginfo. When it is back up I will check.
If it does indeed map uniquely (as in: they occur separate from administrative boundaries that ought to have language preference), then it should definitely be added alongside administrative boundaries.
If you have any examples you could point me towards, that would save a bit of time and effort, of course!
And what exactly would be your tagging solution to situations like Saint-Boniface in Winnipeg â which OSM object would be tagged, or would a new one be created to represent the extent of where municipal signs are multilingual?
Aside from it being up to the local mappers, Saint-Boniface is a recognized city ward, so could be represented on the map with an administrative boundary.
If the bilingual signage in Winnipeg does not align to administrative boundaries, then there would need to be some digging there to find a solution indeed.
I would suggest to discuss how the name tag should be used in multilingual areas if this proposal was adopted,
Honestly, it appears to be an intractable problem.
There are so many discussions that have been had on the topic, many without clear conclusions and even more that have resulted in regionally-specific guidelines which conflict with those from other regions.
The proposal explains the issues with using name in multilingual contexts, and I expect no good answer there. If there was one, would this proposal even be needed? Probably not.
if only to avoid confusing discrepancies between maps created using the languages:presentation_order tag and maps created using the name tag.
That is, unfortunately, unavoidable. No matter how one decides to cram multiple languages into name, if renderers have a way to customize rendering there will be differences. (Consider the case of separator characters, e.g.)
That said, Iâm not sure what would constitute a âconfusing discrepancyâ. Can you can provide a real-world example that would affect a non-negligable number of users?
Do you see it being dropped?
Not in the forseeable future, as that would cause major backwards compatible problems all over, from renderers that arenât using the new tags to parts of the OSM database that arenât updated for however long it would take.
Eventually? Maybe, but also maybe not. Itâs simply not in scope for this proposal.
Then lots of QA tools would have to be updated.
Indeed, improving language mechanics means software needs updating to take advantage of the improvements. And not only QA tools, but other tools as well.
Do you see it being manually updated with some text format to match presentation_order names?
No; in fact, the pain of manual updating to follow language conventions is a reason for the proposal, as cited in the proposal.
Do you see it being left as is? Or something else altogether?
It could be left as-is. It could be re-rendered using automations that follow the language preference data once it is in there.
That could well be left up to the community and local mapping groups afterwards once the language metadata is there. This is probably a parallel discussion to the proposal, as it is as true right now given all the errors and inconsistencies already in the OSM dataset around multilingual names, regardless of what happens with this proposal.
What this proposal would give OSM is a way to move forward with improvements, yes even to name tag content. This proposal does not rely on such improvements being made to name tags however.
I have to disagree. We can look at physical signage and listen to people on the street of multilingual locations to know that it absolutely is part of the geographical data of an area. You can not produce a map that is accurate to such a region without knowing the intended set of languages to be used, and the standard ordering of them on e.g. signage.
Changing the name of the tag from presentation_order to official does not alter the content of the tags, nor how they would be used.
The reason it was changed from official to presentation_order was specifically to avoid the political arguments, and frankly the level of emotive response, it caused. Itâs the âname of least harmâ, if you will.
It already does, in two different ways:
a) The Europe node is a place:continent, and as such it does not belong to a country administrative boundary, which is the âupper limitâ of the languages hierarchy.
b) A languages:presentation_order:self tag could be added to the Europe node noting its specific language preferences for name rendering.
âThe proposed tags are intended to be applied only to default name rendering an application performs before any application-specific user preferences (e.g. user locale) are applied, and as such would not interfere with user preferences in applications.â
âThe proposed tags are can be used by application for showing names. It is not intended to be used if specific user preferences (e.g. user locale) are set. And as such would not interfere with user preferences in applications.â
can be more clear that use of this tag is entirely optional as usual?
It might be useful to alert the developers of osm2pgsql to this discussion. For raster-based renderers and vector-based renderers that use a PostGIS database, the obvious place to do the (non-trivial) work of evaluating the display order for a given object is at the âingestionâ stage. They will have a better understanding of the effort involved.
An optimistic scenario is that a common chunk of Lua code could be developed to do the job. On the other hand, a major slowdown in import times could be showstopper.
I would expect at least five examples from around the world. More and different cases would probably be helpful. You like to discuss concrete cases, and so does everyone else. 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.
To me, multilingual names of features are the subject most likely to cause controversies in OSM, or perhaps second only to disputed country borders. Names are intensely political and cultural and we canât expect to handwave them.
What stage do you currently see this proposal at? I think it should definitely be fleshed out with more guidance and more concrete examples before it goes to a vote to be adopted, but if youâre looking to get more thoughts (than the posts already on the forum) then perhaps it doesnât need more details - though it might benefit from being circulated on forums other than this one. Other alternative could be to reduce the scope, so for example rather than creating a tag to be used globally (!), define it only for Switzerland.
Itâs great that it would be up to local mappers, but a proposal aiming to improve tagging of names worldwide should probably make some suggestions and recommendations on how to tag things, or we might end up with another mess as local mappers worldwide interpret the accepted guideline differently.
Iâm thinking of a scenario where name tag is updated independently of name:<lang> and languages:presentation_order tags, or vice versa, whether out of oversight or on purpose, so that the names presented are now different even discounting formatting. Something like Relation: âȘIqaluktuuttiaq (Cambridge Bay)⏠(âȘ6007219âŹ) | OpenStreetMap (Cambridge Bay - Wikipedia) ending up with name=Iqaluktuuttiaq, name:ikt=Iqaluktuuttiaq, name:iu=ááááááŠááá , name:en=Cambridge Bay, and languages:presentation_order=ikt;iu;en.
