GNOME Goal: Migrate to msgctxt

Guidelines

Migrate all strings with context to use msgctxt instead. This is less error-prone for translators. Also, automated QA with something like pofilter will work better (this is a problem with the current in-message context markers).

GLib includes a patch which adds a 2 argument macro for translations with context combined with GNU gettext >= 0.15. So instead of writing Q_("context|id"), it is now possible to write C_("context", "id").

How does it affect translators?

In any po file, this means that instead of

it will contain

Most translation tools support msgctxt nowadays (kbabel, pootle, translate, launchpad). Poedit supports this from version 1.3.8, but not in a usable way (Aug 2008, see Tracker item 1 and 2). gtranslator also supports msgctxt. l10n.gnome.org runs gettext 0.16.1 (according to claude) and intltool-0.37.0, so there should not be any problems.

How to fix a module?

According to http://l10n.gnome.org/releases/gnome-2-22 the Spanish translation team has the most updated po files. running pcregrep -l 'msgid.*\|.*' ./*/po/es.po in your gnome svn checkout directory will print a list of modules that have a pipeline (|) in the msgid strings.

Fix any affected modules by replacing Q_("context|id") by C_("context", "id") in the affected source files. Note that if updating a string that was defined with N_(), you should use NC_() and this requires a few changes to the code when using the string. See the API documentation.

If you're daring, change the *.po files using a script such as the following:

for file in po/*.po; do sed -i "s+msgid \"\([^|]*\)|+msgctxt \"\1\"\nmsgid \"+" $file; done

Make sure you review the *.po files for accuracy after running this script -- it makes an assumption that any string with a "|" in it was to be used with the Q_ form. Also make sure to tell translators about you updating the po files on the gnome-i18n mailing list.

Python Specific Notes

• Replace your existing Q_ method definition with:

def C_(ctx, s):
    translated = gettext.gettext('%s\x04%s' % (ctx, s))
    if '\x04' in translated:
        # no translation found, return input string
        return s
    return translated

See the ad nauseum discussion at https://bugzilla.gnome.org/show_bug.cgi?id=569118.

Comments before approval

ChPe: Extraction of C_ strings needs intltool 0.36.3 or later (support for C_ was added in bug 499179). So I think we need to change configure.ac (resp. configure.in): replace IT_PROG_INTLTOOL([x]) with IT_PROG_INTLTOOL([0.36.3]) if x is less than 0.36.3.

ClaudeParoz: glib added support for NC_ macro (N_() equivalent for contextual strings) through bug 536996. We're waiting now for intltool to support C_ and NC_ macros. It seems that C_ support introduced in 0.36.3 was broken (see bug 543665).

• TommiVainikainen: From ChangeLog, first released intltool version where the bug was fixed was 0.40.1. And for glib support, first devel version was 2.17.4 meaning first stable release with support for C_ and NC_ was 2.18.0.

PetrKovar: As of Aug 2008, Poedit, likely being used by many GNOME translators, doesn't have UI support for displaying msgctxt (in any form) yet, i.e. translator can't be aware of msgctxt lines being used in a template/catalog. This should be taken in account when preparing for migration. See also thread #1 and #2 on the gnome-i18n mailing list.

ChristianRose: Not sure about support on platforms that do not use GNU gettext, e.g. Solaris(?). In my opinion not a blocker; other gettext implementations will have to adopt. After all, GNU gettext 0.15 with msgctxt support was released 24th July 2006, so this should not be news to other gettext implementations. However, this should probably be taken into consideration.

Status of this goal

Above are the states and corresponding markup to update the affected modules state table (as of 2009/01/11) below.