Proposal talk:Names localization

Why not put lang tag on boundary relations?

This suggestion has one simple benefit - you don't need to specify lang ta gon every single object, but just on few relations, but to use this you would need to do a spatial query to get the setting from a higher level. And this complicates everything, because...

• Things (multipolygons & boundaries especially) get broken pretty frequently, so a single bug in one relation or way could do a lot of damage.
• It means that you have to check a whole hierarchy to decide if you need to regenerate the value, which means this would be order of magnitude harder to implement in data consumers SW.
• Not all data consumers use whole planet data and if they cut out only a small region, they don't have the higher level in their data.
• You would need to define how to resolve conflicts, e.g. a way spanning multiple lang areas.
• Another conflict could happen, if you have an object with only name:de="Whatever" in the area with lang="en", now what?

-- It is not that bad:

• broken things - Yes, this might be a problem. One that should be solved on the side of editors/user education though.

Yes, but no matter how hard you try, you can count on that these things will happen. --Xificurk 15:02, 1 August 2012 (BST)

• checking hierarchy - I find this argument misleading. Checking whole hierarchy would be the worst case scenario, usually the proper value would be found on a lower level. Even putting this info redundantly on all the regions in lowest levels would be much easier to maintain and by far less redundant than putting it on every single named object.

I'm not really sure how would you actually do that. The problem is that your starting point is a position of specific object and there is no easy way how to incrementally iterate up in the hierarchy. Furthermore, the spatially query finding in what lang area the object is located is not trivially cheap. If you consider, that the amount of objects that actually need language specification is several orders of magnitude lower then the amount of objects for which a single name tag is sufficient, the whole idea of specifying lang on relations seems like an overkill. --Xificurk 15:02, 1 August 2012 (BST)

• consumers using only small extracts - these consumers would very likely be well aware of what language they want to use without looking in any tags. If it is in uniformly speaking area easy, nothing needed. If this extract is from area speaking multiple languages, one necessarily gets at least part of the boarder.

You're right, I retract this objection. --Xificurk 15:02, 1 August 2012 (BST)

• multiple area - That has to be decided already, only now it is decided by the mappers, while it ought to be decided by the renderer - this is an improvement

OK, but you can approach it from the other side - what happens if two relations defining lang are not mutually exclusive, but overlap? --Xificurk 15:02, 1 August 2012 (BST)

• missing names - again not a real problem, but an improvement - simple preference choice

--LM 1 11:28, 1 August 2012 (BST)

What if the name is the same for two languages?

I think none of the proposed solutions work well in the case where a name is the same in two or more languages. e.g. Lana Lana has name:de=Lana, name:it=Lana and name:=Lana. Especially option 2 will fail in this case (you don't want to end up with "Lana - Lana"). --Tyr 23:15, 1 August 2012 (BST)

Interesting point! This is actually another "con" of the Option 2. I think Option 1 might still work - if you use lang=it;de, you're saying name=Lana contains German and Italian name (which is actually the same). This pretty much works - if you want to present the map that has in addition to local signs German or Italian translation, the lang tag notifies you that those languages are already contained in the bare name tag.--Xificurk 23:43, 1 August 2012 (BST)

Why not use simple string comparisons?

Why isn't it enough to simply go through all name:xx tags and look if those string appear in the name-tag? By that you could easily determine in which languages a name is given...

For the "use-case" in the identification of the problem would end up like this:

• Take a look at London: The "name" is "London" and it is the same as name:en, name:de, name:ku and name:sv. But I want to make a map in French, so I add name:fr ending up with "London (Londres)".
• Take a look at Brussels: The "name" is "Bruxelles - Brussel" and seems to be in French and Dutch. As I want to make a map in French, I do not have to add the French name. End up with "Bruxelles - Brussel"

By using option 1 of this proposal one doesn't gain practically anything. Suppose you want to make a map in German: By only looking at the "lang" and "name" tag London you may end up with "London (London)". You wouldn't like that, would you? --Tyr 23:34, 1 August 2012 (BST)

You can always add this check to your tool chain. Generally, this approach works (most of the time), but sometimes the names in different languages are substrings of others. Brussels vs. Brussel, I know this is not really a good example, because you can search for whole word matches only, but I suspect that we could find some name that in one language is "XYZ" and other language mutation contains some additional adjective, like "New XYZ", "West XYZ", etc. Though, I can't think of one right now from top of my head.--Xificurk 00:02, 2 August 2012 (BST)