Closed Bug 216382 Opened 18 years ago Closed 15 years ago

need to put the spell checker dictionary files (should not be in components dir)

Categories

(Core :: Spelling checker, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1beta1

People

(Reporter: sspitzer, Assigned: benjamin)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1, Whiteboard: [swag: 1d] 181b1+)

Attachments

(2 files)

from mscott:

we want to fix where they store the dictionary files.

right now, the build puts them into the components directory.

but they aren't components.

from
http://lxr.mozilla.org/mozilla/source/extensions/spellcheck/myspell/dictionaries/Makefile.in#47

DICTIONARY_FILES=\
	$(srcdir)/en-US.dic \
	$(srcdir)/en-US.aff \
	$(NULL)

libs::
	$(INSTALL) $(DICTIONARY_FILES) $(DIST)/bin/components/myspell

mscott, can you clarify where they should be going?
Depends on: 225468
*** Bug 238092 has been marked as a duplicate of this bug. ***
Component: Browser-General → Spelling checker
QA Contact: general → core.spelling-checker
my suggestion:
first, look in $profile/dictionaries
then, $app/dictionaries
then, $app/components/dictionaries.
the last is only to not break current .xpi dictionary packages.
mvl: i'd like to plug gre/dictionaries.

if i have 20 gecko apps, i don't want 20 dictionaries.
OK, couple of questions:

1) are these dictionaries openoffice-compatible?
2) are these dictionaries the openoffice dictionaries?
3) can we make this a "system" function (for example, install to
/usr/lib/dictionaries and/or ~/.dictionaties)
(In reply to comment #4)
> 1) are these dictionaries openoffice-compatible?
Yes.

> 2) are these dictionaries the openoffice dictionaries?
In most cases, yes. 

> 3) can we make this a "system" function (for example, install to
> /usr/lib/dictionaries and/or ~/.dictionaties)

On my redhat defora box, the openoffice dict are in
/usr/lib/openoffice/share/dict/ooo/
I dont know if openoffice looks somewhere else. I think we could do without a
system location. Just the profile or the mozilla app dir. If a user don't wants
to copy, there are symlinks. (too bad windows don't know about that. at least
not in a way accessible to the regular user) 
Last I looked at the code there were comments to the affect that the location
should be set via a pref... wouldn't that suffice instead of hardcoding one
location as is done currently or hardcoding multiple locations as is being
suggested? Even if there are hardcoded locations a pref would still provide value.
bsmedberg: do you have ideas on this? What is an easy place to put the
spellcheck files to be able to install them using the EM? (I think install.js
can make most locations work when installing in seamonkey)
(I really want to get this fixed, so that i can install extensions somewhere in
my profile)
I think we should use a list of directories
(nsIDirectoryServiceProvider2.getFiles) like we do for plugins, chrome
manifests, etc.

The problem with this has always been Seamonkey's lack of a seamonkey-only
dirserviceprovider, and my insistence that we shouldn't burden
nsAppDirectoryServiceDefs with additional stuff.

nsXREDirServiceProvider can easily provide what we need, and I even can think of
a way to make it app-only (need to file a bug on that).
A further benefit (at least on Mac OS X, maybe others) is that dictionaries will
remain installed when Mozilla is upgraded.
Blocks: 119232
OS: Windows 2000 → All
Hardware: PC → All
Any progress on this? I thoungt I might mention that I want this, too, and
unlike the poster of comment #5 I think we quite defintely ought to look in a
"system" location (/usr/share/dict) or similar. Dictionaries should obviously be
installed in such a way that the may be shared by applications and users. User
profile install is generally bad, IMO; "global" per-application is slightly
better, but its quite annoying that you have to install the same dictionaries
all over again to support another application using the same format. Sharing via
symlinks is slightly better, and it's actually what I do now, but this also
requires work that ought to be unneccessary, and I very much consider it a hack.

Another problem is that Mozilla expects files in a slightly different format
from what the OOo install normally uses, so you can't just symlink the directroy. 
(In reply to comment #10)

> 
> Another problem is that Mozilla expects files in a slightly different format
> from what the OOo install normally uses, so you can't just symlink the directroy. 
That should be file *names* of a different format. Mozilla uses
<language>-<country> or sometimes just <language> in the "root" of the file
name, while most OOo dictionaries have <language>_<country> - although the name
is actually configurable. In other words, the Mozilla wordlist file for British
English is en-GB.dic, while in the OOo dictionary directory it's called
en_GB.dic. For Norwegian Bokmål, the names are nb.dic and nb_NO.dic, respectively.
*** Bug 301166 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4?
not gonna block on this but if someone comes up with a patch, please nominate.
Flags: blocking1.8b4? → blocking1.8b4-
Blocks: 310285
See bug 313240 comment 1, bug 313240 comment 4,  bug 313240 comment 11
Also bug 272440 

This should be a blocker. 

Either make it possible for people, who do not have permission to write into the
application directory, to install dictionaries [into their profile] or disable
the 'install new dictionary' UI. Consider the implication of disabling the UI
before thinking that's a viable option though.

Above all, do not *lie* to the user by saying installation was successful when
it clearly wasn't. 

Simply ignoring this is not an option.
Flags: blocking1.9a1?
Any chance that bug 225468, bug 267390 and bug 216382 can be rationalised to one bug?
*** Bug 325111 has been marked as a duplicate of this bug. ***
*** Bug 332412 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.1?
*** Bug 335331 has been marked as a duplicate of this bug. ***
*** Bug 338072 has been marked as a duplicate of this bug. ***
Brett any thoughts on this r.e. blocking for 1.8.1?
I talked to cbeard a little bit about dictionary install. I think we really need to change it. I think we really should fix this for 2.0.
I can do this next week if nobody gets to it sooner: from an inspection of the code it doesn't actually look that hard (and we'll get the ability to ship dictionaries in extensions as an easy bonus).
Ok, over to Benjamin then.
Assignee: mozilla → benjamin
Flags: blocking1.8.1? → blocking1.8.1+
Whiteboard: [swag: 1d]
Brett, let me know if you won't be able to look at this in the next few days.
Attachment #227279 - Flags: review?
Whiteboard: [swag: 1d] → [swag: 1d] 181b1+
Attachment #227279 - Flags: review? → review?(enndeakin)
Target Milestone: --- → mozilla1.8.1beta1
Comment on attachment 227279 [details] [diff] [review]
Use directoryservice, rev. 1

>+  // SetDictionary can be called multiple times, so we might have a
>+  // valid mMySpell instance which needs cleaned up.
>+  if (mMySpell)
>+    delete mMySpell;
> 

no need to null check here.

+  if (aResult)
+    NS_ADDREF(*aResult = mNext);
+

NS_IF_ADDREF?
Attachment #227279 - Flags: review?(enndeakin) → review+
Blocks: 343076
You missed a file when relanding this, causing me crashes due to an uninitialized nsBaseHastable<>.  I just relanded the factory changes.
It appears that these changes have completly broken spell check in today's build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1,Firefox ID:2006062904 [cairo]
(In reply to comment #27)
> It appears that these changes have completly broken spell check in today's
> build:
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629
> Minefield/3.0a1,Firefox ID:2006062904 [cairo]

There don't seem to be any changes to the various package files in the patch that landed.
Depends on: 343126
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This is a consolidated branch patch with the regression fixes from bug 343126 fixed.
Attachment #227573 - Flags: approval1.8.1?
Comment on attachment 227573 [details] [diff] [review]
1.8 branch merge, rev. 1

approved as per 181drivers
Attachment #227573 - Flags: approval1.8.1? → approval1.8.1+
I had to revise the 1.8.1 checkin because 1.8.1 doesn't have nsUnicharPtrHashKey, so I switched to use nsStringHashKey
Keywords: fixed1.8.1
Blocks: 324252
Blocks: 343901
I was about to report three separate bugs against Thunderbird 1.5.0.8 spell checking but, as this is being/has been worked on, I'll just note them here as I'm not sure if they'll have been resolved by  the patch.  Comments are for Ubuntu Linux at least though I assume they apply much more widely.

1. Installation of downloaded dictionary appears to have worked (dialog box says so) but actually it hasn't worked (dictionary doesn't show in Edit->Preferences->Composition->Spelling->Language drop down list).  In my case, of course, it failed because I was running as a non-root user but Thunderbird was installed as the root.

This point has been noted in comment #14 by Paul Tomlin.  I'd like to second his comment that saying that the installation was successful when it clearly wasn't is not an option.  The lack of a report of the failed installation is, in my opinion, much more serious than the root cause of the failure.

2. Using "sudo thunderbird" allows the installation but sets only read permission for root on the dictionaries.  Something like "sudo chmod a+r en-GB*" in the components/myspell directory is required to make them usable to non-root users.

3. If dictionaries are present but not readable (as per 2) then no warning is given - instead all words are reported as incorrectly spelt.
Flags: blocking1.9a1?
Blocks: 225468
No longer depends on: 225468
Duplicate of this bug: 423119
You need to log in before you can comment on or make changes to this bug.