Keld writes:
EvdP wrote:
Now, (as if that wasn't bad enough), we have the additional problem
that many Kanjis map to multiple pronunciations (mnemonics). For
example, the "Naka" above (K1), can also map to "Chuu", which varies
case by case, i.e. depending on the context.
It is right that the context is just one or two characters?
Yes, but the surrounding characters may depend on the surrounded
character.
I may have some 200.000 combinations of CJK characters that should
uniquely define words and meanings for CJK.
So email software should parse Japanese? This is not simple enough, in
my opinion.
Another question: would Naka1 not be associated with the right
CJK character?
No. The Japanese don't have any "Naka1" system, so they would not be
able to make the association.
I am of cause aware of the problems that Erik has described
and I am looking into providing something better than just gibberish
to unextended equipment. This is indeed hard for CJK.
I am humbly making a try on it.
But if this does not succed for CJK, would that lead to no solution
at all for laguages, where adequate solutions exist?
I would think that that would be a real pity.
I strongly agree with you here. I think that the mnemonic system is
extremely useful for European languages, and that its uselessness for
Japanese should not prevent it from being used elsewhere.
However, I am concerned about the email header solution, as I said.
Now, having said that Japanese text must be in a particular form of
ISO 2022 for it to be readable, I should also say that ISO 2022 cannot
be used in email headers, because it can contain unquoted special
characters like '<', '(', '"'. (And quoting would distort the
ideographic glyphs.)
Well, these things may be quoted.
No, the quoting would change the (Japanese) characters that you see.
Regards,
EvdP