Re: gnulib's translation

[Bruno Haible]

Hi Benno,

> > Ah, you were assuming that the POT file is stored in the version control 
> > system?
> > This is a practice that produces problems,
> 
> What problems does this produce?

<BEGIN NEW DOC>

There are basically three ways to deal with generated files in the context
of a version controlled repository, such as ‘configure’ generated from
‘configure.ac’, parser.c generated from parser.y, or po/Makefile.in.in
autoinstalled by gettextize or autopoint.

“Never”
    Generated files are never committed into the repository. 
“Occasionally”
    All generated files are committed into the repository occasionally, for
    example each time a release is made. 
“Always”
    All generated files are always committed into the repository. 

Each of these three approaches has different advantages and drawbacks.

“Never”
    The advantage is less work for the maintainers. In particular, the
    handling of branches becomes much easier, both for release branches
    and “topic branches” as in Git. The drawback is that anyone who checks
    out the source not only needs tools like GNU automake, GNU autoconf,
    GNU m4 installed in his PATH, but also that he needs to perform a
    package specific pre-build step before being able to "./configure; make".
“Occasionally”
    The advantage is that anyone can check out the source, and the usual
    "./configure; make" will work. The drawbacks are: 1. The one who checks
    out the repository needs tools like GNU automake, GNU autoconf, GNU m4
    installed in his PATH; sometimes he even needs particular versions of
    them. 2. When a release is made and a commit is made on the generated
    files, the other developers get conflicts on the generated files when
    merging the local work back to the repository. Although these conflicts
    are easy to resolve, they are annoying. 3. Copying a change to a branch
    is not easy, because it involves separating the patch into a hand-made
    part, to be applied literally, and a set of commands or Makefile targets
    which will produce the other part. 4. Working with branches is time-
    consuming and error-prone.
“Always”
    The advantage is that anyone can check out the source at any moment and
    gets a working build. The drawbacks are: 1. It requires some frequent
    "push" actions by the maintainers. 2. The repository grows in size quite
    fast. 3. and 4. as for “Occasionally”. 

The “Never” approach is the predominant one nowadays, especially in projects 
that use branches like in Git. 

<END NEW DOC>

> (Probably this was discussed earlier
> and elsewhere?  Maybe have a URL of an archived message?)

It will be documented in the next release of the GNU gettext manual.

Bruno