[9front] ctrans - Chinese language input for Plan9

[9front] ctrans - Chinese language input for Plan9

[smj]

With the recent commit of 'ktrans' to 9front, SDF boot camper 'ldb' as taken the
idea and created 'ctrans' https://9p.sdf.org/who/ldb

As Kenji Okamoto has pointed out, 'ktrans' would be difficult to extend to 
Chinese due to the massive number of characters necessary.  While Japanese can
get away with ~2500 daily use characters, Chinese requires quite a bit more. 
The advantage in Japanese is that there are two other writing alphabets which are
purely phonetic and useful for importing foreign words.

ldb's 'ctrans' had to take the 'ktrans' idea and optimize it a bit more to support
20,000 characters.  The result is a mechanism that more or less behaves like ktrans
but is quick (even over drawterm) to cycle through character lists.

moody has seen this work and it has been an inspiration to adapt to 'ktrans' for
even faster Kanji look up which could allow for more esoteric Kanji to be added.

In addition a new font 'HanaMinA' has been adapted which beautifully supports both
Japanese and Chinese characters and it is what we recommend folks use on 9p.sdf.org.

Thank you ldb for your great work!

ldb, お疲れ様です!

smj

Re: [9front] ctrans - Chinese language input for Plan9

[Jacob Moody]

On 7/19/22 21:19, smj@9p.sdf.org wrote:
> With the recent commit of 'ktrans' to 9front, SDF boot camper 'ldb' as taken the
> idea and created 'ctrans' https://9p.sdf.org/who/ldb
> 
> As Kenji Okamoto has pointed out, 'ktrans' would be difficult to extend to 
> Chinese due to the massive number of characters necessary.  While Japanese can
> get away with ~2500 daily use characters, Chinese requires quite a bit more. 
> The advantage in Japanese is that there are two other writing alphabets which are
> purely phonetic and useful for importing foreign words.
> 
> ldb's 'ctrans' had to take the 'ktrans' idea and optimize it a bit more to support
> 20,000 characters.  The result is a mechanism that more or less behaves like ktrans
> but is quick (even over drawterm) to cycle through character lists.
> 
> moody has seen this work and it has been an inspiration to adapt to 'ktrans' for
> even faster Kanji look up which could allow for more esoteric Kanji to be added.

After the discussion I had with ldb on cat-v, it became clear that there would be
some performance issues when using ktrans for considerably larger character sets. My thought
was that this performance stuff was a bug and set off to work to make this better.
I consolidated the dictionary and mapping lookups to use the same base hash map structure
and that seems to have speed up things quite a bit for larger character maps.

With that being said, I did take a stab at Chinese support in ktrans. Currently
it is explicit lookup only; working as ktrans does for Kanji  vs
how it handles kana. But I am about the furthest thing away from native
Chinese speaker, so I can't say if what I cooked up is usable by any means.
I would love to learn how to make it more usable, it currently is in the a state
where it works convenient with the existing code but no reason it has to remain that
way.

I would love to keep proper support in the base system, and for that I think I would
prefer that it live in ktrans vs its own program. Lets make ktrans better instead of
duplicating the code elsewhere, is my thoughts mostly.I just want avoid programs
like these become a 'if you know, you know' thing like ktrans did floating out in the
ether.

I realize now that my eagerness may have come across like I was trying to step on some toes,
if that is the case I apologize, those were not my intentions.

> 
> In addition a new font 'HanaMinA' has been adapted which beautifully supports both
> Japanese and Chinese characters and it is what we recommend folks use on 9p.sdf.org.
> 

Post a diff, I would love to include this in the base system.

> Thank you ldb for your great work!
> 
Yes, thank you.

--
moody