po4a-Bugs item #311648 was changed at 06/02/2018 17:30 by Martin Quinson You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=410622&aid=31... Priority: 3 Submitted By: Michael Terry (mterry-guest) Assigned to: Nobody (None) 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: 06/02/2018 17:30 Message: Hello, this request is partially covered by existing tools, and initial requester did not comment on the remarks, almost 10 years ago. I thus doubt that there is many interest in migrating this to github. If you disagree, please reopen a bug on github. Meanwhile, I close this one. Thanks, ---------------------------------------------------------------------- Comment By: Martin Quinson (mquinson) Date: 27/03/2017 18:11 Message: Hello, what you are trying to do can be achieved by using po4a-translate and po4a-updatepo directly, I guess. I do not plan to work on implementing your proposal myself, but if you come up with a simple and well tested patch, I will certainly integrate it. Thanks, Mt. ---------------------------------------------------------------------- Comment By: Neil Williams (codehelp) Date: 16/11/2009 23: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...