[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] error message in other language
- From: Tim Van Holder <tim vanholder anubex com>
- To: veillard redhat com
- Cc: xml gnome org
- Subject: Re: [xml] error message in other language
- Date: Mon, 17 Jul 2006 08:28:54 +0200
Daniel Veillard wrote:
> On Tue, Jul 11, 2006 at 02:51:10PM +0200, Anne Müller wrote:
>> Hi,
>>
>> I have an xmlErrorPtr error.
>>
>> I want to show error messages (error->message) like
>>
>> “Element p is not declared in span list of possible children”.
>>
>> It works fine but I need this message in German. Has anybody an idea how
>> this could work?
>
> Hum, not trivial, you would need to look at the exact error numbers
> and depending on the error either rebuild a localized error based on the
> extra inforamtions given, or apply a transformation to the string (based
> for example on sscanf/sprintf)
>
> Daniel
I'd suggest filing a bugzilla entry for i18n of libxml; there's no good
reason why it shouldn't be gettextized.
Of course, once that's done, someone will still have to do the German
translations - but translating a message catalog is much much easier
than trying to parse the English error messages and replacing them with
German ones.
As for Daniel's reservations (cfr.
http://mail.gnome.org/archives/xml/2003-April/msg00048.html):
- if current messages are not intended for users, then they should not
be the primary error information; instead, error codes would have to
be used, with a default error handler that emits a not-user-oriented
message based on that. Requiring callers to parse textual errors in
order to provide meaningful messages to the user is not a great
design (and that is what I take it you mean when you speak of an
"interpretation layer"). Also, there is something to be said for
standardized error messages - why would it be a good idea for every
program to have its own wording for an error when it's the same
libxml2 error at the basis?
- Various localization mechanisms? Add support for gettext, and you
cover a wide range of platforms; those without gettext support simply
get English messages as before. This approach is used by many, many
open source programs (including many parts of Gome).
- A lot of work? I'd have to dig through the code, but as long as
messages are created/emitted using *printf-style functions, it would
be very little work to instrument existing code for gettext use (just
add _() around translatable strings, and define _(message) to expand
to dgettext("libxml2", message). xgettext will then easily be able
to extract the message catalog.
=> so I see it as a relatively small amount of work, with the benefit
of standardized and fully localized error messages
*runs away before Daniel can grab me and force me to provide a patch*
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]