Polish man pages broken again in po4a 0.37
by Robert Luberda
Hi,
The Polish man pages generated from POD are unreadable, e.g. (from
Locale::PO4A::Man(3), please also note its strange header, but this
is another problem):
_build::pod::3::pUseriC_build::pod::3::pl::lib::Locale::Po4a::Man(3)
NAZWA
Locale::Po4a::Man - Konwersja stron podrAeXcznika z/do
plikA~Xw PO
OPIS
Celem projektu po4a ("po for anything") jest uAaXatwienie
tAaXumaczeAaX (oraz, co ciekawsze, zarzAeXdzania
tAaXumaczeniami) przy uAaXyciu narzAeXdzi gettext w tych
obszarach, gdzie nie byAaXy uAaXywane, jak na przykAaXad w
obszarze dokumentacji.
The problem seems to be caused by po4a-build not passing --utf8 to
pod2man, and by po4a, which doesn't include any `==encoding' line in
translated PODs.
I was able to work-around this in po4a-build by defining a following
simple pod2man function there, and then rebuilding po4a:
pod2man()
{
i=`expr $# - 1`
file=`eval echo '$'$i`
case $file in
*_build*)
sed -e '1,/=head1/s/=head1/=encoding
UTF-8\n\n&/' $file > $file.tmp
cp $file.tmp $file
/usr/bin/pod2man --utf8 "$@"
;;
*)
/usr/bin/pod2man "$@"
;;
esac
}
Regards,
robert
14 years, 8 months
Duplication with po4a-build
by Neil Williams
There is an intrinsic problem in po4a-build to do with source packages
that build a lot of binary packages. The manpages are generated for
each binary package, which causes duplication.
Without refactoring po4a-build in perl (which might happen eventually),
one way to handle this is to remove the duplicate with a CLEAN= value
in the conf file. That wastes build time but prevents the packages
containing the same files in the same locations.
(This came as a result of testing with emdebian-grip - for now, I'm
going to stick with only translating the script output of those
packages.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
14 years, 10 months
Error on 0.37 translated manpages
by Omar Campagne
Hello everybody:
0.37 just hit the repos, so I downloaded it, and I've encountered some
issus in the manpages :(
[1]
My system is en_US, so I use "LANG man". Upon viewing the manpages with
man, they look as if nroff markers (i.e. its weird accents) appear
untransformed.
Maybe it's just me, but it also happens if I do
nroff -man file
on the cvs source generated manpages.
[2]
Another issue is that "LANG es_ES.utf8 man po4a-build" still reveals the
original manpage. nroff -man on the translated/built po4a-build.1 file
shows contents in English.
[3]
One last thing is that, since manpages "changed" section (3pm -> 3), you
may still get both versions unless you trigger "#mandb" after
installation.
Anyway, the trigger man-db in aptitude install process doesn't clean,
but add manpages in my system.
Since 3pm are now "outdated", to which manpage does the
system default if users don't trigger mandb? This issue might be just
me, *seriously*, my Debian sometimes doesn't "refresh" random stuff.
I realized last thing with "man -k".
Sorry if I brought you down guys :-) I'll try to use more the BTS in the
future for these kind of issues. Just thought this might involve a
trivial change in a script or conf file (I'm clueless with build
scripts) and this way is faster.
Anyway, no big deal for the user, just a temporary inconvenience :)
Best regards, Omar
--
"Why stop now just when I'm hating it?" -- Marvin The Paranoid Android
14 years, 10 months
0.37.0 released
by Neil Williams
po4a, including the new po4a-build script, has been released and po4a
(0.37.0-1) has been uploaded to Debian. This release also includes a
fully updated Spanish translation, including the new po4a-build
documentation, thanks to Omar Campagne.
po4a-build will be used as a build-dependency by emdebian-rootfs and
svn-buildpackage (both due to be released in a couple of days). Feel
free to try it out with any package that builds translated
documentation, *especially* if it also builds binary gettext
translations of program output without using autotools, e.g. perl
scripts using $(MAKE) but not ./configure.
This should be a useful step in encouraging more packages to translate
their script output and manpages. It is trivial to add translation to
packages using the full autotools|intltool setup, now po4a-build brings
the same level of ease to packages only using $(MAKE). (If someone
wants to investigate how CMake can do the same, let me know.)
http://alioth.debian.org/projects/po4a/
http://alioth.debian.org/frs/download.php/3183/po4a-v0.37.0.tar.gz
http://freshmeat.net/projects/po4a/releases
(0.37.0 announcement pending approval by FM)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
14 years, 10 months
Only translating specific XML tags
by Francois Gouget
I have an XML file I'd like to translate. It has quite a few tags, but
only two or three of them should be translated. But it appears that I
will have to specify every single tag I don't want to see translated
To test this I have written a small test file, where <name> is the only
tag that should be translated:
<?xml version="1.0" encoding="UTF-8" ?>
<root>
<global>
<name>To be translated</name>
<other>foo</other>
<yetother>bar</yetother>
</global>
</root>
So I thought that something like this would work:
po4a-gettextize -f xml -m test.xml -o 'translated=<name>'
But that still produces a po file that includes every string. What's the
point of the 'translated' option then since all tags are included by
default anyway?
I also tried 'tagsonly=<name>' but it's deprecated and just produced an
empty po file anyway.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Hiroshima '45 - Czernobyl '86 - Windows '95
14 years, 10 months
Putting multiple translations in an XML document
by Francois Gouget
So I'm still with my XML file I'd like to translate and I have another
issue with it, which is quite independent.
The thing is I'd like to have all the translations in one file so I can
then ship just this one file and the application using the file would
then pick the right locale.
So starting from my test file:
<?xml version="1.0" encoding="UTF-8" ?>
<root>
<global>
<name>To be translated</name>
<other>foo</other>
<yetother>bar</yetother>
</global>
</root>
I would like to get:
<?xml version="1.0" encoding="UTF-8" ?>
<root>
<global>
<name>To be translated</name>
<name lang="fr">A traduire</name>
<name lang="de">de--To be translated--de</name>
<other>foo</other>
<yetother>bar</yetother>
</global>
</root>
That does not seem to be doable with the standard XML module or any
other. I guess that means I should code my own. I'm a bit worried the
infrastructure is not geared towards that kind of use though. For
instance po4a-translate does not expect to be given multiple po files.
Is there some code that does something similar and that I could use as a
model?
The only other similar case I can think of is the .desktop files, but as
far as I can tell they are not supported by po4a and are not XML either.
This new module could probably be made pretty general: take a tag and
duplicate it, adding a lang attribute with the proper value. Ideally one
would use a copy of the file with no translation at all as the source to
avoid confusion. I don't know if anyone else would be interested in such
a module though.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
14 years, 10 months
po4a 0.37.0 release
by Neil Williams
I'm ready to do a po4a release (0.37.0) including po4a-build in a few
days.
Shall we have a call for translation updates before the release? Only
es.po is up to date currently. Or make the release and then the call
and a release of 0.37.1 containing the translation updates?
(I'd like to get 0.37.0 out so that I can use po4a-build as a
build-dependency of two other packages.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
14 years, 10 months
[po4a-Bugs][311648] Integrate tightly with a package's existing po files
by po4a-bugs＠alioth.debian.org
Bugs item #311648, was changed at 2009-05-03 14:12 by Neil Williams
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=410622&aid=311648&gro...
Status: Open
Priority: 3
Submitted By: Michael Terry (mterry-guest)
>Assigned to: Neil Williams (codehelp)
Summary: Integrate tightly with a package's existing po files
Category: None
Group: None
Resolution: None
Initial Comment:
I recently converted my project's documentation to use po4a. It was great, thanks for the software.
However, I wanted to avoid having two gettext domains and used a bit of Makefile magic to make it happen. You can read about it here: http://mterry.name/log/2009/05/02/translate-your-documentation/
It would be nice if there was a mode for po4a where more of that would happen automatically.
* The ability to read po files without also writing to them
* The option to merge the resulting pot file with another
* The ability to read the language list from po/LINGUAS
In addition, it would be nice if po4a shipped some m4 macros to make writing Makefile integration easier. Stuff like installing the translated man pages, etc. Together with the above, it means I could just have something like "PO4A_MAN_PAGES = one.1 two.1 three.1" and everything would just happen within my existing translation framework.
The tricky part would be filtering out the messages again when making the dist tarball (see blog post above). But I'd be happy even if that weren't included, since that's pretty hacky. :)
----------------------------------------------------------------------
>Comment By: Neil Williams (codehelp)
Date: 2009-11-16 22:28
Message:
Elements of what you requested are part of the po4a-build changes currently being tested. Rather than m4 macros, I've gone for a Makefile snippet based on how autotools and intltool handle the typical po/Makefile.in.in symlink.
As for having two domains, I actually think it's useful - the script output messages and the documentation messages are orthogonal. Yes, it's nice to have both translated into the the same languages but putting all strings into one PO file (as a result of having one POT file) does have drawbacks:
1. The much larger % of strings from the documentation "swamp" the output strings, unless you use 'po4a -k 0', you risk losing the script output strings even if (it the separation had been retained) the output strings are at 100%
2. The output translations must be handled separately at runtime anyway. The script output goes into /usr/share/locale/ as binary files. The documentation output goes into /usr/share/doc/ as plain text, generally. In situations (like embedded environments) where a division is desirable, putting output and docs strings in one PO file causes aggravation. If the script output strings and doc strings are in one PO file, where does the resulting translation get installed?
po4a already has ways of merging all POT content for all docs - po4a-build enhances that. po4a-build does indeed use simple KEY=VALUE config lines and does allow "everything to just happen within the existing *docs* translation framework".
Take a look at po4a-build (currently in CVS, to be released as 0.37.0) and if it meets your needs, close this bug. If necessary, open new ones for features still missing.
----------------------------------------------------------------------
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=410622&aid=311648&gro...
14 years, 10 months
po4a-build is ready for testing . . .
by Neil Williams
OK, I've made the change to po4a-build and fixed the errors that I
found as I went. po4a-build has 14 translatable strings, plus the
manpage (which needs considerable extension, my next task) and the
other script manpages (po4a-mandisplay-po and po4apod-display-po) also
need translation.
The XML content has been folded into po/pod/po4a-pod.pot and the shell
script output for po4a-build has been folded into po/bin/po4a.pot.
The new build system seems to be OK - it builds cleanly and I've added
the necessary build-deps for chroot builds from the distributed
tarball. Chroot builds directly from CVS are still problematic - the
deps added make no difference to the test failures on my laptop.
(All were already installed) :-(
I'm now going to install 0.37.0-1 locally and continue testing with
svn-buildpackage and emdebian-rootfs using po4a-build externally; each
will then get a build-dep on po4a (>= 0.37.0) at the next upload after
po4a itself is released.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
14 years, 10 months
Current CVS fails in a chroot
by Neil Williams
The latest t/20-sgml.t tests (and a few others) fail if po4a itself is
not installed. (PERLLIB=lib needed?)
It looks like docbook is essential to running make dist too. Is there a
definitive list of packages needed to build from CVS? (Should have that
in ./README.cvs or similar.)
I'm missing at least one package on this laptop because po4a CVS
doesn't build even outside the chroot.
A version of 0.36.6 does build:
$ head changelog
2009-11-07 Omar Campagne <ocampagne(a)gmail.com>
* po/pod/es.po: Updated to 1248t.
After installing po4a and docbook inside the chroot, 'make dist' fails
with a latex test - not sure which of the dozens of latex packages
would be needed. I've got texlive-latex-base.
With texlive-latex-base, current Debian source for 0.36.6 builds the
tarball OK but CVS is still broken.
t/22-html.t ........... Unknown format type: html.
What packages do I need to be able to run 'make dist' (and also the
full 'make check') inside a clean chroot?
There's obviously something missing between this laptop and my main
machine - I just can't work out what.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
14 years, 10 months