I just pulled tomboy TRUNK out of svn, and lv.po does not contain the string "\x01" anywhere in the file, and the last modification to the file was on 2007-04-01.

Are you sure there isn't some other problem perhaps? It also strikes me as odd that your "steps to reproduce" says that you have to run intltool-merge twice, not once.

Adding the \x01 does seem to cause other valid translations to be skipped though. The fi translation seems to be the only one up to date for the .desktop file, and it doesn't included for the _Comment tag when I place the \x01 in the lv.po. I don't know why that is though. The lv.po would be skipped anyway. It's probably the fact that intlool ALLOWS such characters to exist, rather than disallowing them, that is the problem here. What would "START HEADING" mean for a string in a translation, or a desktop file, anyway?

Of course I mean the control character code ^A, not "\x01" literally. Here is the bad lv.po entries:

#: ../libtomboy/gedit-print.c:267
#, c-format
msgid "Rendering page %d of %d..."
msgstr "RenderDju %d no %d lapDm..."

#: ../libtomboy/gedit-print.c:269
#, c-format
msgid "Printing page %d of %d..."
msgstr "DrukDju %d no %d lapDm..."


Reproducing by running twice is because, it breaks the cache feature. intltool-merge uses ^A (\x01) as the entry separator while saving/loading the cache. Having ^A in a msgstr breaks it, and intltool-merge loads wrong cache in the second run. The below is the buggy piece of intltool-merge code:


sub create_cache
{
    print "Generating and caching the translation database\n" unless $QUIET_ARG;

    &create_translation_database;

    open CACHE, ">$cache_file" || die;
    print CACHE join "\x01", %translations;
    close CACHE;
}

sub load_cache 
{
    print "Found cached translation database\n" unless $QUIET_ARG;

    my $contents;
    open CACHE, "<$cache_file" || die;
    {
        local $/;
        $contents = <CACHE>;
    }
    close CACHE;
    %translations = split "\x01", $contents;
}


The current tomboy Debian package has incomplete .server file. (.desktop file is built in the first run, .server file is built from the wrong cache.) I thought it was a Debian specific problem until I found the lv.po entries and this intltool-merge code. I'm still not sure why Fedora (or even Ubuntu) has no such problem though. 

OK. I read the Fedora's tomboy build log and I found why..  They are using -j4 make option for build. Three intltool-merge processes run in parallel so accidentally avoid using the wrong cache.

And Ubuntu package's .server file is also incomplete. But they seem to implement their own runtime translation mechanism for their translation only package.

<oaf_server ubuntu-gettext-domain="tomboy" iid="OAFIID:TomboyApplet_Factory" ...

IMHO this is a bug in the lv.po. Such control chars shouldn't be in the msgstr in the first place. Maybe check with the Last translator...

I agree with Claude here. The gettext documentation says to avoid control characters like this. See http://www.gnu.org/software/automake/manual/gettext/Preparing-Strings.html for reference.

Then how about exit with an error when there is such a control character, instead of generating wrong files silently?

CC'ing Raivis who was te last Latvian translator - please take a look at this!

I removed control characters from Latvian lv.po. It should be ok now.

This is definitely not a bug. GNU gettext uses such characters internally, yet silently produces bad PO files if you try to compile them (i.e. try with \0 or \2, which is, if I am not misremembering, used for msgctxt separation in MO files: you'll get broken MO files as well).

MO file with \0 or \2 does not break other translated messages. But in this case, a single \1 character broke all languages' intltool-merge based translations silently.

It's not intltool's fault, but a simple check by intltool can prevent it.