Tails

#1 Updated by intrigeri 2016-02-02 13:24:57

• Affected tool set to Email Client

frontdesk: please assign to kytv if you can reproduce.

#2 Updated by Anonymous 2016-02-05 17:32:58

• Subject changed from icedove's default spell checking language is french to Icedove's default spell checking language is french
• Status changed from New to Confirmed
• Assignee set to kytv
• Priority changed from Low to Normal
• Target version set to Tails_2.2
• Deliverable for set to 268

I have tested and confirm the bug. I’ve selected german as default language and keyboard layout but the spell checker is in french by default.

#5 Updated by Anonymous 2016-02-24 11:22:57

• Target version changed from Tails_2.2 to Tails_2.3

#6 Updated by anonym 2016-03-10 12:58:04

• Assignee changed from kytv to anonym

#7 Updated by anonym 2016-04-20 10:57:13

• Target version changed from Tails_2.3 to Tails_2.4

#8 Updated by intrigeri 2016-05-10 05:06:12

• Subject changed from Icedove's default spell checking language is french to Icedove's default spell checking language is French
• Parent task set to Feature #5663
• Deliverable for changed from 268 to SponsorS_Internal

Feel free to postpone this one.

#9 Updated by anonym 2016-05-24 20:50:29

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10

I had a quick look without any progress except that I have ruled out any relationship with:

• the intl.locale.matchOS pref; either value has no effect
• the langpacks; I removed all of them without effect
• our icedove wrapper or the ~/.icedove; using neither has no effect
• /etc/icedove/...; removing it has no effect

So it seems a bit tougher than expected.

A workaround could be to make our wrapper set the correct pref, e.g. to en for all locales. If we want it localized we can perhaps refactor some code from guess_best_tor_browser_locale.

#12 Updated by anonym 2016-06-08 01:34:51

• Target version changed from Tails_2.4 to Tails_2.5

#13 Updated by anonym 2016-07-18 07:18:35

• Target version changed from Tails_2.5 to Tails_2.7

#14 Updated by anonym 2016-10-04 13:20:45

• Parent task deleted (Feature #5663)

#15 Updated by anonym 2016-10-05 10:04:23

• Assignee changed from anonym to bertagaz
• % Done changed from 10 to 50
• QA Check set to Ready for QA
• Feature Branch set to bugfix/11037-icedove-spellchecker

intrigeri wrote:
> IMO we should disable spell checking by default (like we do in Tor Browser, and like it was in Claws Mail) and not spend more time on this.

I guess… but why do we do that in the Tor Browser? IMHO a spellchecker is a good thing — consistent misspellings leak a lot of identity!

Any way, I found the issue: the cause is that we enable the amnesia branding extension in Icedove. I don’t know the reason why it doesn’t work as it should, but I rather not waste time on this; I really see no reason for this extension in Icedove (and kytv didn’t give any rationale in commit:9e07c3d) and it is adapted for Tor Browser so presumably more work would have to be done to adapt it for Icedove (for starters, we generate the extension based on which langpacks are avaiable for Tor Browser; I think we’d need a separate extension for Icedove…).

So the feature branch removes this extension from Icedove, which still means that spellchecking is enabled by default, but with the en-US spellchecker selected no matter the locale. IMHO that is fine — chaning it is a click, some scrolling in the list, and another click away.

What say you?

#17 Updated by bertagaz 2016-10-05 13:28:00

• Assignee changed from bertagaz to anonym
• QA Check changed from Ready for QA to Info Needed

Reassigning to anonym, as there are questions for him here to be answered before I have a look.

#18 Updated by anonym 2016-10-07 13:20:40

• Assignee changed from anonym to intrigeri

intrigeri wrote:
> > So the feature branch removes this extension from Icedove, which still means that spellchecking is enabled by default, but with the en-US spellchecker selected no matter the locale. IMHO that is fine — chaning it is a click, some scrolling in the list, and another click away.
>
> Does that mean that if I’m primarily composing email in Italian, for every message I write, either I’ll live with an en-US spellchecker that underlines most words I write in red, or I have to go through “click, some scrolling in the list, and another click away”?

Yes.

> If it is so, then this looks like a potential PITA for anyone who writes lots of email in non-English.

Right.

> Alternatively, is disabling spell-checking for one given email writing window less of a burden? If it is easier (like one single click and not having to find the right language in a list) then this can be good enough indeed.

With “disabling spell-checking” I assume you mean “disable inline spell-checking in the composition editor by default”, then yes, we can. Users can then Right-click in the editor -> “Check Spelling”, which will enable inline spellchecking in to English in each new composition window. Then can also click the “Spelling” button which will go through all misspellings one by one in a new window, which also will default to English.

Good enough?

> Alternatively, can one pick another default language for the spellchecker globally, have it persist, so that it applies to all email I write? This would be perfect, and would address all my concerns.

It will not persist unless you go through the preferences -> Composition -> Spelling -> Language, which isn’t very convenient unless persistence is enabled for the Icedove profile.

TBH, I am feeling like my workaround from the bottom of Bug #11037#note-9 would be the best for our users, i.e. at each start of our Icedove wrapper script we check if spellchecker.dictionary is set (by a previous run, or by the user explicitly through the preferences, as detailed in the previous paragraph), if it is, do nothing, if it is uset, set it according to some guess similar to guess_best_tor_browser_locale adapted for Icedove’s langpacks/dictionaries. That will require some work, though. Overkill?

#19 Updated by intrigeri 2016-10-07 16:53:11

• Assignee changed from intrigeri to bertagaz
• QA Check changed from Info Needed to Ready for QA

>> Alternatively, is disabling spell-checking for one given email writing window less of a burden? If it is easier (like one single click and not having to find the right language in a list) then this can be good enough indeed.

> With “disabling spell-checking” I assume you mean “disable inline spell-checking in the composition editor by default”, then yes, we can. Users can then Right-click in the editor -> “Check Spelling”, which will enable inline spellchecking in to English in each new composition window. Then can also click the “Spelling” button which will go through all misspellings one by one in a new window, which also will default to English.

I assume you mean s/will enable/will disable/. And so:

> Good enough?

Not too bad.

>> Alternatively, can one pick another default language for the spellchecker globally, have it persist, so that it applies to all email I write? This would be perfect, and would address all my concerns.

> It will not persist unless you go through the preferences -> Composition -> Spelling -> Language,

OK, that’s good enough for me. People who are annoyed about it can surely find this, and if they complain we can make sure it’s properly documented somewhere.

> which isn’t very convenient unless persistence is enabled for the Icedove profile.

FWIW I don’t care much about the non-persistent Icedove use case and prefer to focus on the presumably most widespread and convenient one, i.e. with persistent Icedove data.

> TBH, I am feeling like my workaround from the bottom of Bug #11037#note-9 would be the best for our users, i.e. at each start of our Icedove wrapper script we check if spellchecker.dictionary is set (by a previous run, or by the user explicitly through the preferences, as detailed in the previous paragraph), if it is, do nothing, if it is uset, set it according to some guess similar to guess_best_tor_browser_locale adapted for Icedove’s langpacks/dictionaries. That will require some work, though. Overkill?

Overkill, yes, IMO. Let’s not try to solve this problem before people complain about it and are not happy enough with the other, aforementioned workarounds.

So I think that my concerns are solved and am reassigning to bertagaz for review.

#22 Updated by bertagaz 2016-11-09 11:57:44

• Status changed from In Progress to Fix committed
• Assignee deleted (bertagaz)
• % Done changed from 50 to 100
• QA Check changed from Ready for QA to Pass

Does what it says it does! No wonder why with such a tiny diff. Good catch ’bout the branding extension. It’s now merged!

#23 Updated by bertagaz 2016-11-15 18:23:32

• Status changed from Fix committed to Resolved