Bug 971336
Summary: | subpackages for language support | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
Component: | ibus-typing-booster | Assignee: | anish <apatil> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | apatil, i18n-bugs, mfabian, petersen, pnemade |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-11-07 05:59:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jens Petersen
2013-06-06 10:07:04 UTC
that makes i-t-b to provide almost 45 subpackages. or another way might be to hook up ibus-typing-booster with hunspell-* through yum-langpacks? (In reply to Jens Petersen from comment #0) > Description of problem: > I think UX maybe be improved if there was a subpackage for each > language with hunspell support. Currently adding a dictionary > seems kind of an awkward process requiring restarting ibus > afterwards. It doesn’t require restarting ibus when installing the dictionary with the ibus-typing-booster setup tool. Because the setup tool sets a gconf key that a dictionary has been installed: $ dconf dump /desktop/ibus/engine/typing-booster/typing-booster-de-de/ [/] dictionaryinstalltimestamp='2012-12-15 18:27:18' inputmethod='t-latn-post' ime='t-latn-post' pagesize=6 shownumberofcandidates=true tabenable=false and ibus-typing-booster then loads it without having to restart ibus. Currently ibus-typing-booster does not notice though when the dictionary becomes available by installing it with other procedures, not the ibus-typing-booster setup tool. This could probably improved to check whether a dictionary suddenly has appeared because it was installed by other means. > Actual results: > need to install dictionaries oneself to use hunspell. > > Expected results: > Select which language you want to use: > eg yum install ibus-typing-booster-de. > > Additional info: > yum-langpacks could pull in ibus-typing-booster-* for > one's language when installing ibus-typing-booster. There is another reason why I am hesitating to do this at the moment: Currently there is on ibus-typing-booster for each language. One has to enable the German typing booster to type German, the English one to type English, ... In the swiftkey application on Android, one can select a list of languages which one wants to use and one does not have to switch between them. I.e. one can select German *and* English. Then just type and it automatically does complete both reasonably well without the need for the user to switch manually. I would like to have that for ibus-typing-booster as well, i.e. the possibility to use multiple dictionaries in one engine. Maybe there could be just one engine left which can handle an arbitrary list of dictionaries and input methods. Splitting ibus-typing-booster into a lot of subpackages just because of the hunspell dictionaries goes into the opposite direction. The other reason why I don’t want to split at the moment is that the importance of the hunspell dictionaries will decrease considerably when tri-gram support is there (And I think we are pretty close now ...). Because the hunspell dictionaries are simple word lists with no tri-gram data. If tri-gram data is available, the value of the hunspell dictionaries decreases quite a lot. I think ibus-typing-booster will still use them, but they will be less important then, the prediction quality will suffer less when they are missing. (In reply to Parag from comment #1) > that makes i-t-b to provide almost 45 subpackages. Even more in future: $ rpm -qa | grep hunspell | wc 127 127 4366 We will add the missing languages to ibus-typing-booster soon, some language where hunspell dictionaries are available are only not supported by i-t-b at the moment because we did not create a xx_YY.conf file to support that language. There is no reason i-t-b could not support all of them. Creating a .conf file has become much easier already, no list of valid input characters for the language is necessary anymore. And no list of characters valid for matching in the hunspell dictionaries. And the encoding of the hunspell dictionaries is autodetected now and not in the config file anymore. So the only thing one needs to check when adding a new language is whether there are some transliteration m17n input methods available for that language and add them to the config file. Maybe even this could be made at least partly automatic? (In reply to Jens Petersen from comment #2) > or another way might be to hook up ibus-typing-booster with hunspell-* > through yum-langpacks? Looks better than splitting to me. (In reply to Mike FABIAN from comment #3) <snip> > There is another reason why I am hesitating to do this at the moment: > > Currently there is on ibus-typing-booster for each language. One has > to enable the German typing booster to type German, the English one to > type English, ... > > In the swiftkey application on Android, one can select a list of > languages which one wants to use and one does not have to switch > between them. I.e. one can select German *and* English. Then just > type and it automatically does complete both reasonably well without > the need for the user to switch manually. > > I would like to have that for ibus-typing-booster as well, i.e. the > possibility to use multiple dictionaries in one engine. Maybe there > could be just one engine left which can handle an arbitrary list of > dictionaries and input methods. How can this be possible? like one dictionary is loaded for any engine, few more can be loaded? (In reply to Mike FABIAN from comment #4) > (In reply to Parag from comment #1) > > that makes i-t-b to provide almost 45 subpackages. > > Even more in future: > > $ rpm -qa | grep hunspell | wc > 127 127 4366 > > We will add the missing languages to ibus-typing-booster soon, > some language where hunspell dictionaries are available are only > not supported by i-t-b at the moment because we did not > create a xx_YY.conf file to support that language. There is no > reason i-t-b could not support all of them. Creating a .conf file > has become much easier already, no list of valid input characters for > the language is necessary anymore. And no list of characters valid > for matching in the hunspell dictionaries. And the encoding of the > hunspell dictionaries is autodetected now and not in the config file anymore. > So the only thing one needs to check when adding a new language is > whether there are some transliteration m17n input methods available for that > language and add them to the config file. Maybe even this could be made > at least partly automatic? I just consider number of conf file available in i-t-b source and as yum-langpacks only consider langcode without country-code, count comes to 45. (In reply to Mike FABIAN from comment #5) > (In reply to Jens Petersen from comment #2) > > or another way might be to hook up ibus-typing-booster with hunspell-* > > through yum-langpacks? > > Looks better than splitting to me. I think in current scenario, the yum-langpack plugin already pulls hunspell wherever its available for any language. So as long as user is installing complete language support using langinstall command of yum, he will get hunspell pre-installed for his i-t-b. But, if user manually adds some other language i-t-b engine then manual installation is needed. Looks like i-t-b is moving to multilingual support which probably deprecates this rfe - so closing for now. |