error message in other language

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

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillardredhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ |
Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

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/msg0004
8.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*


_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

On Mon, Jul 17, 2006 at 08:28:54AM +0200, Tim Van Holder
wrote:
> I'd suggest filing a bugzilla entry for i18n of
libxml; there's no good
> reason why it shouldn't be gettextized.

  There is one, I don't want to depend on gettext for
example on
Windows I don't force the dependancy, and on other
"exotic" like
embedded system I don't want anything to get in the way.
libxml2
only dependancies are a C compiler and a decent libc subset,
anything
else must be completely optional.

> 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/msg0004
8.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*

  And a patch which doesn't get in the way for those
without gettext()

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillardredhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ |
Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

Daniel Veillard wrote:
> On Mon, Jul 17, 2006 at 08:28:54AM +0200, Tim Van
Holder wrote:
>> I'd suggest filing a bugzilla entry for i18n of
libxml; there's no good
>> reason why it shouldn't be gettextized.
> 
>   There is one, I don't want to depend on gettext for
example on
> Windows I don't force the dependancy, and on other
"exotic" like
> embedded system I don't want anything to get in the
way. libxml2
> only dependancies are a C compiler and a decent libc
subset, anything
> else must be completely optional.

That's what the --disable-nls configure option (added by
gettext) is
for.  And I expect configure.ac can be set up so that it's
disabled by
default, and --enable-nls is required to activate it.  So
dependencies
are not really an issue (plus, gettextize adds a local copy
of libintl
to the source tree, so all necessary code would be included
in the
libxml2 tarball anyway).


_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml