Hi all,
Today I would like to discuss a change I'd like to make to the way the
spell checking language is selected for text input (editor) fields.
Before I get to my proposal, we need to take a little stroll down memory
lane.
In the good old days, when setting the spell check language in a text
field, the user preference "spellchecker.dictionary" was set to the
selected language and this language was used until the user changed it
again.
Before https://bugzilla.mozilla.org/show_bug.cgi?id=338427 the language
of a certain element (or its closest parent) was not respected for text
input fields, so users had to change the language manually if they
wanted to enter text in different languages on different sites. With the
change, the language of the site/document overrode the setting in
"spellchecker.dictionary". Details here:
http://hg.mozilla.org/mozilla-central/diff/f3f7872db0ae/editor/composer/src/nsEditorSpellCheck.cpp
Obviously the "single language users" who always wanted to write in
their mother tongue were left standing in the rain, since they now had
to change dictionary many times.
Consequently, after landing of this bug in Firefox 8, people started to
complain. If users didn't want to use the language proposed by the site
(or the site provided the wrong information), they had to set the
dictionary manually. So in
https://bugzilla.mozilla.org/show_bug.cgi?id=678842 the language choice
for a particular site was stored in the so-called "content preferences"
(which is a SQLite database in the user profile). This was landed in
Firefox 9. Users could now store the language they wanted to use on a
particular site individually.
However, the "single language users" who always wanted to write in their
mother tongue were still standing out in the rain. They did actually not
want to change the language on all the different sites they visited.
Additionally, both implementations caused even more confusion. After bug
338427, the user preference in "spellchecker.dictionary" was still used
as a fall-back, if the site didn't provide language information. After
bug 678842, the user preference also still served as a fall-back in
cases where no content preference was specified and where the site
didn't provide any language information. However, the user preference
was set at the moment where the user changed the spell check dictionary
and a content preference was created. Details here:
http://hg.mozilla.org/mozilla-central/diff/a624f57a9e6f/editor/composer/src/nsEditorSpellCheck.cpp
This three-tier approach, with the user preference being set more or
less randomly but later not obeyed because it was overruled by content
preference or site language, has lead to a host of problems:
https://bugzilla.mozilla.org/show_bug.cgi?id=1073827 - Meta bug to track
all the problems
Bug 455235 - spellchecker doesn't choose the correct locale dictionary
in Firefox
Bug 717433 - Chosen dictionary intermittently resets from en-GB to en-US
after session restart
Bug 728069 - Firefox should remember manual setting of spell checker
language
Bug 836230 - Preference spellchecker.dictionary doesn't retain user set
value
Bug 853970 - Spell checker in browser forgets language setting
Bug 858666 - spelling checker language setting changes spontaneously
Bug 909040 - Spell checking language gets reset
Bug 923356 - Wrong language used on start up to spell check
Bug 926166 - changing the dictionary (language) is sometimes ignored
Bug 932925 - Spellcheck keeps changing to other languages
Bug 959785 - Chosen language is forgotten after re-focusing textbox
Bug 1073840 - Pref: Always honour setting of spellchecker
language/dictionary in user prefs,
regardless of lang attribute or Content-Language header
Bug 1139550 - Firefox keeps resetting spellcheck language to Cuban Spanish
Mark Straver and I have been looking into bug 1073840. Our proposal is
the following:
Reinstate "spellchecker.dictionary" as a global override, if it has a
value set. So we establish the following list of priorities:
1) Content preference
2) "spellchecker.dictionary", if set
3) language determined by site according to
http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1.2.
4) Fall-back options including the locale and others.
We also suggest not to ever set "spellchecker.dictionary"
programatically. If the user changes the dictionary via the context
(right click) menu, this will be stored as a content preference.
"spellchecker.dictionary" can be set via "about:config" or an option
which would have to be provided somewhere in the user interface.
This approach cuts through all the confusion:
"Single language users" set "spellchecker.dictionary" to their preferred
language and forget about the issue.
"Single language users" who went to a language course and want to try
writing in a different language also set the user preference and only
change the dictionary on a particular site, which is stored a content
preference.
"Polyglot users" unset "spellchecker.dictionary" and enter the text in
the language the site requires. However, they lose
"spellchecker.dictionary" as a fall-back, so their fall-back would be
their locale (see point 4).
I have also considered another option, where the priority is reversed:
1) Content preference
2) language determined by site
3) "spellchecker.dictionary", if set
Mark and I believe that this is not what most users want, who are
"single language users". They want the "global override" back. (The only
advantage of this other option would be that "spellchecker.dictionary"
could serve as a fall-back for the minority "polyglot users". However, I
think their locale is good enough as a fall-back.)
Looking further afield:
Thunderbird from version 38 has changed the way it uses
"spellchecker.dictionary" (bug 967494). There the user preference
remains unchanged and determines the language for every new e-mail. If
the users wants to write in a different language, they can change the
dictionary, but that doesn't change the default. The Thunderbird team is
working on a smarter solution to set the language from the recipient or
other context information.
Chrome offers the users the Firefox pre-version-8 state: They can set
the dictionary, and the choice sticks for all sites until they change it
to something else.
So please voice your objections to the proposed solution, if any ;-)
Kind regards and thank you for your attention,
Jorg K.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
