Next: , Previous: , Up: Maintaining Translations in Your Team’s Repository   [Contents][Index]

3.2 Targets in


Updates the working copy of team’s repository.


Updates the working copy of www.


A shortcut for making update-team and update-www.


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


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 The gnun-diff-po Script, 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 in nottab, the lines beginning with ‘#’ are ignored; other lines contain fields separated by ‘:’.

The first field is the translator’s identifier, the second is space-separated list of translator’s 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 using the NOTIFICATION_PERIOD variable.

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 complete whereas in www it is incomplete or absent.

This is an example of email-aliases:
# Disable `dan' temporarily.,www
# Note that the third field is empty; the default value for period
# will be used.,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 up to the standard length. Many 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 filters all translations with msgcat; basically, it reformats the lines that are longer than the default page width of msgcat.


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

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, so that gets updated for all teams’ benefit.

Next: Automatic Synchronization and Status Reports, Previous: Adopting for a Specific Team, Up: Maintaining Translations in Your Team’s Repository   [Contents][Index]