On 2015-08-31 5:57 PM, Jörg Knobloch wrote:
On 31/08/2015 17:18, Ehsan Akhgari wrote:
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".
If you take a good look at the fallback processing in
editor/composer/nsEditorSpellCheck.cpp, you will notice that it is
highly broken. Single language users who visit a site where the language
doesn't match any on the dictionaries (or the only dictionary) they
have, end up with no dictionary set. Try:
<div style="background-color:#eee;border:1px solid #000;padding:10px"
lang="ko" contenteditable="">
<div>element ko (which is not installed)</div>
</div>
or visit https://www.kyobo.co.kr on your Firefox now, assuming that you
don't have Korean installed.
This code is in desperate need of a clean-up. Some fallbacks only work
if the site doesn't supply a language, see below for a list of all the
problems I encountered.
The fundamental issue is that different people have different needs, and
there is also the information that the website gives us which we need to
take into account somehow. You are describing what _you_ would like to
see. But a Korean speaking user who is using an en-US build would
probably like a different behavior (they may not expect the en-US
dictionary to be used there since neither they speak English nor the
website they are visiting is English.)
No amount of changes to the fallback paths in the code mentioned above
will make things work well for everyone. That is why in my previous
email I said that we should get out of the guessing game and let the
user actually tell us what they want to happen.
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.
While some of the bugs may be unrelated, you get the general idea of
users not understanding why a specific spell check language is used.
Sure.
Part of the discussion here is to establish clear rules that everybody
can understand. The rule: "If you visit site 1 and change the spelling
language (which is currently stored in the preference) and then visit
site 2 you may or may not get the language you just set" is something no
one understands.
I agree.
But what is? What you are describing is definitely not something that
users will understand either.
If nothing else, I'd clean-up the fallback behaviour, since it's broken
and unclear. I'd also clean up the content preference behaviour since I
cannot store "en-GB" on an "en" website, resulting the explicit user
choice to be forgotten all the time.
Believe me when I say that *every single time* we have tried to "fix"
something here, someone has told us that they actually want a different
behavior. As such, I think that any change here must be performed as a
larger project to fix our spell checking UI. Even fixing bugs in this
code has proved to cause more issues.
"Your" code is broken here:
I'm not going through a line by line analysis of this code on the
mailing list since this is besides the point, and I am trying to not
take the "your" above personally!
I've looked at this code for a few days now and tested a few things, and
it simply doesn't work in any meaningful way.
I have looked at this code for years. May I suggest that looking at
things for a few days may not give you the full picture of where the
problems are? :-)
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.
I think the first step should be to clean up the current mess, even if
we mostly maintain the current behaviour of storing
"spellchecker.dictionary" as a possible fallback.
Then yes, I'd be interested to get to know the UX people you talk about.
I suppose you can find them on #fx-team.
From the Thunderbird side I know Blake and Jim.
Again, note that spell checking in a web browser is very different than
in an email client. Everything I said here was about Firefox, not
Thunderbird.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
