Hey Bill ! Sorry for the delay I'm currently in vacation with sparse net access.
Bill Allombert wrote: > 1) po4a-normalize replace - by \- even then this does not seem > warranted. > 2) po4a-normalize end every lines by a space. > 3) po4a-normalize sometimes reformat paragraph in a less than optimal > ways. > > 1. and 2. are problematic when reviewing what changes po4a-normalize did, > though 2. can be mitigated by using diff -ub. 3. cause generated manpages > to not be acceptable as master version. I think this bug is the result of some sort of misunderstanding between us. That may be the price for three frogies to try to collaborate in english ;) (1) is actually a good option since misusing - instead of \- is a common error of manpage authors. This is really annoying to UTF users, ie translation users... (2) and (3) discuss the groff code generated by po4a. I'd say that it's out of the topic. We didn't designed po4a to produce beautiful source code, but to not mess up with the rendered pages. We target the users of translations, not the manpage authors. On Sat, Apr 22, 2006 at 01:47:00AM +0200, Bill Allombert wrote: > Any formating improvement po4a might bring will be lost in the English > version if I don't use po4a-normalize, so there are little advantage to > make them to the translated version anyway. You must be kidding. You are trying to (mis)use po4a to improve your english original, and since it doesn't fit your needs, you discard its primary goal: translating man pages. If we convinced you that \- should be prefered over -, please do fix your original pages, that's not of our business. That's where I see the misunderstanding here. When a potential user express issues with po4a-normalize, I do feel sorry for distributing this tool in the first place. Let me quote its documentation: The "po4a-normalize" script is a debugging tool used to make sure that po4a don't change the document when it's not supposed to. Only use it if you're developing a new module, or if you doubt the sanity of the tools. So, I think that you didn't understand what's the purpose of po4a and how original documentation authors are supposed to use it (no offense intended of course). If I am right, you may find po4a(7) interesting. In the case where you were using this script to check the effects of po4a and whether your original formating will be preserved, you took the wrong target. Indeed, you don't care about the source code beauty of the french page since you'll never modify it manually in the po4a workflow (presented graphically in po4a(7)). Check the rendered page instead. In the po4a cvs, there is a 'testsuite' directory containing scripts doing exactly that. For all installed manpages, they compare the original man page to a gettextized and renormalized page. They do not do so sourcewise, but use groff to render both before. But I think that you can trust the tool on this one: as stated in Locale::Po4a::Man(3pm), we regularly run the test, and po4a only offers suboptimal support (read "bugs") less than 1% of the pages. We are working on them ;) So, in summary, that's true that po4a tries to improve the groff formating when it cans, but the main goal is the rendered pages, not the source code. Don't use it as "source fixer", he's bad at it. But that's not a bug since it's not what it is designed for. > Unless po4a point 3. is improved I am not going to use it. as "source fixer", you mean. > Such tools should either respect entirely the original formating, or reformat > nicely its output. I completely agree. But a lint for groff source code is still to be invented ;) The only thing I can do to fix this bug is to not distribute po4a-normalize anymore. Is it what you want or can I close this bug as is? Bye, Mt.
signature.asc
Description: Digital signature
