[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] internationalization files layout

From: strk
Subject: [Gnash-dev] internationalization files layout
Date: Fri, 3 Oct 2008 11:10:22 +0200

So I understood we want to install .gmo files.

.gmo files are compiled from .po files using msgfmt (gettext package).
.po files are updated from gnash.pot using msgmerge (gettext package).
gnash.pot is generated from actual source code using xgettext (gettext package).

In the above scenario, .po files may be seen as souce code, as they
contain actual translations. So a translator w/out gettext should
be able to update a translation file.
Gnash repository DOES contain .po files, so all is fine there.

Problems are with .gmo files and update of .po files, and what
happens on 'make' and 'make dist'.

The .gmo files problem

As of gnash trunk, .gmo files are generated on 'make', not cleaned
on 'make clean', and distributed on 'make dist'.
Why do we want to distribute .gmo files at all ?
Can't we just make gettext a dependency or skip installing .gmo
files if the builder doesn't have gettext ?

The .po files problem

As of gnash trunk, 'make dist' triggers an update of the .po
files, so by the end of it your source tree is modified.
This is likely done to ensure .po files in a distributed
package are up-to-date with soucecode, since they depend
on gnash.pot which is generated from source code.

The intentions are correct, but why should we then NOT
commit the updated version of the .po to repository ?

I'd rather ensure we update the .pot and .po everytime
now and then, and make sure we do before shipping a 
tarball. Ideally, this could be done as a commit-hook
but wouldn't be so picky.

Final proposal

My proposal is as follows:

1) Don't distribute .gmo files.
2) Don't install .gmo files if gettext isn't found.
3) Don't update .po files on 'make dist'.
4) Keep the update-po rule to explicitly update gnash.pot and .po files,
   to be used periodically with a subsequent commit.

Comments ? 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]