-
Notifications
You must be signed in to change notification settings - Fork 10
I18n
Zephyr's concession to internationalization basically consists of declaring character sets.
Version 3.0 adds two new header fields, the second of which is a 16-bit number (kind of a waste really), that represents the MibEnum number of a character set. (Go look it up at IANA.ORG). In practice this MUST be either 0 (for Unspecified), 4 for ISO-8859-1 (The defacto standard in most current zephyr usage), or 106 for UTF-8 (the only reasonable thing going forward if the payload is representing text).
zwrite and zaway now have a -x option for specifying the outgoing character set.
zwgc should get a similar option. At the moment, it merely sticks a variable charset into the zwgc.desc context. That variable should be called notice_charset, and the deduced tty output charset should be in a variable called tty_charset, will of course be overridable by zwgc.desc. Tty output will be transliterated from notice_charset to tty_charset. (#5)
For now, the X11 driver will just transliterate from notice_charset to 8859-1. #6) It occurs to me, though that the right thing to do may be to transliterate to the encoding of the current font, if easily available. (I know it's in the BDF and the name, but I don't know how easy it is to get it into a form that can be fed to iconv().
(It would be nice if it just displayed wide characters, and there is a patch in the works for that, but given the available free time of the various people working on it, I'm not making any bets. (Work-in-progress patch link copied to #33.)
These conversion points are obviously kludgy, they would be less so if strings in zwgc.desc land could be seamlessly multibyte. (#10) I'm currently thinking that the right approach is to make everything expect UTF-8 and convert all strings to UTF-8 when they enter zwgc.