Updates the repositories. Does nothing unless
Merges all available PO files from the corresponding POT in www. If a POT is missing in the master repository (usually, because it was deleted when the original article was either split, renamed or deleted), a warning is printed for the corresponding file and no merging occurs for it.
Verifies which translations are complete, and prints a list (with statistics) of those that need to be updated. Also, it reports the translations that are not consistent with the revisions from www repository.
More fine-grained notifications are implemented as the
report target, filters its output for different
translators and sends them notifications.
As an addition to the output of the
report target, URLs for
relevant files are written; also, when www and team revisions
are not consistent, their differences generated with
gnun-diff-po are optionally attached (see gnun-diff-po,
for more details).
The list of files to report against are configured with nottab file. The lines of this file that begin with ‘#’ are ignored; other lines should contain two fields separated by ‘:’.
The first field is an extended grep regular expression; the files are selected for the report if their names match this expression. See Regular Expressions in GNU Grep manual.
The second field is a space-separated list of single-word translators’ identifiers for which the line applies. The file may look like this:
^gnu/gnu-history: alice bob carol ^distros/(common-distros|distros|screenshot): dan alice ^(licenses|philosophy)/: eve bob frank ^licenses/: dan
Email addresses of the translators are kept in a separate file, email-aliases. Like nottab, this file contains lines separated by ‘:’; the lines beginning with ‘#’ are ignored.
The first field is translators’ identifier, the second is space-separated list of translators’ email addresses. These two fields are mandatory.
The third field is the personal reminder period in days. After that
period the message is sent again even though its contents don’t
change. Otherwise, the
notify target only sends messages when
something changes. Naturally, no message is sent when no action
is needed in the requested set of translations (unless the
force option is used).
The team-wide default period is defined in its GNUmakefile.team using
The fourth field provides comma-separated options for the report. Currently recognized options are:
Forces sending messages even when there are no files to work on.
Disables sending www vs. www-lang differences as attachments.
Report cases that suggest actions by the team leader, that is, when the translation in the team repository is full whereas in www it is incomplete or absent.
This is an example of email-aliases:
alice:firstname.lastname@example.org email@example.com # Disable `dan' temporarily. #dan:firstname.lastname@example.org:5:no-diffs,www bob:email@example.com:3 # Note that the third field is empty; the default value for period # will be used. carol:firstname.lastname@example.org email@example.com::no-diffs eve:firstname.lastname@example.org:2:www frank:email@example.com:1:www,no-diffs
The email-aliases file should be kept privately because it may contain personal email addresses of people. How to do this is out of scope of GNUN and this manual.
A convenience rule to re-wrap all files upto the standard length. Most
PO editors leave the
msgstr as a single long line after it has
been edited, but GNUN will automatically re-wrap the file to the standard
line length when it is processed. Wrapping long lines in PO files is a
good practice as it avoids unnecessary revisions.
This rule checks for all translations that have lines longer than 80,
msgcat accordingly to reformat them. For that
reason, it is recommended that you wrap all long lines in the comment
fields (e.g. the file header, including the copyright statement, and any
other comments for specific messages), because
make format will
msgcat for any file that has a longer
line, wherever it may occur.
publish rule’s task is to copy all modified files to the
official www repository. It depends on the
to ensure that all files are re-wrapped to the standard line length
limit, but deliberately does not depend on
Usually, one would run
make publish when one or a bunch of PO
files are in a satisfactory condition to be published, and this rule is
just a convenience to avoid multiple manual
As a rule of thumb, before running this rule it is sane to run
sync and correct any “fuzzy” messages and other problems, if
publish rule does not depend on
because that would be a nuisance for offline operations and basically
unnecessary when the committer is fairly confident that there are no
changes to (re-)merge. A hard dependency on
sync would slow down
the operation considerably.
As usual, when committing to the official repository, it is always a
good practice to examine the output of
make publish prints warnings and does not actually copy
the affected file if the sub-directory in “www” is non-existent or the
corresponding .pot is missing.
Typically, after an editing session (whether it involves actual editing or just merging contributions from team members), one would do:
$ make sync VCS=yes $ make publish $ cd wwwdir $ cvs up (Add all new translations, if any.) $ cvs add file … $ cvs diff $ cvs commit -m "Some descriptive message."
Deletes all backup and auto-generated files.
make VCS=yes is the recommended command to be run periodically.
To check the status of the translations, run
Feel free to replace all strings with equivalents in your native language and of course—do not hesitate to extend this file and modify it as much as you like. If you come up with something interesting, it would be nice to send a message to firstname.lastname@example.org, so that GNUmakefile.team gets updated for all teams’ benefit.