Must exist, even if empty. Consists of a list of translations -
each line not starting with a # must match an existing PO file.
e.g. if LINGUAS contains a single line, fr, an fr.po file
must exist alongside the LINGUAS file.
By convention, the LINGUAS file is sorted alphabetically but that is a manual process.
The list of files containing the messages that need to be translated
at runtime - i.e. your scripts. If youve used the top level po/
directory, the paths should be relative to the top level directory,
not the po/ directory itself.
Note that it is explicitly supported that the scripts themselves can contain strings for both runtime and documentation translation, e.g. using gettext functions for runtime and embedded POD content for documentation. So it is not a problem to have the same file listed in po/POTFILES.in and doc/po4a-build.conf
|Makevars-perl.example||If your scripts are in Perl, copy this example file as po/Makevars and edit it to suit.|
|Makevars-shell.example||If your scripts are in shell, copy this example file as po/Makevars and edit it to suit.|
|po4a-build.make||Copy this example file as po/Makefile - it shouldnt need editing but you may want to keep it updated against /usr/share/doc/po4a/examples/po4a-build.make as it may need to be updated within po4a releases as the underlying intltool support changes. (The file itself was generated from another project using Autotools and intltool.)|
These snippets need to be added to your top level Makefile or whatever other method you use to prepare your sources for distribution.
clean: $(MAKE) -C po/ clean install: $(MAKE) -C po/ install DESTDIR=$(DESTDIR) dist: $(MAKE) -C po/ pot
(In an Autotools project, this would happen automatically by simply adding po to the SUBDIRS value in Makefile.am.)
Runtime translation isnt quite as easy as po4a-build in that adding a new translation does require editing po/LINGUAS, but apart from that, updating translations is merely a case of replacing the relevant PO file with the new version.
Depending on how you prepare your source tarball, you may also need to list new PO files in the MANIFEST file or add to the script(s) that prepare the tarball. (That also applies to po4a-build.)
Any *.mo or *.gmo files in po/ can be deleted / cleaned up.
Whilst the example files are part of the po4a project, you are free to use, modify and distribute them in your own projects without needing to refer back to po4a or list the po4a team in your own copyright notices, in the same manner as other build tools like Automake itself. If you want to mention po4a, that is fine too.
Neil Williams <firstname.lastname@example.org>
|Po4a Tools||PO4A-RUNTIME (7)||2016-04-03|