On 2015-08-30 4:17 PM, Jörg Knobloch wrote:
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.
That is only true if the majority of the websites on the Internet use
the lang attribute incorrectly, and also only for those users who use a
localized build in a language different than their language (for
example, a German speaker who doesn't ever enter text in English) but
uses an en-US Firefox.
Just wanting to reiterate that the problem is not as big as you claim it
is. We did not break Firefox for "single language users".
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.
To be clear, we only did that to keep this pref working as a fallback.
This pref should really not be used, because of some of the problems you
are talking about here.
This three-tier approach, with the user preference being set more or
less randomly
I have no idea why you think that we are doing anything randomly. For
the purpose of this discussion, the spellchecker.dictionary pref is only
set by our code, so the behavior that the user sees is as follows:
* If they go on a website which uses the lang attribute, we respect that.
* If they change their preferred dictionary on a website, they will get
that language for that website in the future, and for all other cases
where we are unsure of what language the website needs.
This is not ideal because of two reasons:
1. The user can't globally override the choice of the website author.
2. They don't have a good UI for adjusting the default spell checking
language.
Users who set the spelllchecker.dictionary pref manually are doing
something unsupported, and just like changing any other preference
without understanding the implications, they will probably be surprised.
I'm not really worried about what behavior we have for those people who
change this pref, or rely on it. We may remove the pref or change what
it does in the future.
> 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
This is a mish-mash of probably unrelated bugs that have any number of
causes and solutions. Not sure why this is relevant to anything
discussed here.
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.
No, I don't think we should do this for the following reasons:
* We have changed the meaning of this pref enough times. Doing this
once again will just make the people who like the current behavior complain.
* This proposal seems to focus on the behavior that the users who have
adjusted this pref manually will experience. I don't think we should
really go out of our way to support that.
I will explain more below.
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 will definitely change our behavior, but I don't know if it changes
it for the better.
This approach cuts through all the confusion:
"Single language users" set "spellchecker.dictionary" to their preferred
language and forget about the issue.
No, they won't. Users do not generally go and change random prefs. If
we want to improve anything here (and I think we should) we need to add
UI that most users can use.
"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).
Again since you are suggesting that people should change this pref to
get their desired behavior, they won't. Changing the meaning of the
preference will by and large only affect the people who have previously
set it.
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.
As I have said in the past, what Thunderbird wants to do has no bearing
on what behavior we want in Firefox. We already treat Thunderbird
differently here and we can change the behavior again in Thunderbird
specific ways in the future.
(I will also note that the more Thunderbird specific behaviors we
introduce here the worse off Thunderbird would be in the future since
these behaviors often don't have automated tests and they regress when
we change stuff in Gecko.)
So please voice your objections to the proposed solution, if any ;-)
Please consider this as my objection. :-)
Here is what I would like to see in the future for improving this situation:
* Don't change our behavior any more without complete plans on how to
improve the global picture. Past experience has shown that this is
extremely complicated and every time we change something here we break
some users' workflows; so I don't think this is an area where we can
make small improvements, and we probably need an overhaul. As such, I
don't think I'll accept any more patches to change the behavior here
without a complete plan.
* Get out of the guessing game as much as we can, and give users control
over the spell checking behavior. This roughly means:
** Accepting what the web page tells us about the language out of the box.
** Make it easy/possible for the user to override the default choice
either globally, or per site, or per the field that they are editing.
This needs to happen through a good UI, especially one that lets users
change their past decisions.
* Also think about other improvements that we can make on the fly. The
current way for obtaining new dictionaries sucks for example. And there
is essentially no way to manage a list of dictionaries for
multi-language users. And in some locales there is a default dictionary
shipping which adds inconsistency.
* Also think about how this will work on Firefox, Fennec and Firefox OS.
I don't really have any concrete suggestions unfortunately. If this is
an area that interests you I suggest to start working on the UX with the
help of our UX team. The implementation strategy needs to come after
agreeing on what UI/UX we want to support here.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
