3.2 Targets in GNUmakefile.team

update

Updates the repositories. Does nothing unless VCS=yes.

sync

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.

report

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 notify target.

notify

Invokes 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 NOTIFICATION_PERIOD variable.

The fourth field provides comma-separated options for the report. Currently recognized options are:

force

Forces sending messages even when there are no files to work on.

no-diffs

Disables sending www vs. www-lang differences as attachments.

www

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:alice@example.com abc@test.net
# Disable `dan' temporarily.
#dan:miller@test.by:5:no-diffs,www
bob:brh@invalid.tr:3
# Note that the third field is empty; the default value for period
# will be used.
carol:carol@localhost.br translator@example.bg::no-diffs
eve:eve@test.gr:2:www
frank:gnun-notifications@example.gr: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.

format

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, and runs 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 unnecessarily invoke msgcat for any file that has a longer line, wherever it may occur.

publish

The publish rule’s task is to copy all modified files to the official www repository. It depends on the format target to ensure that all files are re-wrapped to the standard line length limit, but deliberately does not depend on sync VCS=yes. 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 cp invocations. As a rule of thumb, before running this rule it is sane to run sync and correct any “fuzzy” messages and other problems, if necessary.

The publish rule does not depend on sync explicitly, 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 cvs diff.

Invoking 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."

clean

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

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 bug-gnun@gnu.org, so that GNUmakefile.team gets updated for all teams’ benefit.