The build process has several modes of operation, and they all relate to
the handling of files that are to be added to the repository or
performing certain sanity checks at build time. The variables are
specified on the command line, after
make, in the form
make VCS=yes. In the future,
additional features will be implemented in a similar fashion.
Do not add any files to the repository. This is the default. You may
as well omit to define
VCS entirely; there is no special code
that expects assigning the value ‘no’.
Automatically add any new files in the repository (CVS, Subversion or
GNU Bazaar—the repository type is auto-determined at build time,
bzr being a fallback).4 These are
any POT files, if they are generated for the first time, and the
translated articles (.lang.html) in HTML format. Finally,
any missing PO and their HTML counterparts of
the server templates will be added, computed on the basis of the
Skips validation of the HTML articles and generated translations.
Validates all original articles before generating the POTs, to ensure that the ultimate source is valid (X)HMTL. Also, validates all generated translations in HTML format and all PO files. It is highly recommended to run the build this way, even if it is a bit tedious to fix the errors that are reported as a result of enforcing validation.
Articles defined in the variable
no-validate-articles are never
checked for HTML validity. Its purpose was to skip validation of HTML5
articles, until the command-line validation tools are updated to
parse files that comply with this new standard. As of version 0.5
GNUN supports HTML5, so resorting to
should not be necessary.
This is the default, and not defining this variable has the same effect.
Do not send email notifications about errors. This is the default.
If an error occurs, send a mail with a meaningful subject and the error
message as body to the concerned party. The variables
transl-addr control the
recipients; normally they should be set to the GNUN maintainers,
webmasters and translators accordingly. These variables are defined in
the configuration file gnun.conf and by default are set to
If defined, automatic announcements for new translations will be sent to
the address defined in the
ann-addr variable (in
gnun.conf). The email messages contain the translated article
title as Subject, and the URL of the translation as its body. For the
official GNUN build, they are delivered to the
email@example.com mailing list and each language has its
own Mailman topic. It is possible to subscribe to the list and
receive only traffic related to a specific language. See Mailing
Lists in GNU Web Translators Manual.
The default behavior is not to send such announcements.
If defined, the value of the variables
will be printed to the standard output. This is off by
default, but recommended in general since it will show a bug in the
computation of the basic variables.
If defined, ordinary articles that have “fuzzy” strings and are not older
than days will not be regenerated. This functionality is
implemented specifically to prevent gratuitous replacement of translated
strings with the English text when there are only minor formatting
changes in the original. The translator has time (the “grace” period
as defined in this variable) to review the changes and clear the “fuzzy”
mark from the
strings, while keeping the online translation intact. Note that this
variable has no effect on the server templates
and all articles defined in the variable
Grace period for the out-of-date notice. When the variable
GRACE is defined,
OUTDATED-GRACE defaults to 60 days
(see grace period). The out-of-date notice is a special
text (server/outdated.html in the ‘www’ repository) that is
inserted into every outdated translation when the period defined in
this variable is over; its purpose is to inform the reader that the
translation may not correspond to the original English article.
The translation team whose articles need to be checked for
completeness. This variable is applicable only for the
target, and is mandatory for it. See report.
When validation is enabled, the
original English articles are validated first, before any commands
that generate the other files, and
make exits with an error
on the first encountered article. This is done on purpose, to prevent
the propagation of an eventual error in the markup of the original
article to all translations.
Validation of the translated .lang.html is performed after it is preliminarily generated as a temporary file. When no errors are found, the translation is updated; otherwise the real file is not changed (and it is not added if absent)—the build will fail and further processing of the remaining articles will not be performed. The translator has time until the next run to fix the error—usually by modifying the corresponding .lang.po file.
If notification is enabled (
NOTIFY=yes), and the build system
encounters errors (mostly when validating articles), email messages
will be sent to the party that is expected to fix the error. The
subject of the messages always includes the problematic article, for
Subject: [GNUN Error] gnu/gnu.fa.html is not valid HTML
When GNU Bzr is used, files
are added locally only; you need to take care to use
manually (or via cron) to take care of effectively adding them to the
public repository. See triggers, for a short explanation.