Spelling dictionary names not human readable on Linux

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Toolkit
XUL Widgets
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: era+mozilla, Assigned: reed)

Tracking

unspecified
mozilla1.9.3a1
x86
Linux
Points:
---

Firefox Tracking Flags

(status1.9.2 beta5-fixed, status1.9.1 .8-fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080316 Ubuntu/8.10 (intrepid) Firefox/3.0.13
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080316 Ubuntu/8.10 (intrepid) Firefox/3.0.13

It seems that the code for finding spelling dictionaries in inlineSpellCheckUI.js expects nonstandard dictionary names.  On Linux, most spelling dictionaries have a file name like lc_RC where lc = language code (e.g. "en") and RC = region code (e.g. "US"), separated by an underscore.  By contrast, Mozilla expects the separator to be a hyphen.

On a Fedora 12 alpha Live CD, when you install hunspell-en (the dictionary pack for English for hunspell) you get a language menu with unreadable computer-ish names like "en_GB" and "en_US".  On Windows (and Debian, because they have a workaround in place), you get human-readable names like "English / United Kingdom" and "English / United States" in the spelling dictionary language menu.

Reproducible: Always

Steps to Reproduce:
1. Navigate to a page with a <textarea> or other spell-checkable element
2. Type in some typos
3. Right-click in the textarea, and inspect the Languages > submenu in the menu you got when you right-clicked
Actual Results:  
 en_AU
 en_ZA
 en_GB
 en_US

Expected Results:  
 English / Australia
 English / South Africa
 English / United Kingdom
 English / United States

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/66015 is a related Ubuntu bug which has lots of triage notes (and also a fair amount of noise).

Note that Ubuntu inherited the Debian workaround, which has a problem (which is really the topic of the Ubuntu bug in question): it displays *both* the underscored names and the human-readable names.

Comment 1

8 years ago
This is supposed to be done by the fix in bug 335600 - why doesn't it work on Linux ?
(Reporter)

Comment 2

8 years ago
> var isoStrArray = list[i].split("-");

This splits the lc and RC on hyphen, but if they are not hyphen-separated, it doesn't manage to split them properly.  Most other tools on Linux (OpenOffice, for example) have the underscore as separator.  So the problem isn't really in the code per se, but in the assumption that the dictionary file names will be using a hyphen between these parts.

(The Debian workaround is to install symlinks lc-RC -> lc_RC for each installed dictionary, but that has other problems, as mentioned above.)

My proposed fix would simply use an underscore and be done with it, but that requires Windows (and Mac?) dictionaries to be named according to the Linux / ISO convention.  Who controls that, are the Windows and Mac spelling dictionaries distributed by Mozilla or by a third party?  Or anyway, perhaps the code could use a different separator on different platforms, but I'm not enough versed in JavaScript to know how to do that elegantly and idiomatically.  Or well, perhaps it can split on *either* hyphen or underscore, which should work with minimal fuss on all platforms.

(A crude patch is available as an attachment to the Launchpad bug linked above, but it's completely trivial.)
(Assignee)

Comment 3

8 years ago
http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/locales/en-US/hunspell/ shows en-US. So, do we need to support both '_' and '-' as separators?
Severity: trivial → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

8 years ago
Component: General → XUL Widgets
Product: Firefox → Toolkit
QA Contact: general → xul.widgets
(Assignee)

Comment 4

8 years ago
Created attachment 409292 [details] [diff] [review]
patch - v1

Support both separators using a regex.
Assignee: nobody → reed
Status: NEW → ASSIGNED
Attachment #409292 - Flags: review?(gavin.sharp)
Attachment #409292 - Flags: review?(gavin.sharp) → review+
(Reporter)

Comment 5

8 years ago
+1

Dunno if I'm allowed to say that here but that seems like an elegant and unintrusive fix.
(Assignee)

Comment 6

8 years ago
http://hg.mozilla.org/mozilla-central/rev/3776e2ddf1a3
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Comment 7

8 years ago
Comment on attachment 409292 [details] [diff] [review]
patch - v1

Ubuntu and other Linux distros would appreciate this fix being backported, as it fixes a very ugly UI eye sore.
Attachment #409292 - Flags: approval1.9.2?
Attachment #409292 - Flags: approval1.9.1.7?
Attachment #409292 - Flags: approval1.9.0.17?
(Assignee)

Updated

8 years ago
Attachment #409292 - Flags: approval1.9.1.6?
Attachment #409292 - Flags: approval1.9.0.16?
Attachment #409292 - Flags: approval1.9.0.17?
Attachment #409292 - Flags: approval1.9.0.16?
Attachment #409292 - Flags: approval1.9.1.6? → approval1.9.0.17?

Updated

8 years ago
Depends on: 528831
(Assignee)

Updated

8 years ago
It only fixes half of the issue though. The duplicates still show up.
(Assignee)

Comment 9

8 years ago
(In reply to comment #8)
> It only fixes half of the issue though. The duplicates still show up.

Isn't that easily fixable on your end by removing the hack (symlinks) you've used for years for this?
Created attachment 414001 [details] [diff] [review]
patch for 1.9.1

FWIW, the file to which the patch - v1 applies doesn't exist in older releases. This patch applies to the right file on these older releases.
(In reply to comment #9)
> Isn't that easily fixable on your end by removing the hack (symlinks) you've
> used for years for this?

I really don't know where they come from, though. I certainly didn't add them myself as I'm not the dictionary maintainer, and I don't recall requesting them... I would happily have fixed the current bug if I had known these links were being added especially for mozilla products, which seem to be the case. So yes, removing the symlinks is the fix. I'm still puzzled why they got there, though.

Comment 12

8 years ago
(In reply to comment #8)
> It only fixes half of the issue though. The duplicates still show up.

I filed  Bug 528831 to address that issue.
(Reporter)

Comment 13

8 years ago
FWIW Mike Hommey opened a bug on the Debian side about the now-redundant symlinks: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557604
Comment on attachment 409292 [details] [diff] [review]
patch - v1

a192=beltzner
Attachment #409292 - Flags: approval1.9.2? → approval1.9.2+
(Assignee)

Comment 15

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b885d0d5daca
status1.9.2: --- → final-fixed
Attachment #409292 - Flags: approval1.9.0.17? → approval1.9.0.17-
Attachment #409292 - Flags: approval1.9.1.8?
Comment on attachment 414001 [details] [diff] [review]
patch for 1.9.1

Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #414001 - Flags: approval1.9.1.8+
(Assignee)

Comment 17

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/600ed75474d4
status1.9.1: --- → .8-fixed
You need to log in before you can comment on or make changes to this bug.