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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]