2011-02-24 10:57, Harshula wrote:
> Perhaps you are confusing the m17n ispell module with the anthy module.
No, I am talking about Anthy module. Well, let me explain my background.
My native language is Japanese. I developed Egg v4 input method for
GNU Emacs around 1997, and enhanced it to support Anthy around 2001.
When I use Emacs, I use japanese-egg-anthy input method, and this is
mostly used. For Desktop, I have been using scim-anthy, but recently
moved to ibus-anthy.
Until last September (for approximately ten years), I was a colleague
of Ken'ichi Handa, who develops m17nlib. My first experience with him
was about 20 years ago, for enhancement of GNU Emacs. Yes, that's
also work to support multilingual text.
For Anthy, I managed to arrenge some fund for development of Anthy
around 2001, and have kept supporting its development since then. But
the development became mostly dead around 2007. Then, I decided
to maintain upstream anthy since last summer.
> m17n anthy is available to desktop users via IBus.
It is just available, like m17n-edit. But it is not for real use,
seriously. No one use that, except by accident. From viepoint of
Anthy, it is not recommended, because features supported by m17n Anthy
is minimum and not well integrated to desktop usage.
> anthy description:
> "Japanese input method with Anthy as a kana-kanji converter.
> Typed roma-ji is at first converted to Hiragana,
> and Space key converts the Hiragana sequences
> to Kanji-Hiragana mixed sequence."
IMHO, this description would be better to include:
This is a demonstration purpose (not for real use).
Since I'd understand some reason why m17n-lib has to claim "This
library support Japanese too", I don't say more.
> Upstream may move the libmimx-*.so out of m17n-lib into m17n-db.
> Discussions are still ongoing.
Good. Partly, I'd agree.
It makes sence to move m17n-lib modules/plugins out of m17n-lib and
put them, say, independent package, m17n-modules or something. It
would be decision by upstream, but this could be also done by package
maintainer independently.
It sounds somewhat odd to me to include modules into m17n-db, since
it is not data, but program.
If you will request upstream change for moving modules/plugins out of
m17n-lib, it would also make sence to suggest rename of modules. Name
starts by 'lib' would be better to be changed, as it is plugin module
dynamically loaded, not linked to executable at compile time.
If you will request upstream change for this matter, could you please
include me? That's easy way to communicate.
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
