Next: , Previous: , Up: GNUnited Nations   [Contents][Index]

3 Maintaining Translations in Your Team’s Repository

GNUN operates on the “official” Web repository of the Savannah project ‘www’, where normally only the co-ordinators of translation teams have write access. However, all translation teams have their own projects, so it is possible to take advantage of Savannah as a hosting facility to make the team work more comfortable.

The PO files provide an excellent and natural way to review each other’s translations, because the translation appears right below the original message. Mutual reviews and proof-reading of translations is a crucial part of the process. Furthermore, team work is great for the community spirit; automating some of the operations also result in more time for all members to concentrate on the important tasks.

The file in the ‘gnun’ package is a template, aimed for all translation teams who wish to use their own project’s repository as a place to keep their draft translations, until they ripe and are ready to be installed officially.

The following diagram illustrates a typical workflow—it is applicable for small, medium and large teams:

+----------+                   +-------------------+
| ``www''  |                   |   ``www-LANG''    |
|   Web    |------>---->-------|Sources repository |
|repository|  automatic merge  +-------------------+
+----------+                         |    |     |
     |                               |    |     `-- Member A
     +------------<----<-------------'    |
                  Leader                  `---Member B

All members and the team leader commit in their project’s repository—when a translation is ready, the leader checks it in the official ‘www’ repository. If an original article changes, a build can be invoked to synchronize (i.e. merge) the changes and optionally automatically commit them so that the draft PO files are updated; at the same time, automatic notifications are sent to the persons interested in particular translations8. A translator will then normally update the PO file, and commit it again in the project’s Sources repository, from where the co-ordinator will pick it up and install it in ‘www’.

To take advantage of this semi-automation, rename this template as GNUmakefile and install it in the root of your project’s Sources repository. Then create directories and sub-directories exactly as they are in ‘www’. Do not create the /po sub-directories; they are redundant here. Instead, install the PO files in the normal locations where the corresponding .lang.html resides in ‘www’, for example:

  |   |
  |   |
  |   +--linux-and-gnu.lang.po
  |   +--manifesto.lang.po
  |   +--…
  |     |
  |     |
  |     +--free-sw.lang.po
  |     +--not-ipr.lang.po
  |     +--open-source-misses-the-point.lang.po
  |     +--…

The next sections explain how to adopt the makefile for your team and how to invoke a “build”.



The following sections describe in more details how to setup these automatic actions; however, if you have any difficulties with that, please ask the GNU Web Translation Managers to set them up for your team on our server.

Next: Working with PO Files, Previous: General Usage, Up: GNUnited Nations   [Contents][Index]