* the choice of suggesting tagging the language information on either > the administrative boundary relations or the individual features but > not on any other feature with a meaning beyond the feature itself was > not arbitrary. >
Are you objecting to the idea of tagging places as well as boundaries? What about the protected area / aboriginal lands boundaries? I was trying to avoid tagging individual POIs and features with language:default=xxx, to reduce the workload on mappers. Is it not yet feasible to associate nodes with the nearest place? > * the choice of syntax for the language string is something that can be > discussed obviously. You can essentially use any characters that are > unlikely to occur in an actual format as structuring elements. The > dollar sign is a common symbol prefix here. > OK, but is this necessary for it to work? Is a 3-letter ISO code sufficient? Would it be possible to put the language code in the key (language:<code>=default) or is it better to stick to the value? > * the core of my proposal is not using the plain "name" tag any more for > anything other than legacy fallback if other data is missing. Any > proposal to separately tag the language of the name tag ... is a very > different idea. > Functionally both ideas work the same, right? In particular, tagging specific POIs with language_format=<code> or language_default=<code> is tagging the language of the default name, unless the two tags were added by different mappers with opposing ideas. I didn't want to bring up anything about deprecating the defaul name=* tags or stopping rendering them. That can be discussed sometime in the future if this proposal catches on. TL:DR: 1) Do we really need that $ symbol? 2) Language code in value vs key? 3) Tagging settled places?
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging