Closed
Bug 1255242
Opened 9 years ago
Closed 4 years ago
Take secondary locales into account for glyph selection, especially in the context of Han Unification disambiguation
Categories
(Core :: Graphics: Text, defect, P3)
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!
Reporter | ||
Comment 1•9 years ago
|
||
This is how built in EditText works.
Reporter | ||
Comment 2•9 years ago
|
||
This is how Firefox for Android nightly 48.0a1 (2016-03-09) behaves.
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
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.
Comment 5•9 years ago
|
||
(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>.
Reporter | ||
Comment 6•9 years ago
|
||
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.
Comment 7•9 years ago
|
||
(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
Comment 8•9 years ago
|
||
gfxPlatformFontList generates font list per locale data.
Whiteboard: gfx-noted
Updated•8 years ago
|
Priority: -- → P3
Comment 9•4 years ago
|
||
This is already resolved by bug 1434805. Closing. I have verified on Fenix 80.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•