Re: Context in translations, Q_() and gettext

[F Wolff <friedel translate org za>]

I'm just lurking on the list and can't really comment on all things, but
I'll comment on the wordforge tools. (Pootle, Pootling and the translate
toolkit)

Op Sondag 08-07-2007 om 22:18 uur [tijdzone -0400], schreef Matthias
Clasen:
> GLib offers the Q_() macro for adding context to translations, but 
> the solution of embedding the context into the msgid is error-prone 
> for translators and can lead to regular msgids being misinterpreted 
> as having a context. 
> 
> When this was last discussed on this list 1 1/2 years ago, there
> seemed to be consensus that a solution that keeps context and msgid
> separate is preferable. Since then, GNU gettext has added support 
> for this in the form of msgctxt, which has been available in gettext
> 0.15 for a year now. 
> 
> I'd like to add support for separate message context to the next 
> GLib release (i.e. not 2.14, which is almost done), in the form of 
> a C_(Context,Msgid) macro. An implementation of this can be found
> in http://bugzilla.gnome.org/show_bug.cgi?id=142676 . The patch
> also modifies the Q_() macro so that it can keep working even if
> the contexts in .po files are converted to msgctxt (xgettext can
> do this automatically)
> 
> There is a number of questions that I'd like to find answers for
> before we decide to push for adoption of msgctxt:
> 
> - Have the translation tools caught up with msgctxt yet, or will
>   msgctxt cause problems for translators ?

Pootle 1.0 and the translate toolkit 1.0 have support for msgctxt.
Pootle will display the context in the same way as it handles KDE style
msgid comments by displaying it close to the source string. We have not
exhaustively tested our merging code and all the tools where the context
might play a role, but we do support it in the file format and at least
some of the tools.

> 
> - Will it be a big problem for people using alternative gettext
>   implementations if msgctxt starts to appear in .po files ? 
>   Do we need to provide a script to "fold back" msgctxt into 
>   msgid prefixes, for use with old msgfmt implementations, 
>   or can we expect everybody to use GNU gettext for creating 
>   .mo files ? 

We already handle it, and some of the tools in the toolkit might just
ignore it instead of breaking. It shouldn't normally create big
problems, I would say. Our current pocompile (msgfmt equivalent) doesn't
handle it yet (it will create .mo files without the context part), but
support for it is already committed in SVN and will form part of the
next release of the toolkit (1.1).

> 
> - How can we handle existing translations when context moves
>   from the msgid to msgctxt ? 
>   Does msgmerge handle this intelligently, or do we need some 
>   conversion script ?

The translate toolkit is written in Python, it might easy to write such
a conversion script based on our current pot2po tool by just
manipulating the data before the normal matching. (pot2po is our
equivalent to msgmerge)

http://translate.sourceforge.net/wiki/toolkit/pot2po

> 
> - Can we make the transition from Q_() to C_() smoother ? 
>   Unfortunately, xgettext does not provide a way to extract
>   strings from a 2-argument macro like C_() to msgid-prefix
>   form.
> 
...


I would suggest that we schedule a bug day where people can try out all
the combinations of features and tools that they can think of. This way
we might be able to make good progress in a single day and build a base
of test files with wide variety.

The upcoming release of Pootling (version 0.2) relies on translate
toolkit 1.0 and will support msgctxt as well.