https://bugzilla.redhat.com/show_bug.cgi?id=971336
--- Comment #3 from Mike FABIAN <mfabian(a)redhat.com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=7YB9uDI4bw&a=cc_unsubscribe