Re: GNUN setup issue

[Yavor Doganov]

В 19:33 +0300 на 14.12.2009 (пн), Ineiev написа:
> On 12/14/09, Yavor Doganov <address@hidden> wrote:
> >> So, how do I check?
> >
> > You don't.  (I don't do it, at least.)
> 
> This is a surprise for me. probably because I'm a really new translator.

What is so surprising?  Requiring every translator to build and verify
the .LANG.html is unrealistic.  We have an official GNUN build job
operating in www, and there are notifications for all kinds of errors.
It's not a big problem if a buggy .po file is committed; this happens
fairly often.

> Perhaps it is ridiculous, but I'm not a member.

Not ridiculous, and not a problem in itself.  Membership is almost
formal.  There are some teams with lots of members who do nothing, and
others with a few members who process external contributions, thus
advancing in their translation efforts much more.

Being a project member of www-LANG just gives you commit rights to its
repository, if there's any.

I can always add you as a member to the trans-coord Savannah project if
you want to experiment with the GNUN testbed there, and of course I can
subscribe you to trans-coord-discuss if Anatoly is OK with this.

> I tried again and did not find neither GNUmakefile (not GNUmakefile.team),
> nor config.mk in gnun.info, and quick search for `links' didn't give me
> anything (though I could miss something).

IIRC it was announced in NEWS, but described not in the documentation.
I'll try to rectify this soon.

Back to your original problem: the culprit is that distros.pot does not
correspond to distros.html for some reason.  I'll have to figure out why
this is so by examining the logs, but after building your translation
the .po is modified as follows:

$ msgfmt -cvv -o /dev/null distros/po/distros.ru.po
15 переведенных сообщений, 7 неточных переводов, 1 непереведенное сообщение.

That's why you see them untranslated in distros.ru.html.  Because there
are no .proto/.m4 files in my checkout at my workplace (and in yours
when you attempted to build it), GNUN rebuilds them from scratch so
there's an apparent discrepancy/mismatch.  I touched that file in my
working copy at fp to force the regeneration of the .pot, but this has
to be investigated to find out the real bug -- for sure there is some
bug as GNUN wrongly considers distros.pot up-to-date on my working copy
at fencepost.gnu.org).