name:el-Latn for romanized versions of street names in Greece?

westnordost · 2020-07-17T21:55:14.000Z

Hello all!

I understand it is common practice in Greece to use int_name for the romanized version of the Greek street names.

So far, StreetComplete users will usually tag the romanized version of Greek street names as name:en. A Greek user started an issue about it in the bugtracker of StreetComplete. Further below in that issue, I added a research into the actual usage of the name tags in countries with street signs that have multiple names in different languages/scripts. Read it here:

https://github.com/westnordost/StreetComplete/issues/1953

Basically, I agreed with the Greek user that using name:en for that is not really correct, but actually, int_name is neither: The same as English does not equal “International”, so does Latin Script not equal “International”. The most correct tag would be actually name:el-Latn for a romanized version of the name in Greek.

What would you think about if users of StreetComplete would use the tag name:el-Latn when they enter a romanized version of a street name?

I also started at topic in the Thai forum because they use name:en for romanized versions of the name in Thai script.

Map-Finder · 2020-07-19T07:46:07.000Z

Welcome to the greek section westnordost.
As I mentioned in an other topic, if we use name:en is a wrong decision, equal as using name:fr, de, it and so on.
I think int_name is an acceptable tag, the tag el-Latn will not be recognised by any software of navigation!
Anyway, there is the way of transliteration.

westnordost · 2020-07-19T12:52:28.000Z

Map-Finder:

Anyway, there is the way of transliteration.

You mean automatic transliteration? Yes of course, I’d even say this would be the preferred way. However, if a second name is given on the street sign itself, I think it is reasonable to also record that name. If only because sometimes, the romanization used on the street sign is not the correct one, so it is good to record the name as written on the sign.

Map-Finder:

I think int_name is an acceptable tag, the tag el-Latn will not be recognised by any software of navigation!

Are you sure about this? name:xx-Latn is not exactly fringe tagging, it is used massively in Korea and Japan. Any software that works for these countries, will have to implement a fallback like that.

Also, what about the support for int_name then?

Yesterday, I noticed that in StreetComplete itself, there is not a proper fallback, so I tried to implement both int_name and name:xx-Latn. I ultimatively failed and I failed at int_name actually. Here is some insight into my experience:


function getDisplayName(tags: Map<String,String>, userLang: String, userScript: String, countryLang: String, countryScript: String)
{
    // for example, userLang="de", userScript="Latn"

    // Preference #1: Take name in own language. No problem here
    val nameInUserLang = tags["name:" + userLang]
    if (nameInUserLang ) return nameInUserLang

    // Preference #2: Take "International" name.
    val internationalName = tags["int_name"]
    if (countryLang != userLang && internationalName) return internationalName 
    /* PROBLEMS! 
       1. Where to get information from in which country the element this is about is located? Need a country-level 
          reverse geocoder that works extremely fast, because it is going to be queried for every single element 
          that theoretically has a name!
       2. Where to get information from what language is spoken in that country? Need a complete list of language 
          by country. What if the country has several (official) languages?
		  
       This MAY be solved differently but only if the name in the country's language is ALSO tagged as name:xx
       alongside the normal name tag. Because through this, the official language of the element can be ascertained.
    */

    // Preference #3: Take name that is at readable in user's script (usually: romanized name)
    val nameInUserScript = tags["name:" + countryLang + "-" + userScript]
    if (countryScript != userScript && nameInUserScript) return nameInUserScript
    /* PROBLEMS! 
       1. Same as above, where to get the language info for the country from?
       2. Where to get the information from what language uses which script? Some languages optionally use several
          scripts
		  
       Unlike for "int_name", point 1 can be solved differently so no geocoder is necessary: Just take ANY name in the
       user's script (for example using regex "^name:([a-z]{2,3})-Latn$") if the script of the language in the tag has
       a different script than the user's script.
    */

    // Preference #4: Take name in English (cause it's kind of "international") language
    ...

    // Preference #5: Take name that is readable in Latin (cause it's kind of "international") script 
    ...
	
    // Preference #6: Take name of any other language whose script is the same as the user's script
    ...

    // Preference #7: Take name of any other language whose script is in Latin (cause it's kind of "international") script
    ...

    // Otherwise, normal name
    return tags["name"]
}

Ok, this code snippet got longer than expected, mostly because of the extensive comments. The learning from this attempted implementation are

For most reasonable fallbacks, it must be known what is the language used in the name tag. So for data consumers, it is very convenient if the name is duplicated into the name:xx key. However, a proper solution always requires a reverse geocoder by country (I wrote one for StreetComplete) and a list of official languages by country code (I did that for StreetComplete)

It is pretty much the same complexity to implement name:xx-Latn as int_name

SucreRouge · 2020-07-20T20:24:14.000Z

Hi!

I don’t see why int_name shouldn’t be used. In Greece (as well as most countries of the world) the transliteration of names in the Greek alphabet to names in the Latin alphabet serves as the international version. Don’t know why int_name should be used if not for that exact reason. Latin Script *does *mean international version in Greece, that’s what I am saying. We should also check why the community in Korea and Japan, agreed to use name:xx-Latn instead or along with int_name, because the reasons there may not be relevant in our case here.

westnordost · 2020-07-21T16:02:26.000Z

Ok, I am ~~not~~ implementing to offer “int_name” to the user in StreetComplete instead of “name:en”

Edit: meant to say that I will implement it, don’t know how the “not” slipped in there

SucreRouge · 2020-07-23T07:59:04.000Z

In my opinion, I think that StreetComplete should use int_name instead of name:en, and should be implemented. My disagreement lied to the name:xx-Latn key.

Thanks again!

Edit: As I saw in the issue on Github you will actually implement the int_name, and not give an option for name:el-Latn for names in Greece. I think this is the correct practice.

westnordost · 2020-07-23T12:34:58.000Z

Oh! Yes actually I don’t know how the “not” slipped in into my last post! I meant to say that I **do **plan to implement it

More info here: https://github.com/westnordost/StreetComplete/issues/1953#issuecomment-662522976