Bug#418430: [Debian-hebrew-common] Re: [Debian-hebrew-package] Bug#418430: mixed hebrew/english spell checking is needed

[kobi zamir]

> Well, can't we ask the nice Debian/Qt maintainers to apply a patch to
> call multispell instead?
We can, If I was the nice Debian/Qt maintainers I would say NO.
k3spell is an old code that should be replaced by sonnet, because it
has a lot of other problems and the "hspell" const string is not one
of this problems.

> Actually, taking a look in kdelibs/kspell2/plugins/hspell, it seems
> that kspell accesses the dictionary using libhspell and doesn't
> directly call hspell in any event. So how does this alternatives trick
> work anyway?
kmail use old kde3support for spelling:
http://websvn.kde.org/trunk/KDE/kdelibs/kde3support/kdeui/k3spell.cpp?view=markup

the static string "hspell" is used to invoke the hebrew speller, a
patch to replace this string with "multispell" will do the trick. But
if I was the maintainer of this backward support code I will not want
to touch it.

> > problem will not exist anymore, and multi lingual spelling will not be
> > possible at all.
> Why is that?

sonnet (for kde) and enchant (for gnome) use one language code string,
e.g. he_IL, ar_JR, en_US to tell the speller what language to use. If
the Hebrew  speller need two language codes, e.g. he_IL:en_US its a
big change in the speller data structures and overall thinking.
http://websvn.kde.org/trunk/KDE/kdelibs/sonnet/plugins/

We can re-write libhspell to do multispelling or we can re-write the
hspell kde_client to use both hspell and aspell, but this is very bad
programing :-( . It is bad because it will ignore the dictionary
contractor variable gchar *language (in enchnat) and QString &language
(in sonnet).

To fix that we will need to ask the authors of sonnet and enchant to
use a list of languages for each document, and not just one language
per document, this is a big step in speller thinking, and I think the
world(*) is not ready for it :-) .

(*) authors of sonnet and enchant

Kobi