1439162 - Firefox uses locale languages/dictionaries for spell-checking, but ignores locale configuration

Status: RESOLVED INCOMPLETE

(Core :: Internationalization: Localization, defect)

Description

[Porcelain Mouse]

Attachment: Screenshot from 2018-02-16 22-53-46.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180130211649

Steps to reproduce:

Nothing.  I just started Firefox.


Actual results:

When I visit a site with free text fields, like this one, spell-checking does not work correctly because the wrong language is selected, i.e. the default language is *not* the language I have configured as my default/preferred language.

FF always selects the locale language "US-English (Malawi)" from the locally install locales (NOT Firefox "dictionaries", see below) even though LANG="en_US.utf8".


Expected results:

One of the main problems is that I don't know the answer to this question because, no matter how many times I bring this up in similar bugs, no one will tell me what FF is *supposed* to be doing.  But, here is what should have happened for a typical application:  FF should use my configured locale preference to select the default spell-checking language.  FF is internationalized and already understands how to access all my installed locales as is evidenced by the fact that the list of available spell check languages is identical to my installed locales.  Yet, FF ignores my locale configuration when selecting the default spell check language.

NOTE: This is *not* the same thing as FF dictionaries.  On Linux, I don't even have the "Dictionaries" option in Add-Ons.

1) If FF is going to use locales for spell checking, it needs to respect my locale configuration.  This seems obvious to me, but maybe I'm wrong.

2) Otherwise, FF should not use installed locales for spell checking and should allow/require Linux users to install dictionaries through Add-Ons as on other platforms.

Comment 1

[Abe - QA (:Abe_LV)]

We tested this on Ubuntu 16.04 with the latest nightly (en-US locale). We changed the language in about:preferences, but the spelling checker checks by en-US, not by the language we added.

Comment 2

[Sam Foster [:sfoster] (he/him)]

:flod, can you chime in on what *should* be happening here, what is the current state of play? (and if this is a known dupe)

Comment 3

[Francesco Lodolo [:flod]]

I'm not sure I can provide a full answer to this, but there are several things to clarify:
* Installing a language pack doesn't provide a dictionary, it needs to be installed separately from https://addons.mozilla.org/firefox/language-tools/ That might explain why Linux doesn't have a dictionary (it's usually an English build with language packs).
* Only some languages ship a dictionary in the full build, that's due to license constraints (a lot of them are under GPL, and can't ship in Firefox code).

In Preferences you currently set only the Accept-Language preference, i.e. which languages (and in which order) you want to see web content in. That's unrelated to dictionaries, and also unrelated to the UI language.

There is a lot of planning work happening this year about making Firefox properly multilingual, that should include work on dictionaries, and language detection.

Firefox is supposed to respect the lang attribute of the element you're in (bug 338427), not the language you've requested for the web page, or the language used for the browser UI. 

For example: I'm using an Italian build, ask for Italian content, but I'm writing in English here on a page that explicitly tells me content is in lang="en".

Comment 4

[Porcelain Mouse]

I realize you probably know this, but just in case it is helpful and relevant, there is a bit of bug history involving the lang= HTML attribute.  I was actually involved it one such bug, so I remember it.  There was a problem, at one point, where sites were setting lang=en-US, but there is no such POSIX locale.  The locale is "en_US" and FF had to take account of this difference in representation.  I did quite a bit of testing and thought this bug was fixed.  I wonder if there is a regression in this code or related code.  Also, could it be that there isn't a link between "en" and other English locales?  I mean, I doin't have "en" installed, I have "en_US" and others.  So, there still may need to be a selection algorithm for this.