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=31... Status: Open Priority: 3 Submitted By: Michael Terry (mterry-guest) 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. :) ---------------------------------------------------------------------- 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=31...