"Jon M. Taylor" wrote:
> * Method 0: Romanji (sp?). Standard Roman character input.
> * Method 1: Key-per-Hiragana-character. Hiragana is a native Japanese
> phonetic alphabet, with each key/modifier mapped in a similar manner to
> roman alphabets. Fairly easy to handle.
> * Method 2: Key-per-Katakana-character. Another(!) native Japanese
> phonetic alphabet, used with foreign words. Just needs another
> key/modifier lookup table. Also fairly easy to handle.
> * Method 3: Inline contextualized phoneme-set-to-Kanji-grammar based
> lookup (!!!). This is the hard one. This is what Andy was referring to
> below, and it is _wierd_. Essentially it works as follows:
> 1: You use the Hiragana or Katakana(?) alphabet to enter a string of
> phonemes which comprise a _spoken_ Kanji syllable. Each syllabic Kanji
> can be composed of 1, 2, 3 or sometimes 4 phonemes. You then need a way
> to tell the software side that you are finished entering your Kanji
> syllable, which on Japanese Windows is done by hitting the spacebar. So:
> Hiragana 'Z' phoneme +
> Hiragana 'e' phoneme +
> Hiragana 'n' phoneme +
> Spacebar =
> 'Zen' Kanji syllabic glyph.
> I *think* that this stage can be handled with a simple keypress
> accumulator and table lookup.
ok. Do you think that this accumulation is something gii should handle ?
I mean, it would certainly be clean to just expose the unicode once it is
completed. Then the client would only see one single key press even though
there were quite a couple.
The alternative is that berlin handles this internally. However, I think it
would be coherent with the rest if it would already be done. key to unicode
mapping is handled outside as you told me so I would assume that this is a
> 2: Now that we have a way to turn phonemic Katakana or Hiragana into Kanji
> syllables, we next need a way to turn the Kanji syllables into higher
> level conceptually-mapped Kanji glyphs or glyph strings ("words"). As
Do you really mean Glyph ? I assume you know that the charater <-> glyph
mapping is quite complex. So I would assume the syllables to be mapped to
characters, not glyphs.
> Nice, eh? The unfortunate truth is that this crazy input system
> is pretty much required, due to the highly contextualized nature of the
> Japanese language. The Kanji for 'Zen' (for example) can have over 20
> completely different meanings when used in different grammatical contexts.
> Unless you keep track of the running context, it is impossible to
> accurately translate subsequently entered Kanji syllables into Kanji
> words. This more or less requires a full Japanese grammar engine be
> embedded into the input protocol itself |-/.
since this seems indeed to be very complex, might I suggest that we handle this
inside berlin ? This way, we could define ourself helper applets which present
contextual help for composing text. This would be extremely difficult on a lower
> Luckily, although this is all quite complex, I do not think it
> impossible. One or more LibGII translation modules will need to sit in
> the input stream and perform the various translation steps, wile also
> sending events back and forth to the higher-level LibGGI code which
> handles the display updating, highlighting, autocompetion, etc. And I
> would be surprised if there were not already some open source code
> Japanese grammar engine code out there, give how much has been done
> already WRT Japanese locale support.
ok. This would be a different approach. For us, however, this would require
a more tight coupling between GII and berlin. berlin would essentially need to
install callbacks into gii so that the desired functionality would be achieved
by cooperation. I think handling this exclusively in berlin is by far the easiest.
> My knowledge is secondhand, but Mitch (my roomate) knows all of
> this quite well, so I can quickly find out whatever I do not already know.
> Let me know if I can be of further help to anyone here.
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
...ich hab' noch einen Koffer in Berlin...