Re: [Fwd: Re: Main Page, again]

[Yavor Doganov]

Hossam Hossny wrote:
> Yavor Doganov wrote:
> > Strange.  This looks like a GNUN bug

> I was near certain that's a GNUN bug.

Yes and no...  Strictly theoretically speaking, it is not a bug as we
assume that translators always work with up-to-date files.  (That's
what GNUmakefile.team does automatically, BTW).  In practice, though,
it may often happen that this assumption is false -- for example,
someone from your team picks an incomplete .ar.po file from the repo,
works on it for some time, and sends you the completed file (but it's
already out of date despite his changes because the English .html
changed in the meantime).  If you don't msgmerge it before committing
to the official repository, it will be done by GNUN -- but only for
the ordinary articles.

FWIW, article-rules has the following comment (and command) precisely
because of this:

# If a translator commits a PO file based on an old version of the
# POT, it is not msgmerge'd as `make' considers the corresponding
# `$(1).po' target up-to-date.  As a result, the generated HTML
# translations has English strings (but no fuzzy strings in the PO)
# since there's no match between msgid/msgstr.  Invoke msgmerge
# unconditionally to cope with that (valid) scenario.

So thanks for reporting this -- I don't remember why I made it only
for article-rules when I discovered this issue.  Fixed as follows
(will be in gnun-0.3):

2009-05-20  Yavor Doganov  <address@hidden>

        * GNUmakefile ($(rootdir)/home.$(1).shtml)
        ($(template-dir)/po/whatsnew.%.html): Unconditionally update the
        PO file before the .LANG.m4 generation to cater for the case when
        translators do not commit an up-to-date properly msgmerge'd PO.
        Reported by Hossam Hossny.
        * THANKS:
        * NEWS: Update.