> I'm still concerning what language should be used when the text attrib=
utes
> becomes mixed language, such as :"%%[PrinterError:Offending command whi=
le
> printing file ******.ps%%]" (please assume ***** as a Japanese kanji an=
ything
> you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be Englis=
h,
> Japanese, or we don't have to care??
I just want to point out that this is not just an 'ASIAN language'
issue.
The content-language attribute of a string is used for a variety
of purposes, such as determining hyphenation (German and French
and English hyphenate differently), as an aid in text-to-speech
translation, as well as a way of controlling presentation (such
as might occur with Chinese and Japanese language strings.)
As you point out, simple text strings have no way to indicate
in-line language shifts. The same problem would occur, for example,
if a message were both in French and English, and was sent
to a text-to-speech processor without further annotation.
As you say, a technical solution (use HTML instead of text)
might well be to allow additional markup, the cost of supporting
that markup for simple strings returned from printer errors
might be higher than we want to impose on simple clients.
> But the problem still remains, especially for describing human names or=
> name of places. We have to know EXCACTLY CORRECT kanjis to identify the=
> particular persons/places, mostly because historical reasons.
Most of the discussions I've seen on this issue (on many mailing lists)
have actually petered out because there has never been a realistic
example submitted; the issue seems to be theoretical and political rather=
than practical. For example, do you actually have a client that
supports both renderings of characters that would otherwise be
ambiguous, and scenerio in which the difference matters, or is it
just a theoretical matter?
Martin Duerst, Martin D=FCrst, which one do you mean? But of course, he
puts up with being mis-identified.
Larry
-- =
http://www.parc.xerox.com/masinter