Re: Reasons to not use quote signs directly?
Hi!
On Sun, 2016-09-25 at 16:46:58 +0200, Helge Kreutzmann wrote:
> On Sun, Sep 25, 2016 at 04:21:31PM +0200, Guillem Jover wrote:
> > On Wed, 2016-09-21 at 01:59:10 +0200, Guillem Jover wrote:
> > > But I've found some quirks and issues that while not unsurmountable,
> > > might need to be looked at first and perhaps fixed or workarounds found
> > > to avoid "regressions", and I'm not sure which ones Russ would be happy
> > > to get bug reports for? :) I'm attaching a PoC conversion (can be tested
> > > with «pod2man deb-symbols.pod|man -l -», and is available also from [G])
> > > and here's a list of potential differences/issues:
> >
> > I've been playing with this a bit, converted few more pages and
> > updated the build infrastructure, and it might be workable after all.
> > One ideal goal would be to try to get as less fuzzied strings as
> > possible after a conversion. Here's a list of alternatives/workarounds
> > for some of the issues/differences:
Ok given your comments below, and your earlier comments, I think I
might go for an alternate solution, which I've tentatively implemented
locally, which would look like this:
* Rename all man pages to foo.man (from foo.1 or similar).
* Replace the 3rd and 4th arguments to .TH with placeholders for the
release-date and version, which will get replaced at build time,
for both English and translations. This should stop adding fuzzies
on date updates, as you'll just see something like @RELEASE_DATE@.
* Convert all roff escape sequences to proper UTF-8 for the English
and translations (po files); and map all of these back to escape
sequences at build time. So you'll have more readable input and
translations, and we'll have more portable generated man pages, as
they will be usable even on systems w/o proper UTF-8 support!
I'll take care of unfuzzing anything involved in the above. Hope this
sounds like a better plan for now? :)
> Thanks for your analysis. Given that we are closing in on a release my
> request is simple: Delay any update which causes (lots of) fuzzy
> strings just for formatting to the next cycle.
>
> The formatting updates are simply a pain for translators, and at least
> in the beginning of the cycle you can review them by pices. This late
> in the cycle you just are frustrated because many pages (which are
> translated looking at the content) are failing to translate because of
> formatting.
Right, I always feel between a rock and a hard place on this, because
due to translations I'm sometimes reluctant to do some kinds of changes
because they might seem like just churn, but at the same time I also
want to cleanup stuff. :/
> Automatic conversion might quite difficult, because each language has a
> different status, some (e.g. German) are current, some have already
> done the latest formatting changes, some only the second latest and
> some are really old. (Obviously, the last ones might be ignorable).
> And, of course, some might have blindly followed your formatting
> (which I did and now start to divert), some might have not or only
> partially …
I don't think a possible migration to use POD necessarily implies many
fuzzied strings, but I'll postpone any such thing for the next major
dpkg series.
Thanks,
Guillem
Reply to: