> Well frankly, I prefer to handle that myself. This way I can decide a string
That doesn't scale, sorry. What will happen when you'll get more than 60 translations ? :-). Will you check each one and try to decide whether it is up-to-date or not to decide shipping it or not? What I can't figure out is whether you don't want to use po4a at all....or just avoid shipping PO files in your tarball. I actually don't care of the intermediate steps as long as we can guarantee that we have in Debian: -a convenient file for translators to work on: PO files are convenient, manpages aren't -always up-to-date files If you can add to this a convenient way to ship tarballs with up-to-date manpages to other vendors, that's fine. > Yes, but given the current state of the English manpages, does it worth > the trouble ? I don't mind the French translation since I can fix both > the English and French at once. > > If the manpages are important enough to be translated, they must probably > be rewritten first. Which I am doing slowly, but I am not a good English > writer anyway. Manpages are always important. And translated manpages are important *as long as they are up-to-date*. The usual objection against translated manpages is that they're often outdated...which is true with a manual translation system. Using po4a guarantees that the translated manpage remains up-to-date because changed strings fuzzy the translations and are not used. This may result in a translated manpage which is a mix of English and another language....which you can decide not shipping with your package with a special case of the build system. So, again, are you completely ruling out po4a in either the package build system or the "upstream" tarballs build system?
