[Kbabel] Fwd: Re: [Translation-i18n] Context, disambiguation, translator info

[Stanislav Visnovsky]

FYI

----------  Preposlaná správa  ----------

Subject: Re: [Translation-i18n] Context, disambiguation, translator info
Date: Streda 12 Október 2005 12:46
From: Bruno Haible <bruno at clisp.org>
To: Danilo Segan <dsegan at gmx.net>
Cc: Danilo Segan <dsegan at gmx.net>, Clytie Siddall <clytie at riverland.net.au>, 
translation-i18n at lists.sourceforge.net, Matthias Kiefer <kiefer at kde.org>, 
Stanislav Visnovsky <visnovsky at kde.org>

Hi Danilo,

> optional
> dependency on eg. libxml2 (it would be trivial with that, and not so
> trivial without any existing XML parser).

libxml2 is among the "minimal" set of packages of today's Linux
distributions. Therefore it is OK to make the gettext tools depend on it.
Of course, for the sake of other platforms, use a #if like this:
   #if HAVE_LIBXML2
     ...
   #else
     error (EXIT_FAILURE, 0, _("\
this functionality requires libxml2, but libxml2 was not present when gettext
 was built")); #endif

> Of course, I agree that Chusslove's solution is more elegant and
> nicer.

Good. Following the statements from Clytie and from you, I've now added
context support to GNU gettext. The NEWS entry says:

* GUI program support:
  - PO files can now contain messages constrained to a certain context.
    Most often such a context is a menu, dialog or panel identification.
    The syntax in the PO file is
      msgctxt "context"
      msgid "original"
      msgstr "translation"
  - The xgettext program can be told through the --keyword flag which
    function/macro argument has the role of a context.
  - The (non-public) include file gettext.h defines macros pgettext,
 dpgettext etc. that take a context argument.
  For more information, see the node "Contexts" in the manual.

> > At the beginning of this thread, Clytie explained that with this kind of
> > syntax, average translators don't understand that they should translate
> > only the part after the "|". I believe that the presence of
> > "#, has-context" will not change much about this, and that
> >
> >   msgctxt "Blah blah"
> >   msgid "Hello World"
> >   msgstr ""
> >
> > is more intuitive to understand.
>
> Actually, the problem is not that simple.  Clytie, just as most
> other translators, is using GUI tool to edit a translation.  "#,
> has-context" and "Context-Descriptor" was there to help such tools
> display this in a more intuitive way.  This is currently not possible,
> since there is technically no difference between "context|blah" and
> "the | operator".

The msgctxt indicator will "help the GUI tools" as much as
"#, has-context" or "Context-Descriptor" could do. Without the
limitation regarding "|".

> Those using simple text editors or Emacs po-mode shouldn't have too
> much problems adjusting, at least in my experience.  Hell, po-mode can
> be expanded as well to display it differently, to have C-j copy only
> the part after the context marker over to translation, etc.

Do you know a volunteer who is willing to hack po-mode?

> And the backwards compatibility is a big win, IMO.

Not so big as you think. For example, for kbabel, it would be a small change
in just two files to recognize the msgctxt keyword and transform it into a
comment, like they do for the Qt .ts/.qm format. Adding support for
msgctxt across entire kbabel is some more work. But supporting the keyword
msgctxt in a hackish way is something they can do rapidly.

> I know from experience of introducing ngettext() usage in Gnome (it
> took more than 2 years since introduction of ngettext() in GNU
> gettext, and it started only when I joined as Serbian translator)
> which met most of the resistance from maintainers and developers
> because of compatibility issues.  Translators are glad to update their
> tools to get better support for their work, while maintainers always
> worry about such "trivialities" such as build systems, portability,
> etc.  We are still getting occasional bug reports about intltool not
> working with non-GNU xgettext, even if we've been using --keyword for
> ages now.
> ...
> Eg. I know that we'll probably not be able to use a new context system
> in Gnome for at least the next two years.  And even then, it will be a
> big question how long will it take to introduce it everywhere.

This is actually an argument in favour of putting the feature into GNU
gettext as soon as possible, rather than delaying it. I did it now. So
you will have to wait 2 years until you can use it. If I had waited one
more month, you would have had to wait 2 years and a month. Etc.

> we can fix it now (i.e. what I am proposing is a shift
> in metadata support, while the data stays the same: because there was
> no uniform behaviour, everybody designed their own, so lets support
> them all with a *very simple* mechanism, IMO).

Supporting the existing KDE or Gnome syntax wouldn't solve the major
problem that Clytie mentioned: that most translators don't understand
that they have to strip the context from the msgstr.

> You are forgetting about all the other PO tools as well.  These are
> exactly the big wins of PO format, because GNU gettext is not the only
> set of tools to work with them.

You are right that there are a lot of other tools. But they will have
to upgrade. Things are interdependent and intertwined, but that must not
cause a freeze in the overall functionality.

> I've recently written direct MO reader which I plan to commit to CVS soon

Does it support the various revisions of the .mo file format, like
gettext-tools/src/read-mo.c does? Does it support the way contexts are
now stored in .mo files?

Bruno

-------------------------------------------------------