Re: live-manual: Building translated manuals individually
- To: Debian-live mailing list <email@example.com>
- Subject: Re: live-manual: Building translated manuals individually
- From: chals <firstname.lastname@example.org>
- Date: Mon, 26 May 2014 21:21:00 +0200
- Message-id: <CAJRhvALZGhGR6cm9=XCh585hzq65vqFf4CJyVnE2EwRXXtTkPg@mail.gmail.com>
- In-reply-to: <CAJRhvA+m_d2vAvuctd+00Uo75CktohD0W=f0kH5pE+QyTZWfZw@mail.gmail.com>
- References: <CAJRhvA+m_d2vAvuctd+00Uo75CktohD0W=f0kH5pE+QyTZWfZw@mail.gmail.com>
On Tue, May 20, 2014 at 9:11 PM, chals <email@example.com> wrote:
> The question is:
> Are live-manual makefiles flexible enough to build translated manuals
> by language (one at a time)?
> The answer is:
> Absolutely yes! (With capital letters)
Indeed. But since some recent changes have slightly improved the
translation process I would like to comment a couple of things (just
for the record).
Basically, the po4a.cfg configuration file was added to the .gitignore
file. This means that changes to this file are not tracked anymore.
This is not really a big loss but rather on the contrary, the po4a.cfg
is deleted and recreated by the Makefile after each run, so the
changes to the configuration have to be made in the Makefile and they
have to be tracked there, not in the file itself. Besides, this will
add a tiny bit of flexibility to the translation workflow because
experienced translators will be able to modify the po4a.cfg if they
want to, without worrying about the changes they make.
Second, the .po integrity check is now part of the po4a Makefile "so
to speak" because it really belongs in there. This way, there is no
way of skipping it now, as long as one uses the makefiles.
One may ask: "Why is this .po integrity check important? Does it
really make a difference?"
Indeed. This check has made part of the live-manual processing more
robust. The build process has not broken anymore due to bad .po files
since the check was added.
Do not get confused by this seemingly innocent .po integrity check
which will normally remain silent. Because if you mess with the .po
files, the integrity check will behave like a fierce watchdog
preventing you from committing bad .po files. It has yet another
advantage, when angry, the .po check is very verbose, informing where
and how you have messed with the file/files. So fixing stuff is a
Last thing. In my previous mail I suggested that using a very general
commit message like "Updating dates in live-manual files." would be
enough. This is usually the case when building all languages, but when
only building one language, we should tune the commit message a little
bit to make it more accurate.
Sorry, again, for these looong messages. Thanks for listening!