Re: How would you like to spell check this?

[Ehsan Akhgari]

On 2015-09-03 6:44 AM, Florian Quèze wrote:

The solution I would like to see implemented (and I'm willing to help)
is automatic detection of the language.


Note that in addition to this, in order to make the feature completely 
useful for multilingual users, we would need to implement support for 
multilanguage spell checking as well (so that we can deal with more than 
one language in a text box correctly) which is another thing that we 
should improve some day.  What makes this difficult now is the fact that 
the spell checking code is written assuming that each editor object has 
only one spell checker which is limited to one dictionary loaded in the 
underlying hunspell component.  This is another thing that people have 
asked us for in the past.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Florian Quèze]

On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:

> So please voice your objections to the proposed solution, if any ;-)

As someone mentioned already, lots of websites are actually
communication tools (eg. webmail, chat, social networks), and there's
no way the website can know in advance in which language I'll want to
type (I write half the time in French and half the time in English).
My personal experience is that touching a context menu to switch the
dictionary all the time is too much effort, so I gave up and am now
used to completely ignoring the red underlines.

The solution I would like to see implemented (and I'm willing to help)
is automatic detection of the language. We already ship language
detection code 
(http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm)
and this could be reused for spell checking. Of course we can't guess
the language when the user starts typing (so we'll still need the
mechanisms you discussed), but as soon as we have a couple words, the
detection is pretty reliable.
This would of course need a way to pref it off for people who speak a
single language and would be annoyed if every once in a while the
dictionary is switched automatically; but I think it would make the
spell checker significantly more usable for multi-language users.

Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 3/09/2015 12:44, Florian Quèze wrote:
The solution I would like to see implemented (and I'm willing to help) 
is automatic detection of the language.


Nice idea.

I'd like to clean-up the current behaviour first in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 so we have a solid 
base to start from.


This would of course need a way to pref it off for people who speak a 
single language and would be annoyed if every once in a while the 
dictionary is switched automatically; but I think it would make the 
spell checker significantly more usable for multi-language users.


I think this is where Ehsan's argument comes in, to define the user 
interface first (for which I didn't find any support by the UX team).


Currently, "spellchecker.dictionary" is set when the user sets a 
language from the right-click (context) menu. This will only serve as a 
fallback for sites, where no language is defined by the page content.


There are people who want a global override of this (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1073840).


We could consider both issues at the same time later. I would like to 
fix what is broken now and causes much confusion amongst the users 
before embarking on new adventures.


Jorg K.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Panos Astithas]

On Thu, Sep 3, 2015 at 1:44 PM, Florian Quèze  wrote:

> On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:
>
> > So please voice your objections to the proposed solution, if any ;-)
>
> As someone mentioned already, lots of websites are actually
> communication tools (eg. webmail, chat, social networks), and there's
> no way the website can know in advance in which language I'll want to
> type (I write half the time in French and half the time in English).
> My personal experience is that touching a context menu to switch the
> dictionary all the time is too much effort, so I gave up and am now
> used to completely ignoring the red underlines.
>
> The solution I would like to see implemented (and I'm willing to help)
> is automatic detection of the language. We already ship language
> detection code (
> http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm
> )
> and this could be reused for spell checking. Of course we can't guess
> the language when the user starts typing (so we'll still need the
> mechanisms you discussed), but as soon as we have a couple words, the
> detection is pretty reliable.
> This would of course need a way to pref it off for people who speak a
> single language and would be annoyed if every once in a while the
> dictionary is switched automatically; but I think it would make the
> spell checker significantly more usable for multi-language users.


+1000
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 2/09/2015 07:17, lalo.mart...@gmail.com wrote:

To put it simply, if I select a language via the context menu, it should still 
be there next time I visit the same site; it's the intended behaviour for the 
current code, and even if I don't think it's ideal, it's currently broken, and 
I don't understand how there can be any resistance to fixing it.


This was reported in bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=717433.
I have submitted a simple patch which addresses this problem only 
without trying to do a general clean-up.
I've presented the patch for review and it has been accepted and will be 
part of Firefox 43.


Another problem is still bugging me:

I've installed a German localised version of Firefox and one dictionary, 
the German one. This represents the average non-English speaking user.
* On every new site I visit that supplies a "lang" setting, I have to 
explicitly select the German spell checking dictionary. No default is 
supplied.
* On every new site I visit that *does not* supply a "lang" setting, I 
automatically get the German dictionary selected (since there my last 
choice, which was saved in spellchecker.dictionary, gets applied).


It is a) highly annoying having to set the dictionary over and over and 
b) very inconsistent, since the user doesn't generally analyse the HTML 
content of the site to understand the behaviour.


I would call this another *bug* that can be fixed *without* having to 
come up with a new user interface, which no one in charge does currently 
have interest in or time for.


A patch for this second problem was presented in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1200533.


I would like to hear a good argument why this confusing behaviour should 
be maintained. I don't consider the following a good argument (quote):
"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."


I even have proof, that this is *not* a good argument, since one aspect 
of the general spell checking problem (bug 717433) already has an 
accepted solution.


Jorg K.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Robert O'Callahan]

On Wed, Sep 2, 2015 at 6:41 PM, Jörg Knobloch  wrote:

> I would like to hear a good argument why this confusing behaviour should
> be maintained. I don't consider the following a good argument (quote):
> "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."
>
> I even have proof, that this is *not* a good argument, since one aspect of
> the general spell checking problem (bug 717433) already has an accepted
> solution.
>

I don't intend to pick a fight with Ehsan over this. I believe what he
wrote there. The patch in bug 717433 just seemed like an especially clear
improvement.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 2/09/2015 12:24, Robert O'Callahan wrote:

The patch in bug 717433 just seemed like an especially clear
improvement.


Agreed. This was the nastiest problem that affected the most users and 
had the most obvious fix.


As detailed earlier in the thread, there is another puzzling issue that 
should be fixed. If Ehsan doesn't want to be burdened with potential 
issues, I'm happy to look after this area for one year after my change 
in bug 1200533 goes live. No UI change, no mayor behaviour change, just 
some fallback changes. That offer includes fixing regressions and 
handling complaints on BMO. Too good to refuse, isn't it?


Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 1/09/2015 16:01, Ehsan Akhgari wrote:
I suppose you can find them on #fx-team. 


Just for the record from IRC:

jorgk:

Hi, #fx-team. I had this discussion with Ehsan 
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Et02D8Mk2d0 
on improving the spell checking in Firefox. Currently the website 
dictates the dictionary, the user can select another one, which is 
remembered for this website only, and there is some weird fallback 
behaviour. Ehsan suggested to improve the UI first to allow for a global 
override (as does Chrome) and then fix the internals. Bug 1073840 is 
about that. There is also a meta-bug 1073827 which reflects the general 
user confusion. So should we make a start to clean this up?


dolske (Justin Dolske):

I think I'd defer to ehsan's comment about this being a complicated 
issue full of pitfalls.

Not a priority for us to work on right now.

In other words: We will maintain the current "status quo" for the 
foreseeable future.


Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

Hi all,

I hope we can at least agree on fixing the problems with the current 
behaviour.

I raised bug https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 for that.

The clear order of priorities that will be established will be:
1) content preference, not ignoring an "en-GB" setting on a plain "en" site.
2) language set by the website, or any other dictionary that partly 
matches that, so if the website is "en-GB", a user who only has "en-US" 
will get that.
3) the value of "spellchecker.dictionary" which reflects a previous 
language choice of the user on another site.

4) the user's locale
5) the content of the "LANG" environment variable (if set)
6) the first spell check dictionary installed.

Feedback?

Jorg K.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[lalo . martins]

Oh come on, this is getting ridiculous.

THIS IS A BUG, no matter how much some contributors want to pretend it isn't. 
It's a conceptually simple bug that's been sitting around for at least 3.5 
years (since reported).

To put it simply, if I select a language via the context menu, it should still 
be there next time I visit the same site; it's the intended behaviour for the 
current code, and even if I don't think it's ideal, it's currently broken, and 
I don't understand how there can be any resistance to fixing it.

I understand open source projects need some sort of structure, but a large 
project (not single-developer) where one person can say "I don't have time or 
interest to look into this or read the many different tickets, but in 
principle, I don't want this bug to be fixed" is dysfunctional. It's a bug. It 
needs to be fixed. There's nothing to discuss or approve there, except for 
reviewing the fix code itself.

On Tuesday, 1 September 2015 18:28:47 UTC+2, Jörg Knobloch  wrote:
> On 1/09/2015 16:01, Ehsan Akhgari wrote:
> > 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.
> 
> Actually: No. I was complaining about a bug. A single language user with 
> one dictionary installed visiting a site which prescribes another 
> dictionary is left with no spell checking. Not his locale, not the only 
> dictionary he has installed, not the last choice he made and was stored 
> in "spellchecker.dictionary". This user needs to set the language on 
> every single "foreign" site he visits. My example was just a US user 
> visiting a Korean or German or French or Spanish site. This is what I 
> call "leaving users stand out in the rain".

I'm a multi-lingual user. Since my preferred language (en-gb) matches my 
locale, it never gets saved. So if any site selects a different one via lang 
attribute, this propagates to all my windows. Selecting English-UK again 
through the context menu is *supposed* (as currently specced) to save a content 
preference, but it doesn't, so if I visit a site that selects a different one 
again, it again propagates to all windows.

Or, sometimes, I have no idea under which conditions (maybe a site specifies 
"en" in their lang?), it switches to en-ca or en-au.

Please explain to me how this is not a bug and not worth fixing. Please explain 
to me how a fix will break desired behaviour here -- if there's anyone who 
*expects* this to happen, I'm sorry, but they're insane.

Yes I'd prefer the behaviour to be different. But I can accept that changing it 
would be complex. However, the current state is broken, and it needs to be 
fixed. Anyone who disagrees, please try to replicate my setup and live with it 
for a couple of weeks.

1: set your locale to a variation of en-XX where XX is not US.
2: have other dictionaries installed (and don't tell me this is a corner case; 
on Linux, Firefox uses system dictionaries, and it's nontrivial to filter which 
ones you want installed on a system level; Ubuntu lets you choose a language, 
but not block specific regional variations).
3: frequently visit sites that have in their lang a different language, for 
which you do have an installed dictionary (maybe because you occasionally write 
in that language).

If in two weeks you still don't think this is worth fixing, we can talk again.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 1/09/2015 16:01, Ehsan Akhgari wrote:
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.


Actually: No. I was complaining about a bug. A single language user with 
one dictionary installed visiting a site which prescribes another 
dictionary is left with no spell checking. Not his locale, not the only 
dictionary he has installed, not the last choice he made and was stored 
in "spellchecker.dictionary". This user needs to set the language on 
every single "foreign" site he visits. My example was just a US user 
visiting a Korean or German or French or Spanish site. This is what I 
call "leaving users stand out in the rain".


Your Korean user with a en-US build should most probably install a 
Korean dictionary to avoid defaulting to en-US, if he/she switches on 
checking in the first place. So I don't think your example compensates 
for those getting wet.


No amount of changes to the fallback paths in the code mentioned above 
will make things work well for everyone.

Sure, but we should fix the most obvious errors.




"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!


This was actually a reply to what you had written before (quote):
"... the spellchecker.dictionary pref is only set by *our* code ..."
I don't know who you referred to by "we" and "our", but I am addressing 
the same people ;-)


Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Ehsan Akhgari]

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:

element ko (which is not installed)

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

Re: How would you like to spell check this?

[Anne van Kesteren]

On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:
> 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.

HTML4 is long obsolete.


> 4) Fall-back options including the locale and others.
>
> "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).

If you speak multiple languages you have to actively unset an
about:config setting?

FWIW, as someone who uses two languages, what I've always wanted is
that the spellchecker can use multiple dictionaries at once. Quite
often when a site accepts text input it's some kind of communication
tool. And the communication tool doesn't know what language you use to
communicate and the language you use to communicate will not always be
the same.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 31/08/2015 08:12, Anne van Kesteren wrote:
HTML4 is long obsolete. 

OK, the HTML5 definition is here:
http://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes
It comes to the same result.


4) Fall-back options including the locale and others.

"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).

If you speak multiple languages you have to actively unset an
about:config setting?

If is was set in the past. Default install won't have it set.
As I said, this should be offered as an option in the UI, since 
currently there is no direct access to "spellchecker.dictionary", 
although the value is used in weird and wonderful ways. This bug is 
about cleaning up behaviour that confuses the user and establishing a 
clear priority.


The UI could read:
Preferred spell check language:
- Use language defined by website
- Override with (dictionary of your choice)
Note: In both cases a site specific language can be chosen.


FWIW, as someone who uses two languages, what I've always wanted is
that the spellchecker can use multiple dictionaries at once. Quite
often when a site accepts text input it's some kind of communication
tool. And the communication tool doesn't know what language you use to
communicate and the language you use to communicate will not always be
the same.
Multiple dictionaries in the same text field? That's unlikely to be 
implemented any time soon.
Multiple dictionaries in different text fields already works, as long as 
no overrides are set. Try:






contenteditable="">

root en-AU


lang="en-GB" contenteditable="">

root en-AU, but element en-GB



The point of this discussion is whether there is objection to the new 
priority suggested:

1) Content preference
2) "spellchecker.dictionary", if set
3) language determined by site
4) Fall-back options including the locale and others.

Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

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:
lang="ko" contenteditable="">

element ko (which is not installed)

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.


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. 
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.


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.


"Your" code is broken here:
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#616
("en-GB" on an "en" site like BMO gets tossed away)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#764
(faulty error handling)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=11100#768
(this is wrong, that should be retrieved straight after getting the 
language of the element/parent, if this isn't set)

https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=16900#834
(this is wrong, since rv controlls the flow of the fallback, but is used 
as the return status for a helper function)

https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=18400#853
(IMHO the status should be checked here)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=21400#859
(this is wrong, see Korean example above)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=20800#871
(this is wrong, must not check rv again)
https://dxr.mozilla.org/mozilla-central/source/editor/composer/nsEditorSpellCheck.cpp?offset=21200#880
(this makes no sense, since en-US is not a useful fallback for most 
locales).


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 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. 

From the Thunderbird side I know Blake and Jim.


Jorg K.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

How would you like to spell check this?

[Jörg Knobloch]

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.