IMO you should feel free to copy the contents of the name:th tag to a new name tag. I generally use three name tags when I add data. I’m not sure where I picked up that habit but since I use presets for many common objects it’s a simple matter to paste Thai values into those two tags. Of course I use a name:en tag too.
I’m in the United States now and tagging here is so easy. Only one tag for names. And I can read the road signs without using a translator. LOL
I believe the name:th field is mostly used to make it easy for computers to parse languages.
If you look at the name field on a global scale, then it contains many different languages. If I want to create a map in only Thai language, but for the entire world, then it is easier to just render name:th without worrying which country the actual node/way/relation is in.
I don’t know the full history of the tags, but they are being used. I believe I picked it up on the OSM-Talk or OSM-Tagging mailinglist - if you are interested in the specifics, then I can try and do some more digging.
No, I use only the name tag here. I think it might have been Stephan that got me thinking about adding the (unnecessary) name:th tag. My feeling about name:th is that it’s easy to add and doesn’t hurt anything. At the same time I realize that it’s both redundant and unnecessary. You sometimes see important or popular objects outside of a particular country tagged in several languages. I suppose that’s so the names of those objects can be easily read by a worldwide audience. I dunno - YMMV
I believe important objects that have specific names have name:th tags, e.g.:
I still have to research more on why it is important. But it fundamentally falls back to the fact that you don’t actually know what language the name tag is in.
Many brands, like Makro, are promoting their international name - which is what goes into the name field, but technically it also have a Thai name. In Thailand detecting whether something is Thai or English might be easy because the character set is different, but for countries like Switzerland it is more difficult to know if the name field contains the German, French or Italian name.
Having name:de, name:it, name:fr allows you to easily find the name in the language you want.
Now Thailand isn’t really multilingual in this way, though I guess there could be some mountain villages that could have Lao or Burmanese names - but also a name in Thai.
Anyway, I still need to do my research, just adding more details from memory.
Trying to research the reason name:th is added, I came across this:
Unfortunately it didn’t really clarify the reason. The section on Thailand obviously lists they way we are currently doing it, and I am not using this as an argument to keep doing it (I think it was added by Stephan), but look at how many other countries are doing it as well.
Anyway, I’ll keep looking - I am sure there are some really good reason to do it.
I don’t mind people not adding the tags, but please don’t delete the existing ones even if they seem redundant.
Ok, found a little more information on the topic.
Now the example I am going to give is probably rather dumb and would likely never happen, but don’t want to spend too much time on a realistic example if this gets the point through.
Imagine that all the Burmanese workers in Thailand wanted to render there own map for the Thai/Myanmar website that covers Myanmar and Thailand. The people that cross from Myanmar to Thailand speaks Burmese and Thai, a few speak Shan and only very few understand English.
The rendering engine would therefore have the following language priority: Burmese, Thai, Shan, English, and Local.
To make my case more valid, there are many users that cannot read the Latin letters at all.
Here are the rendering priorities with and without name:th:
- name:bur, name, name:shn, name:en
- name:bur, name:th, name:shn, name, name:en
Option #1 can show English names if no Burmese translation exists, we are using non-Thai in the name tag for international brands, or businesses primarily targeting an internal audience like hotels.
Option #2 will only show the English names if Burmese, Thai and Shan translations doesn’t exist.
So having name:th provides some language possibilities that would otherwise not be available. My example is not great and was written rather fast, but I am sure there are other problems like this I haven’t even considered.
Yes, I don’t really think it is confusing. The value in the name tag is the primary name the locals would use for it. Lets say a two Thais wanted to meet at a Toyota shop and communicates via chat. Would they write Toyota or would they write something in Thai letters. If they would use “Toyota” then I believe that is what needs to be in the name tag.
Taking a quick look at a Thai Toyota fan page it looks like they write Toyota in latin letters:
When a Thai look at the names fields it should contain something that makes sense to him. If you just use Thai letters to spell Toyota, I am not sure if that feels natural to read.
As a foreigner, I don’t think I can answer this question.
What I was trying to say is that a computer cannot easily tell which language is used in the name tag. We both agree that name tags in Thailand can have both Thai and English language in it. So for language priority name:en would ensure English only and name:th would ensure Thai only. Where as the name tag itself could be either language.
Take for example Big-C, which I can see tagged like this:
RocketMan, are you Thai?
Not arguing here, just trying to make sure I understand you correctly.
You are saying that you don’t see any reason for name and name:th to ever contain different values, e.g.:
Big C should either be:
Am I understanding that correctly?
name:th can be used outside Thailand: there is a small Thai minority in Northern Malaysia, and I added a name:th tag to a buddhist temple there: https://www.openstreetmap.org/node/3278470603 (the Thai name is actually the transliteration of the Malay name only, not even a translation (“pond 3”)).
But in Thailand, name:th is - in my opinion - not very useful. There might be exceptional cases where Thai people prefer the “English” name - with Latin characters - of some shops. Though more often I see “English” names of “ressorts”, but in Thai characters.
By the way, if only “name:en” is given (without “name”), most Openstreetmap renderers won’t show a name at all.
I missed the start of this thread. here my 2 cents:
For the name tag the convention is to use the “local” name. This applies word-wide and is quite agreed by the community.
In Thailand this is mostly the name in Thai script. For example names of rivers.
Brand names are slightly more complicated, because the brand owner decided to use a name with Latin characters as the main brand. Either because the brand is foreign (McDonald’s) or because it’s en-vogue. Sometimes these businesses also have the name written in Thai script. I don’t know why they do this at all. It might be for people unable to read Latin or it might be some sort of legal requirement. As a foreigner I don’t know the exact details.
In these cases name is the brand in Latin, name:th the Thai script version.
name:th can duplicate the name in the first example (river), name:en can duplicate the name in the second example (brand).
The name: tags are useful in situations where data consumers want to directly address a specific writing. It helps to distinguish a specific-language name from a “local” name,
This is more a problem for global consumers. While for larger areas with uniform languages like Thailand a preprocessing could automatically move the name tags based on a bounding polygon it is more difficult on other areas where the the “local” language changes more based on a unsharp boundary.
One of these consumers was the wikipedia implementation of global maps. They tried to automatically produce maps in all 100 something languages of the wikipedia. Implementing individual fallback-routes for non-existing languages for each language. Read more about it here:
Having only name:th in Thai script without a name doesn’t make much sense. Copying the names over to name sounds reasonable. Maybe review the names to repair broken ones as well.
Similar to elements where only an English name:en exists, even when there is a Thai name available. In these cases it’s IMHO reasonable to have the name (wrong) as lating and have it later moved to name:en when the Thai script variant is added. Makes the transition smoother for data consumers not handling the extra effort of multi-languages.