On Friday, May 3, 2002, at 04:33 , Roman Vasicek wrote: >> On Friday, May 3, 2002, at 02:41 , Dan Kogai wrote: >> >> I have just released Encode-InCharset-0.01, available as >> >> http://www.dan.co.jp/~dankogai/Encode-InCharset-0.01.tar.gz and CPAN. >> >> I have developed this module primarily to implement ISO-2022-JP-3 and >> ISO-2022-CN in future. To implement encode() in these, you have to >> know which character set a given character belongs. But this module >> can also be used if a string can safely be encoded >> (Though fallback is much faster). >> > Great! Good work. > > I have one, may be off topic question. Is there module which provide the > same functionality for languages? I mean something like IsGerman, > IsCzech, > etc.
Be our guest ;) To my knowledge there is none but it won't be too hard to implement -- for Roman script languages. You just start with ISO_8599 variants and subtract the ones you don't need. I consider this be one of the problems of Unicode (as of now). When you aggregate anything, usually the source of origin is lost. It is just the same as you can't retrieve 1+1 back from 2 (it could be 0+2 or -1+3 or anything). To overcome this shortage Unicode does have character properties and you can get which I<script> it belongs to using that. But unfortunately that was not the case for the origins of character repertoire (so I made one (Encode-InCharset) because I needed it). Neither is the case for Languages. Maybe Encode-InCharset-0.01 can help implement InLanguage, especially for complex CJK cases. Here is a crude (and possibly incorrect) definition of InNihongo; $InNihongo =~ qr/(?= \p{InJISX0213_1} | \p{InJISX0213_2} | \p{InASCII} ) (?: \p{Hiragana} | \p{Katakana} | \p{Han} | \p{InBasicLatin} | # contemporary! )/xo; Notice it is prepended by InJISX0213_1 and InJISX0213_2. Otherwise all Han Ideographs that are not used in Japanese will also be considered Nihongo. Dan the Encode Maintainer