Re: [PATCH/RFC v2 6/6] gettext: Add a skeleton po/is.po

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, May 30, 2010 at 21:29, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Ęvar,
>
> Ęvar Arnfjörš Bjarmason wrote:
>
>> +#: wt-status.c:53
>> +msgid "# Unmerged paths:"
>> +msgstr ""
>
> On projects that use gettext, merging these line number changes can
> be a royal pain.  In effect, the .po files are mixing semantically
> meaningful text and automatically generated cruft.
>
> So my ignorant questions:
>
>  . does gettext use the #: comments for anything important?
>  . can they be suppressed when generating the .po file?
>  . can they be easily re-added if some translation front-end needs
>   them?

Let me answer that more generally.

Usually when people first see the Gettext format they go "ew!". The
thing is that it's really meant as a format for mixed human and
programmatic editing. Almost everyone editing PO files doesn't do so
purely with a simple non-PO aware text editor.

PO editors use these comments to allow you to jump to the source
definition to see the message in context. E.g. Emacs's po-mode allows
you to do this, and Launchpad displays the file & line number (but
last I checked they didn't have an embedded viewer).

A merge of two PO files that doesn't use msgmerge(1) is going to be
painful. There are some things that it'll throw out and regenerate
(e.g. automated comments, those matching /^#\S/), and it might move
messages around to match their new position in the respective source
files. Thus a merge that might be hard with a simple git merge might
be very easy with a msgmerge-based merge.

Now, we could filter out all these comments (and e.g. context
comments) before checking these files in. But that would cause a lot
of tools like Launchpad and PO editors to behave in unexpected
ways. The Gettext utilities themselves also seem to have no support
for initializing/emitting these sort of slim files.

I don't know what the answer is, but this is all something to
consider. I'm new to the Gettext format myself, but I've come to like
the automatic editing the tools do, especially the automaticy fuzzy
tagging.