Change Details

tl;dr: We should pick the fonts based on language for Chinese, Japanese, and Korean. The full reasoning is fairly technical and dense, so bear with me... When I speak of Chinese, Japanese, and Korean, I'm referring to the languages or speakers of the languages, not the countries. Because unicode has unified Han ideograms, using a single codepoint for different glyphs, this causes problems for maps. Native speakers expect to see language-specific glyphs and feel that other glyph forms are a foreign language, but this is not possible looking solely at Unicode text, because the same string could be in different languages. [Chapter 5.10 of Unicode 9.0](http://www.unicode.org/versions/Unicode9.0.0/UnicodeStandard-9.0.pdf) describe scenarios where the reader is either Japanese or Chinese and has the corresponding fonts. This works for web pages because they have knowledge of the language and mechanisms to describe it (e.g. HTML language tags). When rendering server-side, we supply the fonts, and when rendering `name` tags we don't have knowledge of the language. The OpenStreetMap Carto team, including myself, have [done some research into this](https://github.com/gravitystorm/openstreetmap-carto/issues/2208) and we're currently following [the recommended approach of rendering in Japanese](https://github.com/gravitystorm/openstreetmap-carto/blob/3dc97143ba665cea6a0451f0612da2fb92268ee2/fonts.mss#L18-L26). Their approach is not ideal, getting the wrong glyphs in some regions, but is considered to be the best possible for a single map rendering of `name` tags not targeted at any specific region or language. With internationalized maps, we can do better at picking the right glyphs. We still don't have a specific region we're targeting, but we now have a language, and in many cases, we know the language of the name. The target language comes from the query parameter, and the language of the name comes from knowing which `name:*` tag is being used. I don't propose doing anything with the latter knowledge, but the former lets us pick if we want Chinese, Japanese, or Korean characters based on the surrounding content of the page. When doing this, we would have a Chinese language wiki displaying a map of China or Japan with Chinese glyphs, and a Japanese language wiki displaying a map of Japan or China with Japanese glyphs. A better solution, but not a practical one is to incorporate knowledge of the source of the name into the font selection. So for a ja viewer seeing a name from a `name:ko` tag, it would be rendered preferring the Korean font/glyph. If the name came from a `name` tag, it would prefer the Japanese font/glyph, because that's their language.

**tl;dr: We should pick the fonts based on language for Chinese, Japanese, and Korean.** The full reasoning is fairly technical and dense, so bear with me... When I speak of Chinese, Japanese, and Korean, I'm referring to the languages or speakers of the languages, not the countries. Because unicode has unified Han ideograms, using a single codepoint for different glyphs, this causes problems for maps. Native speakers expect to see language-specific glyphs and feel that other glyph forms are a foreign language, but this is not possible looking solely at Unicode text, because the same string could be in different languages. [Chapter 5.10 of Unicode 9.0](http://www.unicode.org/versions/Unicode9.0.0/UnicodeStandard-9.0.pdf) describe scenarios where the reader is either Japanese or Chinese and has the corresponding fonts. This works for web pages because they have knowledge of the language and mechanisms to describe it (e.g. HTML language tags). When rendering server-side, we supply the fonts, and when rendering `name` tags we don't have knowledge of the language. The OpenStreetMap Carto team, including myself, have [done some research into this](https://github.com/gravitystorm/openstreetmap-carto/issues/2208) and we're currently following [the recommended approach of rendering in Japanese](https://github.com/gravitystorm/openstreetmap-carto/blob/3dc97143ba665cea6a0451f0612da2fb92268ee2/fonts.mss#L18-L26). Their approach is not ideal, getting the wrong glyphs in some regions, but is considered to be the best possible for a single map rendering of `name` tags not targeted at any specific region or language. With internationalized maps, we can do better at picking the right glyphs. We still don't have a specific region we're targeting, but we now have a language, and in many cases, we know the language of the name. The target language comes from the query parameter, and the language of the name comes from knowing which `name:*` tag is being used. I don't propose doing anything with the latter knowledge, but the former lets us pick if we want Chinese, Japanese, or Korean characters based on the surrounding content of the page. When doing this, we would have a Chinese language wiki displaying a map of China or Japan with Chinese glyphs, and a Japanese language wiki displaying a map of Japan or China with Japanese glyphs. A better solution, but not a practical one is to incorporate knowledge of the source of the name into the font selection. So for a ja viewer seeing a name from a `name:ko` tag, it would be rendered preferring the Korean font/glyph. If the name came from a `name` tag, it would prefer the Japanese font/glyph, because that's their language.

**tl;dr: We should pick the fonts based on language for Chinese, Japanese, and Korean.** The full reasoning is fairly technical and dense, so bear with me... When I speak of Chinese, Japanese, and Korean, I'm referring to the languages or speakers of the languages, not the countries. Because unicode has unified Han ideograms, using a single codepoint for different glyphs, this causes problems for maps. Native speakers expect to see language-specific glyphs and feel that other glyph forms are a foreign language, but this is not possible looking solely at Unicode text, because the same string could be in different languages. [Chapter 5.10 of Unicode 9.0](http://www.unicode.org/versions/Unicode9.0.0/UnicodeStandard-9.0.pdf) describe scenarios where the reader is either Japanese or Chinese and has the corresponding fonts. This works for web pages because they have knowledge of the language and mechanisms to describe it (e.g. HTML language tags). When rendering server-side, we supply the fonts, and when rendering `name` tags we don't have knowledge of the language. The OpenStreetMap Carto team, including myself, have [done some research into this](https://github.com/gravitystorm/openstreetmap-carto/issues/2208) and we're currently following [the recommended approach of rendering in Japanese](https://github.com/gravitystorm/openstreetmap-carto/blob/3dc97143ba665cea6a0451f0612da2fb92268ee2/fonts.mss#L18-L26). Their approach is not ideal, getting the wrong glyphs in some regions, but is considered to be the best possible for a single map rendering of `name` tags not targeted at any specific region or language. With internationalized maps, we can do better at picking the right glyphs. We still don't have a specific region we're targeting, but we now have a language, and in many cases, we know the language of the name. The target language comes from the query parameter, and the language of the name comes from knowing which `name:*` tag is being used. I don't propose doing anything with the latter knowledge, but the former lets us pick if we want Chinese, Japanese, or Korean characters based on the surrounding content of the page. When doing this, we would have a Chinese language wiki displaying a map of China or Japan with Chinese glyphs, and a Japanese language wiki displaying a map of Japan or China with Japanese glyphs. A better solution, but not a practical one is to incorporate knowledge of the source of the name into the font selection. So for a ja viewer seeing a name from a `name:ko` tag, it would be rendered preferring the Korean font/glyph. If the name came from a `name` tag, it would prefer the Japanese font/glyph, because that's their language.