Date: Thu, 19 Oct 2000 17:17:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: keichii@peorth.iteration.net Cc: i18n@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: I18N Progress, Plans, and Proposals Message-ID: <200010191717.KAA06915@usr08.primenet.com> In-Reply-To: <20001019033252.A31416@peorth.iteration.net> from "Michael C . Wu" at Oct 19, 2000 03:32:53 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> * Moving to message catalogue style error messages for the kernel and > userland. (AIX style) Each time the system outputs an error > either from the kernel or userland, the error message is a > formatted alphanumerica string mapped to verbose error messages. > The error messages can be mapped to various languages. > The advantages are : > A. Easy bug reporting by users. (e.g. "I have error 2398423") > B. I18N error messages > > The main disadvantage is that it will be a long term work > to maintain it and to keep error messages updated. I have a tool which uses a macro preprocessor and macros to do the majority of this work. It extracts messages from programs which have macro wrapped their I/O strings, and can automatically create XPG/4 message catalogs from them. I wrote this tool on my own time, but it has additions for supporting "ccat" (An InterJet specific non-XPG/4 locale data format). I could either rip these out, or leave them in, which might mean that I have to try to get Whistle's permission to release the code, if they consider the file format to be either proprietary or a trade secret. This is complicated by the fact that I haven't worked at Whistle/IBM for the last month. I can provide a version with the Whistle stuff ripped out in a week or so, if that's considered desirable, but would prefer to leave the code alone. Doing it this way will have a latency in however long it takes them to get back to me, though, so it might be better to burn the time to rip out the Whistle stuff. Right now, this preprocessor is only useful on code that has the ability to have functions or macros of the format "foo((...))", so it should work on C C+, Pascal, or Ada, but not much else. It doesn't recognize block "#idef OMIT" style omission, and it does not recognize C++ style comments, but I consider both of these to be features. Language support is easy to add, but requires that you have a simple language parser so that you can know the parse state when it sees a token that it likes (i.e. it nees to know what to ignore, and when). I applied this to Matt Dillon's public domain "BESTSERV" code in order to support Japanese, and it worked with no problems (but I had to add RFC2045 and RFC2047 to BESTSERV at the same time, so it's not too general an example of minimal changes). If it can't open the catalog file, it falls back to the strings specified in the code. Effectively, these are "C locale" strings, and you could then derive seperate "en_US" locales from them (and would, if you were smart, if you had UI people mucking with the contents of your strings for usability reasons). Let me know if there is any interest in the pre/post-processor code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010191717.KAA06915>