Closed Bug 1255242 Opened 7 years ago Closed 2 years ago

Take secondary locales into account for glyph selection, especially in the context of Han Unification disambiguation

Categories

(Core :: Graphics: Text, defect, P3)

All
Android
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: yukawa, Unassigned)

References

Details

(Keywords: intl, Whiteboard: gfx-noted)

Attachments

(2 files)

Steps to reproduce the issue:
1. Download and flash Android N developer preview NPC56P into Nexus 6P (this is not device specific though) with system locale en-US.
   http://developer.android.com/preview/download.html
2. Enable Google Japanese Input in the system settings (or install whatever Japanese IME you want to use).
3. Install Firefox for Android nightly 48.0a1 (2016-03-09) into Android N developer preview NPC56P.
4. Launch Firefox nightly, go to "data:text/html,<textarea>"
5. Type "忍者" on the textarea.
6. In the system settings, add Japanese as the secondary language.

Expected behavior:
"忍" is rendered with a Japanese glyph after step 6.

Actual behavior:
"忍" is rendered with a Chinese glyph after step 6.

Chromium bug:
http://crbug.com/593511

Additional information:
In Android N, we are working hard to enable users to specify more than one system languages, which will be exposed to applications as an ordered list of Locales.
http://developer.android.com/preview/features/multilingual-support.html

I'm not familiar with how (system) locale change event has been handled in Gecko, but seems that you can call newConfig.getLocales() instead of newConfig.locale in the following place to get the full list of system languages that the user specified.
http://hg.mozilla.org/mozilla-central/file/93156962855d/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#l2206

It would be great if secondary locales are taken into account for glyph selection in Firefox.

Thanks!
Attached video Expected behavior
This is how built in EditText works.
Attached video Actual behavior
This is how Firefox for Android nightly 48.0a1 (2016-03-09) behaves.
I don't know who are working in gfx for Android, though...

In the old thebes, we checked system locale in same situation on Windows. However, I don't find the code in current thebes. So, I'm not sure which push log tells us who is active contributor for here.
Component: Internationalization → Graphics: Text
Keywords: intl
We changes fonts by language of HTML instead of input source.  So If lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.
(In reply to Makoto Kato [:m_kato] from comment #4)
> We changes fonts by language of HTML instead of input source.  So If
> lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.

How about the language information isn't available or non-CJK but the contents have Kanji characters?

E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo lang="en-US">漢字</foo>.
Just FYI, I've uploaded screenrecords here too in case you can watch these movies more easily there.
https://drive.google.com/open?id=0ByZK1hhvVhpVTEt1ZVA0VEw3TFU

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?
> 
> E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo
> lang="en-US">漢字</foo>.

Yeah, that's the problem, and my understanding is that we would eventually need multi-level fallback rules, e.g. en-US > ja-JP > zh-TW, for each context.

As for web browsers, I think it makes sense to put the highest priority on lang attribute, but when it is not sufficient to disambiguate something, it would be great if the browser can treat the system locales as fallback languages.

https://drive.google.com/open?id=0ByZK1hhvVhpVWlJNbFF5emZscE0 is an example where the order of secondary languages matters.
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> (In reply to Makoto Kato [:m_kato] from comment #4)
> > We changes fonts by language of HTML instead of input source.  So If
> > lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.
> 
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?

Application locale.  But Android implementation of nsILocale is pretty broken because it doesn't use Java code.  So if locale is changed, Gecko for Android doesn't know it
gfxPlatformFontList generates font list per locale data.

This is already resolved by bug 1434805. Closing. I have verified on Fenix 80.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.