Currently, app-text/hunspell does not seem to provide an approach to deactivate some of the many language variants that get installed with many dictionary files. For example, app-dicts/myspell-en contains spelling variants for GB, GB-oed, US, ZA, AU, NZ, CA; other myspell packages exhibit the same property. It is very bothersome to have a very long language selection list in applications' spell-check language choice dialog; I mostly encounter this in KDE-apps and Mozilla-apps. Deactivating unused or unwanted language variants would be an option, but I did not find a 'nice' way to do it (in-application or cross-application). In the end, I renamed the .dic and .aff files/symlinks of the unwanted variants in /usr/share/myspell to .dic.dontshow and .aff.dontshow, which had the desired effect. However, I do not know where the dictionary.lst.* files enter the picture (I added # in lines of variants I did not want, but this was not sufficient). I see the following options: 1. variant-use flags on the myspell packages to include/exclude them (N.B.: variants don't always map to locales!) either by not installing them or not installing the symlinks to /usr/share/hunspell (then the English-language files should also be installed there) 2. a configuration script that finds the variants present and installs/removes the necessary symlinks 3. upstream should take care of this, and this can be set by a system config file in /etc and user config file in ~. Reproducible: Always
(In reply to Erik Quaeghebeur from comment #0) > dictionary.lst.* [...] (I added # in lines of variants I did not want, but this > was not sufficient). This appears to be unnecessary, not touching the dictionary.lst.* files seems sufficient. (Tested in Thunderbird.)
(In reply to Erik Quaeghebeur from comment #1) > (In reply to Erik Quaeghebeur from comment #0) > > dictionary.lst.* [...] (I added # in lines of variants I did not want, but this > > was not sufficient). > > This appears to be unnecessary, not touching the dictionary.lst.* files > seems sufficient. (Tested in Thunderbird.) spellchecker.dictionary_path;/usr/share/myspell you can just blank the pref in mozilla products and use external dicitionairies from mozilla if you so wish.
(In reply to Jory A. Pratt from comment #2) > > spellchecker.dictionary_path;/usr/share/myspell > > you can just blank the pref in mozilla products and use external > dicitionairies from mozilla if you so wish. Good to know this, but I prefer to use the system spellchecker over using separate spellcheckers for every different application in which text is handled.
*** This bug has been marked as a duplicate of bug 469422 ***
(In reply to Ian Delaney from comment #4) > > *** This bug has been marked as a duplicate of bug 469422 *** Excuse me, in what way is this a duplicate of bug 469422? This bug is about language variants not being configurable; that bug is about man pages in all languages being installed! Please mark this bug as open again and remove me from the Cc list of the other, unrelated bug.
Oh, sorry, I misread. I asked Ian to do that.
I'm proxy-maintainer for the package now. Erik, The reason I had it marked duplicate is because it is similar to (but not the same as) bug 469422 - a cursory glance made me believe it was the same. Sorry about that. I've removed your CC accordingly. I am presently busy for the holidays and do not have time to fix this issue until mid-January. If anyone wishes to provide patches sooner, I'd happily look at them.
(In reply to Erik Quaeghebeur from comment #0) > I see the following options: > 1. variant-use flags on the myspell packages to include/exclude them > (N.B.: variants don't always map to locales!) either by not installing them > or not installing the symlinks to /usr/share/hunspell (then the > English-language files should also be installed there) LINGUAS already exists as a variable; there is no need to add these USE flags, and would be redundant with LINGUAS anyway. > 2. a configuration script that finds the variants present and > installs/removes the necessary symlinks The list of files owned by the package would fall out of sync as a result, and a similar effect can be achieved by the end user if they're willing to let that happen. This also feels like a terrible bolted-on hack. > 3. upstream should take care of this, and this can be set by a system > config file in /etc and user config file in ~. Portage builds are not affected by system configuration other than portage variables as a matter of policy. Applications should respect your locale if it is showing all the language variants. How I would solve this issue (and I must emphasise I am very busy atm) is to simply check the LINGUAS variable. However, I am unsure of what to do when for instance, en is set but no variants are set (do we just install all variants?), or when both en and regional languages are set (do we install all variants or just the local one? that would be surprising behaviour if we install all variants with en).
(In reply to Elizabeth Myers from comment #8) Dear Elizabeth, Thanks for looking at this bug. Take your time, there is a workable workaround. > > I see the following options: > > 1. variant-use flags on the myspell packages to include/exclude them > > (N.B.: variants don't always map to locales!) either by not installing them > > or not installing the symlinks to /usr/share/hunspell (then the > > English-language files should also be installed there) > > LINGUAS already exists as a variable; there is no need to add these USE > flags, and would be redundant with LINGUAS anyway. Well, I always assumed that LINGUAS was for the user interface language. This is in theory orthogonal to installed spellchecker languages (in practice there will usually be at least some overlap). So in principle I do think package-specific use flags would be proper and the current use of LINGUAS is improper. So, an important practical question is whether hunspell itself is localized. > How I would solve this issue (and I must emphasise I am very busy atm) is to > simply check the LINGUAS variable. However, I am unsure of what to do when > for instance, en is set but no variants are set (do we just install all > variants?), or when both en and regional languages are set (do we install > all variants or just the local one? that would be surprising behaviour if we > install all variants with en). (I'm ignoring my principled objection to this practically quite reasonable solution here.) I would interpret 'en' as 'en_*' (install all variants) and not do anything special when also a variant is set in LINGUAS. So 'en, en_US' would still result in 'en_*'. Picky people like me can always set and unset some linguas in /etc/portage/package.use for hunspell.
Hello, I am a new hunspell maintainer (they do chage frequently, don't they?) Even though it's been 10 years since the issue has been opened, I agree that something should be done on this matter, especially regarding myspell-en. I am currently busy for a week or so, and once I have time I will work on adopting myspell-* packages together with making their flags sane. Both you and Elizabeth have expressed good ideas, so here is mine (for myspell-en): en LINGUAS flag is deleted and every other regional one is set on by default. This way we both get rid of ambiguity brought by general "en" flag, and don't "discriminate" anyone by setting only specific dialect by default (experienced users can always disable unneeded variants) What do you think?
(In reply to zurabid2016 from comment #10) > en LINGUAS flag is deleted and every other regional one is set on by > default. This way we both get rid of ambiguity brought by general "en" flag, > and don't "discriminate" anyone by setting only specific dialect by default > (experienced users can always disable unneeded variants) > What do you think? I think the idea can definitely work. The only possible issue I see is that perhaps it should be L10N flags, not LINGUAS ones. I looked at the localization guide https://wiki.gentoo.org/wiki/Localization/Guide, but it didn't completely clarify the choice for me.
Thank you for the "acknowledgement" :) Once I have wore free time, I will work on adopting the dictionaries themselves. As to distinction between L10N and LINGUAS, this will definitely be brought up on IRC and the best option will be implemented
