[Please CC me as I am not subscribed on the list]
I am working on some docbook which has a list of items:
<seg>Disk Usage Change</seg>
Which generates this msgid of interest:
#. type: Content of:
#: en/aptitude.xml:7233 en/aptitude.xml:7293 en/aptitude.xml:7384
In some locales the translation of "30" is different for each of these
items. For example, German should use "30" for the first but "29" for
the second. Is there some way to generate a unique msgid for each of
those seg tags? I have tried using ID attributes:
but this does not work.
Any help with this would be greatly appreciated.
Le 14/05/2012 19:50, Roger Leigh a écrit :
> I've been working on #588962 to implement po4a for the schroot
I guess you actually meant:
> - I'm getting a "translated" directory in both the source
> directory and build directory
> (man/translated/fr and debian/build/man/translated/fr).
> It's a bug to dirty the source tree--I really only want
> them generating in the build tree.
> I set srcdir and destdir, but I'm not sure if I'm doing the
> right thing (see: man/Makefile.am update-po rule).
I can't see what's wrong at first sight, adding the po4a-devel list in
the loop in case we're missing something. The actual call is:
[ -n "$(PO4A)" ] && $(PO4A) --package-name $(PACKAGE) --package-version
$(VERSION) --copyright-holder "Roger Leigh <rleigh(a)debian.org>"
"--srcdir=$(srcdir)" "--destdir=$(builddir)" "$(srcdir)/po4a.cfg"
Indeed, simply running “po4a --destdir=../debian/build/man/ po4a.cfg”
from the man directory builds everything where expected (even with
“--srcdir=.”), but when run from the root directory, it builds them in
both the --srcdir and the --destdir, so it may be a bug in po4a. As a
workaround, you could remove the sloppy man/translated directory in the
update-po rule, after the po4a call.
> - The fr manpages are output in UTF-8. The man program results
> in readable output, but the PDF/PS documentation looks awful
> due to lots of junk in the output.
> While UTF-8 is fine in the .po file, would recoding to latin1
> or into groff symbols for non-ASCII characters be feasible?
Charset of the files containing the localized documents can be change
with the -L option of po4a, but, there is better:
> Or can groff now process UTF-8 input?
“groff -k -KUTF-8” seems to do the work quite nicely.