Re: building vanilla gnu.org-i18n

[Yavor Doganov]

Калоян Доганов wrote:
> 
> 1. When generating a pot-file, po4a-gettextize always updates the
>    "POT-Creation-Date" field, even all other strings are identical. 

This is neither a bug nor a misbehaviour.  Rather, it's a classic
example of the problem when keeping automatically generated files
under VCS control and an indication that our rules are correct.  Let
me try to explain.

rms-lisp.html was committed by me on 5th Dec.  When you updated from
SVN, the file was new in your working copy.  For your make, the pot
has to be rebuilt because from make's point of view, it is not
up-to-date.  The same happens when you make a fresh checkout on a new
machine (or just another working copy), and run make:

$ svn st | grep M
M      gnu/po/rms-lisp.pot
M      gnu/po/gnu.pot
M      philosophy/po/eldred-amicus.pot
M      philosophy/po/bdk.pot
M      philosophy/po/schools.pot
M      po/keepingup.pot
M      po/home.pot
M      po/provide.pot

(Here you don't see the templates, because on that machine I don't
have po4a from CVS so I ran `make -k' to avoid the problem with the
missing Html po4a module.)

The only way for make to be sure they're up-to-date is running the
command(s) that updates them.
Now because msgmerge never modifies the po when there is nothing to
merge, the po files are considered up-to-date, as well as everything
further in the chain.

If po4a-gettextize was run every time, you would observe this every
time you run make (and also svn diff would show a new
POT-Creation-Date that is equal to the present time).  It is run only
once, when the prerequisite file changed on your disk.

>    I suppose we wouldn't want to commit such "changes" in www.

Definitely, but it won't be a problem, because the thing will run from
one working copy (i.e. fencepost).  It will be a problem when it is
moved to another machine, etc. -- then all POT files will be rebuilt
the way you observed.  I don't expect it to happen, but it would be
very annoying when it does.

Now I agree that it is inconvenient for the present development, since
all updated/new files from you will be "modified" in my working copy
when I update and remake (and vice-versa).

We could check somehow if the diff is only POT-Creation-Date (by
copying the file to a temporary file, running the command, etc.) and
consider the target up-to-date if that's the case.  Would you like to
implement this?   There might be an easier way, though.

> 2. Now Po4a's Xhtml module generates the same results for the templates
>    (www/server directory) as the Html module currently in use.

Are you sure (I didn't checked myself)?  If so, that's a relief.

>   Should I install it?

Yes, please do, it is better to use only Xhtml, if we can.

>     I dropped the idea of adding directories automatically
> 
> Good, then we should reflect that descision in the TODO file.

You have done this, thanks.

>     More specifically, the system should cvs add these files if they are
>     created by the make process:
>
> Maybe this should be done by the so called "cronjob" script. 

I don't see how.  Maybe there's a way, but it's not easy and it's
definitely prone to errors.

> idea to keep the basic page regeneration process agnostic from the SCM
> system.

Well, the main purpose of the software is automatic updates of the
translated articles.  But...

> One should be able to regenerate translated pages using a tarball of
> www, without depending on any SCM.

...I can see that you are right, a translator should be able to do
`make ../../philosophy/article.xx.html' and inspect the generated file
(provided that she has all necessary tools installed).

One way to solve this is to cvs add conditionally, f.i. if hostname is
fp (plus a whoami check, eventually).  Another way, which seems more
feasible and robust as a solution, is to introduce a new conditional
variable CVS_ADD.  Thus, running `make' will not cvs add, but running
`make CVS_ADD=yes' will.  What do you think?

>     I was thinking about this: When a file is modified, an extra
>     command will append the cvs log message from the original file.
>
> This looks tricky and the gain is not so obvious.  

Right.  I'll work for the basic CVS support and will go for this after
some serious thought and discussion.  

>     For language teams, a `msgfmt --statistics'-similar output 
>
> Yes, it's early to think about this, but we must not forget it too.
> I'll add it to the TODO file. 

Thanks.

> Please check whether it ovelaps with the earlier entry "Write a
> script to check the completeness of the translations per language,
> so that a team leader can do", and merge them if apropriate.

Yes, more or less it overlaps.  Initially I thought about a script,
but doing it with make seems more powerful.  We'll think about it
later.

> I don't know neither Autoconf nor DejaGNU. 

I think I can do it (or at least try).  But we'll leave it for now,
it's just a nice enhancement.

> My point is this - let's first observe and catalogue all things that
> must be done.  Then, using the resulted list of issues, we can make
> rational descisions about on what to concentrate our efforts.

Agreed.