> * 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
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message