Chinese, Japanese, Korean language transliteration problem.

[c933103]

Currently, when users set their map language to Chinese/Japanese/Korean/etc. and enabled the transliteration option, the transliteration option would phonetically translate other Chinese/Japanese/Korean languages into latin characters. However, in the East Area region where these languages are commonly used, phonetically transliteration are rarely used and thus latin transliteration is not really useful.

• If the language used by user is Chinese, and to display Korean name, then it would be more useful to display name:ko-Hani=*, name:ko-Kore=*, or name:ko_hanja=* which are the stored Korean-transliteration-to-Chinese-character value (value in name:ko-Kore=* is to be expected to be a mixture of Hangul and Hanja, and Hangul part of the value could be transliterated into latin letters), or show name:ja=* when the value contain no hiragana/katakana which are also likely to be direct Chinese character transliteration, or if these approaches failed, it can also consider transliterating Korean names into Chinese characters using automatic transliterator, and only those that cannot be transliterated in such fashion should be translitrated into latin characters.
• If the language used by user is Chinese, and to display Japanese name, then it would be more useful to directly display Kanji in Japanese names directly, and then transliterate only kana part of those names into latin characters.
• If the language used by user is Chinese, and to display Vietnamese name, then the transliteration into Chu Han would be "nice to have if possible".
• If the language used by user is Japanese, and to display Chinese name, then it should transliterate Chinese letters into Japanese Shinjitai Kanji glyphs if possible, and for other Chinese characters without Shinjitai equivalent, latin or katakana transliteration equivalent could be supplied in bracket after each original Chinese character instead of replacing it.
• If the language used by user is Japanese, and to display Korean name, then it would be more useful to display name:ko-Hani=*, name:ko-Kore=*, or name:ko_hanja=* which are the stored Korean-transliteration-to-Chinese-character value (value in name:ko-Kore=* is to be expected to be a mixture of Hangul and Hanja, and Hangul part of the value could be transliterated into latin letters or katakana), or show name:zh=* or name:zh-XXXX=* and then translitrate the value into Shinjitai value using the aforementioned Chinese-to-Japanese-display method, or if these approaches failed, it can also attempt transliterating Korean names into Chinese characters using automatic transliterator, and only those that cannot be transliterated in such fashion should be translitrated into latin characters or katakana.
• If the language used by user is Korean, and to display Chinese name, then it should transliterate the Chinese name into Korean Hangul using the Korean reading of those Chinese characters.
• If the language used by user is Korean, and to display Japanese name, then phonetic translation is acceptable.

[gurahamu]

I have this issue also as a user in Japan. The visible alphabetic words are sometimes not the correct Japanese transliteration, especially for roads, also meaning the TTS reads out what sounds like a Chinese translation.

I raised this in the OSM forums and also in the Kurviger forums since I design routes in Kurviger and export gpx to OSMAnd+ on Android.

The notes on the OSM post were:

the app developers need to detect the language e.g. by setting it using country boundaries. What would be needed is to trace which part of the software stack is doing the transliteration and fix it there. It can be done. I think Organic Maps does this correctly.

A name:ja-Latn=* tag could be added to ensure correct romanisation. See https://wiki.openstreetmap.org/wiki/Multilingual_names#Japan

I hope this is useful.