Next: , Previous: , Up: 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.

VCS=no

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’.

VCS=yes

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).3 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.

VCS=always

Because GNU Make considers the targets up-to-date after a successful build, if it was performed with no VCS interaction, the important newly created files will not be added (and committed when you do cvs|svn|bzr commit) in the repository. Assigning this value enables additional check and forcefully adds all files. Use it sparingly, since it is very slow and generally less reliable.

VALIDATE=no

Skips validation of the HTML articles and generated translations.

VALIDATE=yes

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 no-validate-articles should not be necessary.

This is the default, and not defining this variable has the same effect.

NOTIFY=no

Do not send email notifications about errors. This is the default.

NOTIFY=yes

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 bug-gnun@gnu.org.

ANNOUNCE=yes

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 trans-coord-news@gnu.org 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.

VERBOSE=yes

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.

GRACE=days

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 no-grace-articles.

OUTDATED-GRACE=days

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.

TEAM=lang

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 report.

Note that VCS=yes,always is a valid combination: because POT files of the server templates are not handled by always, running the build this way will commit any newly added files as specified in TEMPLATE_LINGUAS and will perform additional check at the end, cvs|svn|bzr add-ing all necessary files.

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

Footnotes

(3)

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 triggers, for a short explanation.


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