Next: Targets Specified on the Command Line, Previous: Invoking GNUN, Up: General Usage [Contents][Index]
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
bug-gnun@gnu.org.
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.
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]