Next: , Previous: , Up: General Usage   [Contents][Index]

2.2 Variables to Control the Build Process

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 VARIABLE=value, e.g. 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 extra-templates and optional-templates variables.


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.

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 devel-addr, web-addr and 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 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 templates-translated, ALL_POTS, and articles-translated 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 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 should review the changes, update the translation and clear the “fuzzy” mark from the strings, while keeping the online translation intact5. Note that this variable has no effect on the server templates and all articles defined in the variable no-grace-articles.


Grace period for the out-of-date notice. When the variable GRACE is defined, OUTDATED-GRACE defaults to 60 days. 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 report target, and is mandatory for it. See The report Target.

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 example:

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 bzr push manually (or via cron) to take care of effectively adding them to the public repository. See The triggers Target, for a short explanation.


This variable used to define the “grace period” in days to let the translator update the strings before the English text propagates to the translated page, but in practice that period has always been unlimited

Next: Targets Specified on the Command Line, Previous: Invoking GNUN, Up: General Usage   [Contents][Index]