3 ms·

I copy/pasted the example into iTerm Build 3.4.8 and got Simplified Chinese. When copy pasted it here in this comment box (Mozilla/5.0 (Macintosh; Intel Mac OS

I copy/pasted the example into iTerm Build 3.4.8 and got Simplified Chinese. When copy pasted it here in this comment box (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0), I also got Simplified Chinese. What do you see? 刃直海角骨入 By the way, I do NOT have an Intel Mac, I have an Apple M1.

deleted 3y ago
[deleted]
LoganDark 3y ago
Same codepoints. Software can only choose the right font if it knows it's in the Japanese language. I'm sure if you set your browser's language to Japanese it would select the right font, but since it's probably set to English instead, it's selecting a "default" assumption for the language of those glyphs. App localization (where you specifically select "Japanese" as the language you want an app to display in) is the main target of this article, I think.
- adastra22 3y ago
  Linguistic identification can in principle be a bit smarter than that. Aside from the obvious "if it has kana it is Japanese" metric, there are also differences in code point choice which differentiate Simplified, Traditional, and Japanese. Fully accurate identification is certainly expensive, but quick early-out heuristics could be developed.
  - rsaxvc 3y ago
    This reminds me of guessing codepoint likelihood based on character distribution.
  - eviks 3y ago
    indeed it could be better, though do you know of any apps that actually try to be smarter?
    - adastra22 3y ago
      In principle this is a job for Unicode font rendering libraries and/or standard OS text widgets, not app developers.
adastra22 3y ago
I'm on a Apple Silicon Mac and I see Japanese, for what it's worth.
barryvan 3y ago
I think the point of the page was that unless the site/app/program is explicit about the language being displayed, you'll get Simplified Chinese. As HN is an English-language site, it uses the default. Similarly, your terminal doesn't prioritise Japanese over Simplified or Traditional Chinese. By way of contrast, if you paste that into the search bar on https://yahoo.jp/ https://yahoo.jp/ , you'll get the appropriate Japanese characters, as that site is explicitly Japanese.
- cratermoon 3y ago
  Instead of explaining to me what I already know from reading the site and testing things out for myself, perhaps you could post some examples and experiences you've found.
paradite 3y ago
Interestingly I see the Japanese glyph on Apple M1. My locale is English-US and I am a native Chinese speaker. When I paste it into VS Code it also renders Japanese, but when I click on the unicode code, it goes to https://symbl.cc/en/5203/ https://symbl.cc/en/5203/ and https://symbl.cc/en/76F4/ https://symbl.cc/en/76F4/ which renders Chinese. I am typing out the Chinese equivalent for reference: 刃直 but looks like they also turned into Japanese glyph for display past Chinese input method, in fact I can't type out the Chinese glyph in any apps on macOS. It is not a big deal to me because I have no issue reading kanji as Chinese characters.

deleted 3y ago

[deleted]

LoganDark 3y ago

Same codepoints. Software can only choose the right font if it knows it's in the Japanese language. I'm sure if you set your browser's language to Japanese it would select the right font, but since it's probably set to English instead, it's selecting a "default" assumption for the language of those glyphs. App localization (where you specifically select "Japanese" as the language you want an app to display in) is the main target of this article, I think.

adastra22 3y ago
Linguistic identification can in principle be a bit smarter than that. Aside from the obvious "if it has kana it is Japanese" metric, there are also differences in code point choice which differentiate Simplified, Traditional, and Japanese. Fully accurate identification is certainly expensive, but quick early-out heuristics could be developed.
- rsaxvc 3y ago
  This reminds me of guessing codepoint likelihood based on character distribution.
- eviks 3y ago
  indeed it could be better, though do you know of any apps that actually try to be smarter?
  - adastra22 3y ago
    In principle this is a job for Unicode font rendering libraries and/or standard OS text widgets, not app developers.

adastra22 3y ago

I'm on a Apple Silicon Mac and I see Japanese, for what it's worth.

barryvan 3y ago

I think the point of the page was that unless the site/app/program is explicit about the language being displayed, you'll get Simplified Chinese. As HN is an English-language site, it uses the default. Similarly, your terminal doesn't prioritise Japanese over Simplified or Traditional Chinese. By way of contrast, if you paste that into the search bar on https://yahoo.jp/ https://yahoo.jp/ , you'll get the appropriate Japanese characters, as that site is explicitly Japanese.

cratermoon 3y ago
Instead of explaining to me what I already know from reading the site and testing things out for myself, perhaps you could post some examples and experiences you've found.

paradite 3y ago

Interestingly I see the Japanese glyph on Apple M1. My locale is English-US and I am a native Chinese speaker. When I paste it into VS Code it also renders Japanese, but when I click on the unicode code, it goes to https://symbl.cc/en/5203/ https://symbl.cc/en/5203/ and https://symbl.cc/en/76F4/ https://symbl.cc/en/76F4/ which renders Chinese. I am typing out the Chinese equivalent for reference: 刃直 but looks like they also turned into Japanese glyph for display past Chinese input method, in fact I can't type out the Chinese glyph in any apps on macOS. It is not a big deal to me because I have no issue reading kanji as Chinese characters.