[Fedora-i18n-bugs] [Bug 971336] New: subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

Bug ID: 971336
           Summary: subpackages for language support
           Product: Fedora
           Version: 19
         Component: ibus-typing-booster
          Severity: unspecified
          Priority: unspecified
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail]

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.

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.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

Parag  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Parag  ---
that makes i-t-b to provide almost 45 subpackages.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #2 from Jens Petersen  ---
or another way might be to hook up ibus-typing-booster with hunspell-*
through yum-langpacks?

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #3 from Mike FABIAN  ---
(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.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #4 from Mike FABIAN  ---
(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?

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #5 from Mike FABIAN  ---
(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.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #6 from Parag  ---
(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?

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #7 from Parag  ---
(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.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

--- Comment #8 from Parag  ---
(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.

[Fedora-i18n-bugs] [Bug 971336] subpackages for language support

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=971336

Jens Petersen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Resolution|---                         |WONTFIX
        Last Closed|                            |2013-11-07 00:59:44

--- Comment #9 from Jens Petersen  ---
Looks like i-t-b is moving to multilingual support
which probably deprecates this rfe - so closing for now.