Re: How would you like to spell check this?
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?
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?
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 forg
Re: How would you like to spell check this?
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
Re: How would you like to spell check this?
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?
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?
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?
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?
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?
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?
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?
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?
On 2015-09-02 6:50 AM, Jörg Knobloch wrote: 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? That's great! Thanks for offer. This is an area that I think we should spend more time on, so I'm happy that you are offering to help. I spoke with Olli (smaug on IRC) who is another person familiar with this code and he said that he might have some free time to help you with this effort. Please feel free to talk to him about what you are planning to do and take it from there. I hope to have more time to help here in the future too, but in the mean time having someone else available to you should help unblock you. 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?
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?
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?
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?
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