Hi, Today AFAICT there is no way to properly install a dictionary into mozilla thunderbird. When I emerge a myspell package, I would like the accurate files to be symlinked from /usr/share/myspell to the myspell directory of the thunderbird installation directory (/usr/lib/mozilla-thunderbird/components/myspell for instance). I suggest to enhance the myspell.eclass in order to achieve that, exactly as it works today for openoffice.
(In reply to comment #0) > Today AFAICT there is no way to properly install a dictionary into mozilla > thunderbird. Yes, because upstream suck and assume a completely broken location for user installs (see Bug 100802).
(In reply to comment #1) > Yes, because upstream suck and assume a completely broken location for user > installs (see Bug 100802). > OK I did not noticed a bug was already opened on almost the same subject. My feeling is that if there is a bug upstream concerning dictionary installation from the thunderbird gui (I guess dictionaries should be installed somewhere in the ~/.thunderbird directory), it does not prevent us to provide dictionaries installation at the system level, with the myspell packages, don't you think ?
The myspell stuff is intended to be extended to support linking system-level application-specific locations for dictionaries to the common area in /usr/share/myspell. Assuming thunderbird is using myspell dictionariesMy preferred solution would be to create a mozilladict (or better name ;) ) eselect module to setup the thunderbird dictionary data, which can then be invoked from the postinst() of the myspell ebuilds and that of thunderbird (as we do with OOo). I don't use Thunderbird, so it would be useful is someone could describe the details of the thunderbird myspell dictionary directory, and what other stuff the xpi files do to install a dictionary for thunderbird.
Actually it looks pretty trivial. It seems the xpi installers just dump the dictionary files into the Thunderbird "Components/myspell" directory, and that there are no other configuration files to fiddle with. mozilla people - can you confirm the location of the above directory is /usr/$(get_libdir)/mozilla-thunderbird/components/myspell? Is it different for your binpackage (looks like it might be /opt/thunderbird/components/myspell)?
BTW, the myspell.eclass seems buggy with openoffice-bin on AMD64 because of this in myspell.eclass : MYSPELL_OOOBASE="/usr/lib/openoffice/share/dict/ooo" The accurate path on AMD64 would be /usr/lib32/openoffice/share/dict/ooo I looked at oodict.eselect and there is the same bug. Well, what I see as a bug AFAICT :-) Maybe I should open another issue for this one ?
(In reply to comment #4) > > mozilla people - can you confirm the location of the above directory is > /usr/$(get_libdir)/mozilla-thunderbird/components/myspell? Is it different for > your binpackage (looks like it might be /opt/thunderbird/components/myspell)? > I'm not mozilla people but I can confirm that linking *.dic and *.aff in /usr/$(get_libdir)/mozilla-thunderbird/components/myspell after having emerged some myspell dictionaries works right for me.
(In reply to comment #3) > Assuming thunderbird is using myspell dictionariesMy preferred solution would > be to create a mozilladict (or better name ;) ) eselect module to setup the > thunderbird dictionary data, which can then be invoked from the postinst() of > the myspell ebuilds and that of thunderbird (as we do with OOo). Agree. I vote for mozdict, shorter :-)
(In reply to comment #5) > BTW, the myspell.eclass seems buggy with openoffice-bin on AMD64 because of > this in myspell.eclass : See bug #139228 - already in hand.
Created attachment 91159 [details] Mozilla Thunderbird myspell dictionary eselect module Well, here's a first attempt :) The attachment is an eselect module. Make sure you have eselect-1.0.2 or higher, and copy the attached file to /usr/share/eselect/modules/ (eventually it'll be distributed as an ebuild app-admin/eselect-tbirddict). The name may change, if we find a better one. To map all your installed myspell dictionaries to Thunderbird, do: # eselect tbirddict update This assumes thunderbird is installed in /usr/lib/thunderbird. If you have the binary package installed, do: # eselect tbirddict update --basedir /opt/thunderbird and if you have a 32-bit version installed on amd64 do: # eselect tbirddict update --basedir /usr/lib32/thunderbird Commands are the same as for the OpenOffice.org dictionary eselect module: $ eselect tbirddict list - lists the myspell dictionaries $ eselect tbirddict show - shows the dictionaries mapped to thunderbird $ eselect tbirddict set myspell-it - sets the map for italian dictionary to thunderbird $ eselect tbirddict unset myspell-it - unsets the map for italian dictionary to thunderbird The update command is expected to be used by the thunderbird ebuilds, and the set/unset commands by the myspell ebuilds. Please try it out and see what you think. Couple of points to note: 1) as with the myspell ebuilds, it does not manipulate language variants separately; if you have a myspell ebuild installed you get all the variants that go with that language. This module will install all the variants of a language to the Thunderbird language area. 2) Many myspell languages are not recognised by Thunderbird; they install fine and can be selected and used, but they don't have friendly names in the Thunderbird language selection drop-down menu. There's nothing I can do about that; it's a feature of Thunderbird (OpenOffice.org has similar issues with language names it doesn't know about). Enjoy!
(In reply to comment #9) <<snip>> > To map all your installed myspell dictionaries to Thunderbird, do: > > # eselect tbirddict update > > This assumes thunderbird is installed in /usr/lib/thunderbird My base directory for thunderbird is /usr/lib/mozilla-thunderbird. This is the one where regular portage installed thunderbird, so I guess this should the default setting in the eselect module. I tested this module : 1) eselect tbirddict update --basedir /usr/lib/mozilla-thunderbird symlinks all the *.aff *.dic from /usr/share/myspell to thunderbird : OK 2) eselect tbirddict unset myspell-fr --basedir /usr/lib/mozilla-thunderbird removes the fr_FR.aff and fr_FR.doc symlinks from the thunderbird directory : OK 3) eselect tbirddict set myspell-fr --basedir /usr/lib/mozilla-thunderbird re-symlinks correctly the fr_FR files to thunderbird : OK 4) eselect tbirddict show --basedir /usr/lib/mozilla-thunderbird shows accurate information : OK 5) eselect tbirddict list --basedir /usr/lib/mozilla-thunderbird shows accurate information : OK Many thanks for this Kevin :-)
Created attachment 91170 [details] fixed default path for thunderbird Thanks for good testing, Rodolphe. Default directory fixed in line with /usr/lib/mozilla-thunderbird
Kevin, I thought about this tonight. I'm pretty sure there are several other apps that would need such eselect modules to set up the myspell dictionaries, and for most of them I'm pretty sure what they would need would be the symlinks only, just like for thunderbird. Don't you think it would interesting (especially for you, but also for the maintainers of the packages needing the myspell dictionaries) to have a basic eselect module (lets call it basedict) which handles the symlinks only ? The basedict module would take a --dictdir option to define the symlinks location, and would provide some hooks to allow things like the dictionary list generation for oo. In most cases the basedict module should be sufficient and could be used directly by other applications. In other cases (like the oo case where a dictionary list needs to be generated), the development of a new eselect module would just be simpler and save a bit of your time. What's your opinion ?
I've been thinking along the same lines. My plan is to wait until we have a few, then think about merging them then, depending on how different they are. I'd call the module 'myspell' btw :) One possibility is to add an application option to the commands; e.g. eselect myspell update --application mozilla-thunderbird another is to have a separate eselect-myspell configuration file containing the applications to be managed and their base directories etc. However I think it's best to wait until there are a few applications before merging everything; there's always a temptation to over-engineer if there are not enough examples.
Please note that upcoming mozilla-firefox-2.0 will also use myspell dictionaries. Actually, there is mozilla-firefox-2.0_beta1 ebuild in the current portage tree (masked for now). The directory for dictionary files is: /usr/lib/mozilla-firefox/dictionaries. Maybe it is time to resolve this bug? (there are at least three applications using myspell). I am using Firefox 2.0_beta now and I can help testing some solutions.
Re-targeting this bug to bring support for all applications together in one eselect module.
Created attachment 93404 [details] Combined myspell management for applications Here goes :) First cut. This is intended to replace oodict.eselect, and the tbirddict.eselect provided earlier in a generic way. Obviously after we determine the code is sensible I'll also update the eselect-oodict module to provide a backwards-compatibility wrapper for the new module, but that's for later. The idea is that ebuilds call: eselect myspell install <appname> --directory=<directory> --options=<options> in their postinst phase. This will register the directory and options for the package in a file in /etc/eselect/myspell/ which is recalled as necessary for other operations invoked by the user. Note, I've dropped "class" as the module is clearly only for myspell/hunspell dictionaries. The install action also invokes the update action to register all installed dictionaries with the application. For users, the other actions are pretty much the same as before. The set, unset and show options no longer take a '--libdir' option as that is configured by install and retrieved automatically. They now take an option '--app=<app name>' to cause them to manage just one application rather than all (which is the behaviour if the option is not specified). The application name is up to the ebuild to choose - obviously the sensible choice is ${P}. The options currently provided are chosen to support the various bits and pieces needed by openoffice and the mozilla applications. They are: all-softlinks creates soft links for all three dictionary types spelling-soflinks creates soft links only for the spelling dictionaries dictionary.lst creates the dictionary.lst file dashnames makes the softlink names 'en-US' rather than 'en_US' so for the current set of applications the options are: openoffice: all-softlinks,dictionary.lst mozilla-*: spelling-softlinks,dashnames Some examples of the install action for ebuilds: - standard openoffice: eselect myspell install openoffice \ --directory="/usr/lib/openoffice/share/dict/ooo" \ --options="all-softlinks,dictionary.lst" - binary openoffice on multilib amd64: eselect myspell install openoffice-bin \ --directory="/usr/lib32/openoffice/share/dict/ooo" \ --options="all-softlinks,dictionary.lst" - thunderbird eselect myspell install mozilla-thunderbird \ --directory="/usr/lib/mozilla-thunderbird/components/myspell" \ --options="spelling-softlinks,dashnames" - binary thunderbird eselect myspell install mozilla-thunderbird-bin \ --directory="/opt/thunderbird/components/myspell" \ --options="spelling-softlinks,dashnames" - firefox, from 2.0 eselect myspell install mozilla-firefox \ --directory="/usr/lib/mozilla-firefox/dictionaries" \ --options="spelling-softlinks,dashnames" (I'm guessing that firefox will need the "dashnames" the same as thunderbird) One last note - this version includes the change discussed on bug #139669 (see that bug for details). Please try it out, let me know what you all think.
(In reply to comment #16) > > > Please try it out, let me know what you all think. > Looks very good to me, though I'm not sure how we would handle the transition from the "old" to the new eclass without breaking the current openoffice-ebuilds. Any idea here?
(In reply to comment #17) > I'm not sure how we would handle the transition > from the "old" to the new eclass without breaking the current > openoffice-ebuilds My plan is to provide a wrapper so that calls to 'eselect oodict' get rewritten as appropriate "eselect myspell" calls.
(In reply to comment #18) > (In reply to comment #17) > > I'm not sure how we would handle the transition > > from the "old" to the new eclass without breaking the current > > openoffice-ebuilds > > My plan is to provide a wrapper so that calls to 'eselect oodict' get rewritten > as appropriate "eselect myspell" calls. > Sounds perfect to me :)
*** Bug 154803 has been marked as a duplicate of this bug. ***
Why you didn't put a "myspell" use flag in thunderbird, firefox, oo.. etc?
*** Bug 155672 has been marked as a duplicate of this bug. ***
Just a small issue met with the thunderbird ebuild : when I re-emerge thunderbird after having set some dictionaries using the myspell module, thunderbird removes the old symlinks to en dictionary files and installs raw files instead. This is of course because the myspell module is not used everywhere yet. I hope it will come soon ! rrocca@erbium ~ $ sudo equery f mozilla-thunderbird | grep myspell /usr/lib/mozilla-thunderbird/components/libmyspell.so /usr/lib/mozilla-thunderbird/components/myspell /usr/lib/mozilla-thunderbird/components/myspell/en-US.aff /usr/lib/mozilla-thunderbird/components/myspell/en-US.dic
What's still left to do befor getting this eselect module into portage? Any ETA? I just tested the myspell.eselect module and it works nice and easy. I have been using tbirddict.eclass since it was first released here in July without any problem (on both x86 and amd64).
Sorry, I've been rather busy recently, just catching up with stuff now. It's in my list, just not quite at the top yet. I need to go over it again, then co-ordinate with the various affected packages (OOo, mozilla-*), make sure I'm providing what all of them need and that they're happy and so on.
*** Bug 156737 has been marked as a duplicate of this bug. ***
Any news on this? The lack of spellchecking after a Thunderbird update just annoyed me again today. The above mechanism seems to be a great idea. Regards, Rene
Uhm correct me if I'm wrong but here on my system there is already a well functioned myspell installation done by Portage. So why bringing in additional installs? Just use the existing one by symlinking as base? No Program will feel the difference and could do additional stuff as is. Just modify the ebuilds of Programs with integrated myspell to substitute the original myspell dir with a symlink before merging into system.
FYI mozilla-firefox-3.0_beta2-r1(mozilla overlay) already uses myspell installed dictionaries
Reassigning due to retirement
thunderbird and firefox both already use myspell dictionaries. There is no need for any of this on our end.
Uhm my firefox (3.6.3) does, not detect the installed myspell dictionaries, so why is this bug unneeded??? Please reopen and set summary to "myspell: use portage installed dictionaries for firefox and thunderbird"
