Re: off-topic? [was Re: Examples of translated RFCs]
JFC (Jefsey) Morfin jefsey at jefsey dot com wrote: you say you imagine the following exchange is off-topic for IETF. Please reread the RFC 3066 bis, and your own accompanying proposed registry accepted by the IESG after the Tunis deal. And reread RFC 3935. _You_ trapped the IETF in pretending it is competent in matter of language identification, language tagging, script issues, national lingual policies, etc. to the point to take the world leadership (and the RFC 3935 accompanying responsibilities) with the mission to influence people to design, use and manage the Internet in that area. It has already been explained countless times, for those who care to read and understand, that neither RFC 3066bis nor its predecessors RFC 3066 and 1766 establishes the IETF as a linguistic authority. It establishes a mechanism by which the language in which content is expressed can be identified. Masataka Ohta does not discuss an ISO matter. He discusses an IETF langtag issue. Ohta and I are never going to agree on this Han unification issue, but at least I suspect he understands that it is not an IETF langtag issue. It is nothing of the sort. It is a dispute over the design of ISO 10646. You know, not everything that anyone ever says can be twisted into an argument against RFC 3066bis. So, I will appeal to the IAB to get a final guidance. What a dismal life you must lead, if your only joy is in tearing down the work of others. Anyone who wants to know what RFC 3066bis is really about is invited to read it themselves: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt I will not waste further keystrokes on this. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: off-topic? [was Re: Examples of translated RFCs]
Doug Ewell wrote: Ohta and I are never going to agree on this Han unification issue, but at least I suspect he understands that it is not an IETF langtag issue. It is nothing of the sort. It is a dispute over the design of ISO 10646. What a poor understanding on the internatinalization. RFC 3066 is incorrect to state (despite my counter arguments with counter examples): The issue of deciding upon the rendering of a character set based on the language tag is not addressed in this memo; however, it is thought impossible to make such a decision correctly for all cases unless means of switching language in the middle of a text are defined (for example, a rendering engine that decides font based on Japanese or Chinese language may produce suboptimal output when a mixed Japanese-Chinese text is encountered) The reality is that tags for content language is orthogonal to charset. Japanese language can be expressed in ASCII as follows: Kore ha nihongo no bun desu. English language can be expressed Japanese characters. Just like that, Japanese language can be expressed in Chinese characters, Chinese language can be expressed in Japanese characters. So, language tag does not help to make such a decision correctly at all, even if means of switching language in the middle of a text are defined It is a plain fact of life not affected by IETF, though Harald has been ignoring only to make text processing complex for any good purpose. Anyone who wants to know what RFC 3066bis is really about is invited to read it themselves: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt It is as bad as 3066. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Doug Ewell wrote: I can't print Japanese characters in China where Chinese-style glyphs are used by default. No, you can't print Japanese *glyphs* in that situation. That's bad enough. Remember that the I-D file formats and internationalization thread was initiated by Robert Sayre with the following statement: : Unicode support is a different matter. I find the current IETF policy : to be incredibly bigoted. Many RFCs and I-Ds are currently forced to : misspell the names of authors and contributors, which doesn't seem : like correct attribution to me. Characters and glyphs are not the same thing. Tweaking definitions on Characters does not change the reality. PERIOD. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Masataka Ohta wrote: most native users of Latin alphabet can read Greek alphabet I don't think so, s/Latin/Cyril/ maybe ? Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
off-topic? [was Re: Examples of translated RFCs]
Doug, you say you imagine the following exchange is off-topic for IETF. Please reread the RFC 3066 bis, and your own accompanying proposed registry accepted by the IESG after the Tunis deal. And reread RFC 3935. _You_ trapped the IETF in pretending it is competent in matter of language identification, language tagging, script issues, national lingual policies, etc. to the point to take the world leadership (and the RFC 3935 accompanying responsibilities) with the mission to influence people to design, use and manage the Internet in that area. And now you come and say this is off-topic? Obviously it WAS off-topic. But you made it a core topic for the IETF. Saying it is off-topic now will not address it. I was interested in knowing how you are going to assume it. Now we start understanding. Masataka Ohta does not discuss an ISO matter. He discusses an IETF langtag issue. I fully agree the IETF does not count the expertise and cross-expertise, and most probably the interest, necessary to seriously discuss IETF langtags. Nevertheless every IETF langtag issue is now going to escalate to this mailing list, the IESG and ulitmately to the IAB as the self-assumed world's authority on the matter. I used the appeal now in limbo to make the IESG clarify their (your) contradictory position. I feel that a community having a problem to decide between ASCII Courier and ASCII PDF/A for its own use may not be very excited about deciding for the world how to best support kanji and hanzi, etc. jfc At 08:46 07/12/2005, Doug Ewell wrote: Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: since most computers sold all over the world now come with at least one perfectly good Unicode-based font with Chinese-style glyphs and another with Japanese-style glyphs. Now, you admit that the problem does exist. I admit there are stylistic differences between the way the *same characters* are written in the Chinese and Japanese traditions. Anyone who knows about East Asian writing knows that. I do not admit there is a problem with unifying them in a character-based (not glyph-based) encoding. I can't print Japanese characters in China where Chinese-style glyphs are used by default. No, you can't print Japanese *glyphs* in that situation. Characters and glyphs are not the same thing. With both Chinese and Japanese glyphs are available, ISO 2022 works perfectly fine with corresponding Chinese and Japanese character sets. On the other hand, language tags are useless from the beginning to distinguish characters. One can represent some content in Japanese language by ASCII, Japanese characters or Chinese characters. If you (or your software) can use the distinction between ISO 2022-JP and Big-5, or EUC-TW, or CNS 11643, or whatever to determine whether to display Japanese or Chinese glyphs, you (or your software) can do the same by using the distinction between ja and zh. If you can use ISO 2022 controls to switch between the Japanese repertoire and the Chinese repertoire, you can do the same with language tags. This is a question of style, not legibility. If you are sayingI'm not sure about thisthat the same Ie ISO 10646 code point needs to be displayed in both the Japanese and Chinese glyphic traditions in the same Japanese-langauge text, and that only ISO 2022 is adequate to indicate which glyphs to display, then I ask: how is this problem solved in handwritten text? I think you do your countrymen a disservice by claiming that they are incapable of reading kanji printed in a Chinese-style font. Red herring. Just as most native users of Latin alphabet can read Greek alphabet, most Japanese can read Chinese glyphs, which is not the point at all. Actually I think you are being too kind to most native users of the Latin alphabet. They can certainly read Greek Î', because the Latin A is derived from it. They might get terribly confused by Greek Î and Ρ and Χ, which are not equivalent to the Latin letters they resembleâunless, of course, they are familiar with the use of Greek letters in professional or fraternal organizations, which is its own red herring. Most scholars of writing systems disagree with your premise that Chinese hanzi and Japanese kanji are two separate writing systems in the same way that Latin and Greek are separate. Latin and Greek are not simply glyph variants of one another. You should admit that ISO 10646 useless for internationalization. I do not. ISO 10646 is a cornerstone of modern software internationalization. I imagine this is off-topic for IETF. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
i had RFC-1984 translated into French just after it appeared. served me well for several discussions in France at the time in which I was involved (as an IAB member at the time). No normative references, but translating it to get the point accross with some politicians helped. Erik --On dinsdag 6 december 2005 9:33 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Check this site out: http://rfc-jp.nic.ad.jp/ I *think* it has at least a handful of RFCs translated into Japanese, but my Japanese skills aren't great enough to know if I found the ones that are there. There's also http://www.rfc-editor.org/language.html, with links to Spanish and French translation indexes. Others will have to say if the result has been useful to someone or not; if I read the tea leaves correctly, none have translated more than 100 RFCs. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
On Dec 6, 2005, at 10:56 PM, Masataka Ohta wrote: You should admit that ISO 10646 useless for internationalization. Hogwash. Which is to say, for the benefit of those who have not had to internalize the complicated world of standardization and internationalization: Mr. Ohta's point of view represents the position of a tiny minority; huge swathes of widely-deployed standards and technology rely totally on 10646/Unicode, and they tend to work well, and they tend to deliver high-quality experiences to their users, including Japanese users. -Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Tim Bray wrote: So, you gave up on technical points. OK. Which is to say, for the benefit of those who have not had to internalize the complicated world of standardization and internationalization: Mr. Ohta's point of view represents the position of a tiny minority; huge swathes of widely-deployed standards and technology rely totally on 10646/Unicode, and they tend to work well, and they tend to deliver high-quality experiences to their users, including Japanese users. -Tim I know. Read RFC1815. I wrote it to demonstrate Unicode usable for some local purpose, though it is unrelated to internationalization. As a random collection of local characters, Unicode, in theory, works in any such local environment including Japanese one. However, people with established existing local schemes, including Japanese, keep using them, because Unicode is no better and the existing local schemes are more efficient. There is no point to some form of local version of Unicode, as we must specify which local version we are using. RFC1815 gives examples of such local versions. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
At 09:33 06/12/2005, Harald Tveit Alvestrand wrote: Check this site out: http://rfc-jp.nic.ad.jp/ I *think* it has at least a handful of RFCs translated into Japanese, but my Japanese skills aren't great enough to know if I found the ones that are there. There's also http://www.rfc-editor.org/language.html, with links to Spanish and French translation indexes. Others will have to say if the result has been useful to someone or not; if I read the tea leaves correctly, none have translated more than 100 RFCs. Harald, there is not a big need of translating RFC from English to other languages at the present time, people interested in RFC having some English, except for teaching purposes. As using the smallest charset RFC have limited translation problems (except when being political and an English term meeting cultural context translation problems). Also, RFCs describe the ASCII English Internet and many times need to be in English. The W3C document http://www.w3.org/International/questions/qa-i18n and ICANN efforts in the IDN area show the Internet community current low level of analysis in term of multilingualisation/multiculturalisation. The pending response to my IESG appeal will say how/where the IESG wants to see this analysis and support be carried. So , IMHO, the IETF urgency is today the other way around: incorporating into RFC standards, practices or tables authoritatively written or thought in another language than English, or in English using normative non-ASCII art drafts or using term in a meaning foreign to the IETF. This way we see the language is not the main issue of the current debate. The issue is the authoritative quote in community A a community B's, or of a searcher C's, normative document - while community A presents its documents in a different way - whithout affecting its normative capacity. This problem occurs when referencing in an RFC an ISO document as normative. The first issues being to write its URL properly if it includes non-ASCII characters, to properly name the authors and the references, to properly quote its copyright mentions and not to violate any law. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
JFC (Jefsey) Morfin wrote: I *think* it has at least a handful of RFCs translated into Japanese, but my Japanese skills aren't great enough to know if I found the ones that are there. There's also http://www.rfc-editor.org/language.html, with links to Spanish and French translation indexes. Others will have to say if the result has been useful to someone or not; if I read the tea leaves correctly, none have translated more than 100 RFCs. Harald, there is not a big need of translating RFC from English to other languages at the present time, people interested in RFC having some English, except for teaching purposes. Wrong. There are a lot of needs and many RFCs and even many IDs translated into Japanese. See not only a JPNIC site but also volunteer ones, say: http://www.imasy.or.jp/~masaka/rfc-jp/ However, to honor RFC and ID authers, there is no point to include their names in European or other international characters, because most readers of Japanes-translated RFCs can't recognize them. Though some people with Euro-local insights can't distinguish inter-europeanization and internationalization, many people can't recognize Euro-local non-ASCII latin characters. Very few people, if any, recognize all the characters in the world. So, the names in translated RFCs should remain in ASCII or be transliterated into Japanese local characters. In either case, we don't need Unicode. Note that major charsets used in Japan are ISO-2022-JP, EUC-JP, Shift JIS but definitely not any variant of Unicode. So, for localized RFCs, that is, translated RFCs, local character sets, which are often super set of ASCII, are just enough. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Examples of translated RFCs
JFC (Jefsey) Morfin writes... So , IMHO, the IETF urgency is today the other way around: incorporating into RFC standards, practices or tables authoritatively written or thought in another language than English, or in English using normative non-ASCII art drafts or using term in a meaning foreign to the IETF. If all RFCs are written in English, basically so that there is at most one additional language in which one must be fluent to understand and implement the protocols described therein, wouldn't it defeat the purpose to have normative references written in other languages? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Examples of translated RFCs
See below... -- -Original Message- -- From: Gray, Eric -- Sent: Tuesday, December 06, 2005 11:04 AM -- To: 'Nelson, David' -- Cc: ietf@ietf.org -- Subject: RE: Examples of translated RFCs -- -- David, -- -- Never-the-less, it can happen. Normative references - -- at least by some definitions of the term - can be to types -- of documents than RFCs. -- s/documents than/documents other than/ -- However, it is usually the case that papers and other -- documents written in French, Russian, German, etc. are made -- available in - or can be made available in - English for -- use in references from documents written in English. -- -- This is - indeed - the reason why the IETF allows for -- translations of RFCs: so that they can, in turn, be used as -- references in documents written in other languages. -- -- -- -- Eric -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Nelson, David -- -- Sent: Tuesday, December 06, 2005 10:55 AM -- -- To: ietf@ietf.org -- -- Subject: RE: Examples of translated RFCs -- -- -- -- JFC (Jefsey) Morfin writes... -- -- -- -- So , IMHO, the IETF urgency is today the other way around: -- -- incorporating into RFC standards, practices or tables -- -- authoritatively -- -- written or thought in another language than English, -- or in English -- -- using normative non-ASCII art drafts or using term in -- a meaning -- -- foreign to the IETF. -- -- -- -- If all RFCs are written in English, basically so that there -- -- is at most -- -- one additional language in which one must be fluent to -- -- understand and -- -- implement the protocols described therein, wouldn't it -- defeat the -- -- purpose to have normative references written in other languages? -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Examples of translated RFCs
David, Never-the-less, it can happen. Normative references - at least by some definitions of the term - can be to types of documents than RFCs. However, it is usually the case that papers and other documents written in French, Russian, German, etc. are made available in - or can be made available in - English for use in references from documents written in English. This is - indeed - the reason why the IETF allows for translations of RFCs: so that they can, in turn, be used as references in documents written in other languages. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Nelson, David -- Sent: Tuesday, December 06, 2005 10:55 AM -- To: ietf@ietf.org -- Subject: RE: Examples of translated RFCs -- -- JFC (Jefsey) Morfin writes... -- -- So , IMHO, the IETF urgency is today the other way around: -- incorporating into RFC standards, practices or tables -- authoritatively -- written or thought in another language than English, or in English -- using normative non-ASCII art drafts or using term in a meaning -- foreign to the IETF. -- -- If all RFCs are written in English, basically so that there -- is at most -- one additional language in which one must be fluent to -- understand and -- implement the protocols described therein, wouldn't it defeat the -- purpose to have normative references written in other languages? -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Examples of translated RFCs
At 16:55 06/12/2005, Nelson, David wrote: JFC (Jefsey) Morfin writes... So , IMHO, the IETF urgency is today the other way around: incorporating into RFC standards, practices or tables authoritatively written or thought in another language than English, or in English using normative non-ASCII art drafts or using term in a meaning foreign to the IETF. If all RFCs are written in English, basically so that there is at most one additional language in which one must be fluent to understand and implement the protocols described therein, wouldn't it defeat the purpose to have normative references written in other languages? Dear Nelson, with all due respect, you may have noted that there are around 20.000 stable acknowldged language entities in the world (actually far more) and quite a few SSDOs. Only the IETF uses English ASCII Courier typing for its texts and Arts. This means that statistically a normative idea for the Internet has 90% chance to be eventually thought or initially written in non English ASCII Courier typing and Arts. At the beginning 100% were in English ASCII Courier. Because the Internet was designed by English ASCII Courier people for English ASCII Courier applications. But the more we go, the more the advantage you quote becomes a barrier, as non English ASCII Courier people, applications, standards share into the Internet. This is why we have to reconsider it, to keep it as a blessing (as it does permit to have a pivot framework), but to stop it preventing innovation. It is a tool, not the architectural unilateral model and core value it has become. This is particularly urgent in BCPs. Because Network Managers and Law makers tend to write laws, rules and procedures in the user language rather than in a language they and the users do not understand. If you want to quote as authoritative a local procedure, you are to quote it in its language (and then you may translate it beniffiting from its authority). Not doing it is balkanizing the Internet; splitting the IETF English ASCII Courier Legacy Internet from the many various local Internets the IETF would create this way in being unable to support the world's multilingual reality. Globally, the world normative references are today 99,9 % not written in English ASCII Courier. And English is not necessarily the second language people have. By far and this will probably increase in the coming decades. I know it is hard to accept as an English speaker. But please remember that one century ago the decision taking world spoke French, the same as the technical world of today speaks English. We had to learn to live with the change: you will certainly will too ... and learn how rewarding this may be. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
At 12:41 06/12/2005, Masataka Ohta wrote: JFC (Jefsey) Morfin wrote: I *think* it has at least a handful of RFCs translated into Japanese, but my Japanese skills aren't great enough to know if I found the ones that are there. There's also http://www.rfc-editor.org/language.html, with links to Spanish and French translation indexes. Others will have to say if the result has been useful to someone or not; if I read the tea leaves correctly, none have translated more than 100 RFCs. Harald, there is not a big need of translating RFC from English to other languages at the present time, people interested in RFC having some English, except for teaching purposes. Wrong. There are a lot of needs and many RFCs and even many IDs translated into Japanese. I apologise if hurt your Japanese interest, I would certainly defend has I known them. I trusted the count made by Harald and the reports made by participants to this thread. However since I have no Japanase I have some difficulty to evaluate the real need/offering: on the site you quote there are some brokin links and the RFC numbers _seems_ to be low. May be will you want to consider the IANA request: If you are a host, or are aware of an RFC foreign language site, please send us e-mail with the appropriate URLs.? This would avoid this kind of mistake in the future. And may be help a complete directory of the translated documents. Thank you! jfc So, the names in translated RFCs should remain in ASCII or be transliterated into Japanese local characters. In either case, we don't need Unicode. Note that major charsets used in Japan are ISO-2022-JP, EUC-JP, Shift JIS but definitely not any variant of Unicode. PS. If everyone has the same need and solution, at the end of the day we need ISO 10646. What permits us to scale and print every where?. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
JFC (Jefsey) Morfin wrote: I apologise if hurt your Japanese interest, There is no need of apologize. May be will you want to consider the IANA request: If you are a host, or are aware of an RFC foreign language site, please send us e-mail with the appropriate URLs.? This would avoid this kind of mistake in the future. And may be help a complete directory of the translated documents. I have forwarded it to local ML. But, is it really IANA and not rfc-editor? PS. If everyone has the same need and solution, at the end of the day we need ISO 10646. In most cases, all you need is local variants of ISO 646. In Japan, we also need a multibyte character set and clever ways to combine ISO 646 and multibyte characters. Many days have passed since we got them and we are still using them. What permits us to scale and print every where?. Then, ISO 2022 is a lot more than enough. On the other hand, with ISO 10646, I can't print Japanese characters in China. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: On the other hand, with ISO 10646, I can't print Japanese characters in China. This is the same tired argument you have been advancing at least since RFC 1815, ten years ago, and it is no more true now than it was then -- even less so, in fact, since most computers sold all over the world now come with at least one perfectly good Unicode-based font with Chinese-style glyphs and another with Japanese-style glyphs. I understand you are not happy that Unicode and ISO 10646 chose to unify Chinese hanzi and Japanese kanji, but it is simply not accurate to say that you cannot print Japanese characters in China using ISO 10646. At worst, you are printing them in a culturally non-preferred font style. Considering the amazing stylistic varieties of kanji seen in Japanese advertising and pop culture, and the world-famous Japanese calligraphic tradition, I think you do your countrymen a disservice by claiming that they are incapable of reading kanji printed in a Chinese-style font. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Doug Ewell wrote: Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: at? dot? On the other hand, with ISO 10646, I can't print Japanese characters in China. since most computers sold all over the world now come with at least one perfectly good Unicode-based font with Chinese-style glyphs and another with Japanese-style glyphs. Now, you admit that the problem does exist. I can't print Japanese characters in China where Chinese-style glyphs are used by default. I can, of course, override the default by, for example, bringing my own computer, my own software or my own configuration. But it is not the point. With both Chinese and Japanese glyphs are available, ISO 2022 works perfectly fine with corresponding Chinese and Japanese character sets. On the other hand, language tags are useless from the beginning to distinguish characters. One can represent some content in Japanese language by ASCII, Japanese characters or Chinese characters. I think you do your countrymen a disservice by claiming that they are incapable of reading kanji printed in a Chinese-style font. Red herring. Just as most native users of Latin alphabet can read Greek alphabet, most Japanese can read Chinese glyphs, which is not the point at all. You should admit that ISO 10646 useless for internationalization. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Examples of translated RFCs
Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: at? dot? I tried to obfuscate your e-mail address from bots that search the Web-based archives. I do this to everyone. Sorry if it was confusing. since most computers sold all over the world now come with at least one perfectly good Unicode-based font with Chinese-style glyphs and another with Japanese-style glyphs. Now, you admit that the problem does exist. I admit there are stylistic differences between the way the *same characters* are written in the Chinese and Japanese traditions. Anyone who knows about East Asian writing knows that. I do not admit there is a problem with unifying them in a character-based (not glyph-based) encoding. I can't print Japanese characters in China where Chinese-style glyphs are used by default. No, you can't print Japanese *glyphs* in that situation. Characters and glyphs are not the same thing. With both Chinese and Japanese glyphs are available, ISO 2022 works perfectly fine with corresponding Chinese and Japanese character sets. On the other hand, language tags are useless from the beginning to distinguish characters. One can represent some content in Japanese language by ASCII, Japanese characters or Chinese characters. If you (or your software) can use the distinction between ISO 2022-JP and Big-5, or EUC-TW, or CNS 11643, or whatever to determine whether to display Japanese or Chinese glyphs, you (or your software) can do the same by using the distinction between ja and zh. If you can use ISO 2022 controls to switch between the Japanese repertoire and the Chinese repertoire, you can do the same with language tags. This is a question of style, not legibility. If you are saying—I'm not sure about this—that the same ISO 10646 code point needs to be displayed in both the Japanese and Chinese glyphic traditions in the same Japanese-langauge text, and that only ISO 2022 is adequate to indicate which glyphs to display, then I ask: how is this problem solved in handwritten text? I think you do your countrymen a disservice by claiming that they are incapable of reading kanji printed in a Chinese-style font. Red herring. Just as most native users of Latin alphabet can read Greek alphabet, most Japanese can read Chinese glyphs, which is not the point at all. Actually I think you are being too kind to most native users of the Latin alphabet. They can certainly read Greek Α, because the Latin A is derived from it. They might get terribly confused by Greek Η and Ρ and Χ, which are not equivalent to the Latin letters they resemble—unless, of course, they are familiar with the use of Greek letters in professional or fraternal organizations, which is its own red herring. Most scholars of writing systems disagree with your premise that Chinese hanzi and Japanese kanji are two separate writing systems in the same way that Latin and Greek are separate. Latin and Greek are not simply glyph variants of one another. You should admit that ISO 10646 useless for internationalization. I do not. ISO 10646 is a cornerstone of modern software internationalization. I imagine this is off-topic for IETF. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
