3:27 p.m.
Hello,
Marc Haber already asked for a small document that could give best
practice for maintainers.
Today, Denis and Thomas also pointed that we should define a common
hierarchy to help the l10n robot to detect POs used for translation.
This robot is used by some translation teams (at least the French one) to
inform the translators that the PO needs to be updated.
Detecting po4a's PO will permit to check that the POT are up-to-date and
the POs also.
(Denis and Thomas, correct me if I'm wrong)
Can you check if the attached file is clear enough? (is it too verbose?)
Do you agree of the proposed file hierarchy?
Does it represent your opinion?
BTW, there are currently 17 packages which build-depend on po4a:
adduser, apt-build, apt-proxy, apt-show-versions, base-passwd,
belocs-locales-bin, debarchiver, debhelper, deborphan, debsums,
devscripts, fakeroot, glibc, mailliststat, pppconfig, smb2www, squashfs
dpkg (soon in experimental)
apt, aptitude and debianutils may also switch
Kind Regards,
--
Nekral
4:24 p.m.
New subject: [Po4a-devel] po4a README.maintainers
On Sat, Feb 11, 2006 at 10:27:26PM +0100, Nicolas François wrote:
[...]
Detecting po4a's PO will permit to check that the POT are
up-to-date and
the POs also.
(Denis and Thomas, correct me if I'm wrong)
IIRC when I moved Martin's robot to a Debian machine, I wanted to take as
little resources as possible because some developers considered that l10n
work was a waste of time and resources, and I did not want to fight
against them. Thus only interesting files are extracted from source
packages, dpkg-source is not run. As a consequence we cannot regenerate
POT files.
Another consequence is that we need those POT files in source packages,
some maintainers do not understand that. But PO files are indeed checked
to make sure that they are up-to-date.
Can you check if the attached file is clear enough? (is it too
verbose?)
Do you agree of the proposed file hierarchy?
Does it represent your opinion?
It looks very good, yes. I will give some comments below.
BTW, there are currently 17 packages which build-depend on po4a:
adduser, apt-build, apt-proxy, apt-show-versions, base-passwd,
belocs-locales-bin, debarchiver, debhelper, deborphan, debsums,
devscripts, fakeroot, glibc, mailliststat, pppconfig, smb2www, squashfs
dpkg (soon in experimental)
Of course po-debconf uses po4a (for more than 2 years), but pages were
generated by hand and not automatically. This will be changed in
po-debconf 1.0 coming soon.
apt, aptitude and debianutils may also switch
Kind Regards,
--
Nekral
This document provides some general rules to deploy a translation
process
that will ease the work of maintainers (upstream and distribution
maintainers) and translators (or translation teams).
Translators usually retrieve a POT (for a new translation) or the current
PO for their language, then they translate the untranslated strings and
update the translation of the string marked fuzzy.
Translators need to know if a PO has to be updated:
* they can verify the POs in the version control system or in the
distributed archives/packages
* they can be inform by the translation teams, which automatically
check the status of the POs in various packages.
We want to avoid the translator to be notified by an user reporting that
some strings are not translated even if the PO contain no untranslated or
fuzzy string.
I do not understand this paragraph. Translators need up-to-date PO
files, they should not have to deal with source files.
[...]
A standardized architecture of the source tree will help the
translation
teams when they try to detect the POS that need to be updated.
Thus we recommend the following architecture:
root
|
|-- doc, man, ...
| |
| |-- en
| | |
| | \-- original documents
| |
| |-- po4a
| | |
| | |-- po
| | | |
| | | |-- <package>.pot
| | | |-- <lang1>.po
| | | \-- ...
| | |
| | |-- add_<lang>
| | | |
| | | |-- <translator1>.add
| | | \-- ...
| | |
| | \-- <package>.cfg
| |
| |-- <lang1>
| | |
| | \-- generated translations
| |
| \-- ...
You could also give another example when there are good reasons to have
several POT files, for instance:
root/doc/en
pkg1/po4a/
pkg2/po4a/
...
Maybe small examples could be included in po4a distributions?
Denis
5:58 p.m.
New subject: [Po4a-devel] po4a README.maintainers
On Sat, Feb 11, 2006 at 10:27:26PM +0100, Nicolas François wrote:
[...]
clean:
# Updtate the POT and POs
cd <...>/po4a && po4a --no-translations --rm-backups <package>.cfg
In fact, this depends on how paths are defined in <package>.cfg.
For instance with the same hierarchy, I will write in po4a/po-debconf.cfg:
[type: pod] en/debconf-gettextize.1.pod fr:fr/debconf-gettextize.1.pod \
add_fr:po4a/add_fr/translator.fr
and define targets by:
clean:
# Updtate the POT and POs
po4a --no-translations --rm-backups po4a/<package>.cfg
build:
# Generate the translations
po4a --rm-backups po4a/<package>.cfg
Denis
6:50 a.m.
New subject: [Po4a-devel] Re: po4a README.maintainers
Hello,
Nicolas François <nicolas.francois(a)centraliens.net> (11/02/2006):
Marc Haber already asked for a small document that could give best
practice for maintainers.
Today, Denis and Thomas also pointed that we should define a common
hierarchy to help the l10n robot to detect POs used for translation.
This robot is used by some translation teams (at least the French one) to
inform the translators that the PO needs to be updated.
Detecting po4a's PO will permit to check that the POT are up-to-date and
the POs also.
(Denis and Thomas, correct me if I'm wrong)
Can you check if the attached file is clear enough? (is it too verbose?)
Do you agree of the proposed file hierarchy?
As Denis said, you should also document the situation when there are
several POT files.
Quoting Denis:
> root/doc/en
> pkg1/po4a/
> pkg2/po4a/
I'm not sure this is the best solution, as it is hard to refactor
addenda, for example.
Maybe:
/
/doc/
/doc/en/
/doc/en/<pkg1>/
/doc/po4a/
/doc/po4a/add_<ll>/
/doc/po4a/<pkg1>/
/doc/po4a/<pkg1>/po4a.cfg
/doc/po4a/<pkg1>/po/
/doc/<ll>/
/doc/<ll>/<pkg1>/
Does it represent your opinion?
Mostly yes.
BTW, there are currently 17 packages which build-depend on po4a:
adduser, apt-build, apt-proxy, apt-show-versions, base-passwd,
belocs-locales-bin, debarchiver, debhelper, deborphan, debsums,
devscripts, fakeroot, glibc, mailliststat, pppconfig, smb2www, squashfs
dpkg (soon in experimental)
apt, aptitude and debianutils may also switch
and defoma, menu (switches made and sleeping in the BTS)
Valéry Perrin promised me to make the switch for man-db
debconf will switch in a few days, once Cyril Brulebois has finished to
update the French translation (the patch is nearly ready).
And maybe some others.
About the README.maintainers:
* I have made a few minor corrections, but I'm not a native-speaker, just
as you, so my corrections may be wrong :-)
* Sentences added about the autoconf check
* Sentences added for distribution-specific build systems. I really
think that using po4a should not depend on the distribution, so the
use of debian/rules is a mistake.
* I'm not sure about this paragraph:
We recommend to use a configuration file with po4a that does not require
any option (put the options in the configuration file).
This permits to easily check that the POT is up-to-date with the
documentation and that the
Unless the missing end of the sentence is really convincing, IMO, the
use of external options is not a problem, and may ease the portability
of the configuration file.
As Denis said, translators should not care about the sources.
The document regeneration should be documented, so that it is as easy for
the translator to adapt the configuration file or the Makefile.
Cheers,
--
Thomas Huriaux
7:28 a.m.
New subject: [Po4a-devel] Re: po4a README.maintainers
On Sun, Feb 12, 2006 at 01:50:38PM +0100, Thomas Huriaux wrote:
Maybe:
/
/doc/
/doc/en/
/doc/en/<pkg1>/
/doc/po4a/
/doc/po4a/add_<ll>/
/doc/po4a/<pkg1>/
/doc/po4a/<pkg1>/po4a.cfg
I agree, and po4a.cfg could even be moved into /doc/po4a/po4a.cfg to
have only one cfg file.
Denis
6857
days inactive
6858
days old
4 comments
3 participants
participants (3)
-
Denis Barbier -
Nicolas François -
Thomas Huriaux