During the recent proofreading we discovered some possible
improvements to the original pages as well, which I list for you to
consider and implement (where you agree):
# bug report numbers → bug report numbers of bugs
#. type: Plain text
#: deb-changes.man
msgid ""
"A space-separated list of bug report numbers that have been resolved with " "this upload. The distribution archive software might use this field to " "automatically close the referred bug numbers in the distribution bug " "tracking system."
# libgcc → B<libgcc> or quotes?
#. type: Plain text
#: deb-src-symbols.man
# markup of "eval"?
#. type: Plain text
#: dpkg-architecture.man
msgid ""
"Print an export command. This can be used to set the environment variables " "using eval."
# apt → B<apt>
#. type: Plain text
#: dselect.man
# Why is this bold but not the others?
#. type: TP
#: dpkg-buildflags.man
#, no-wrap
msgid "B<lfs>"
# debian/changelog → I<debian/changelog>
#. type: Plain text
#: deb-src-control.man
# debian/chagelog → I<debian/changelog>
#. type: Plain text
#: dpkg-gensymbols.man
# debian/changelog → B<debian/changelog>
#. type: Plain text
#: dpkg-mergechangelogs.man
And in general, sometimes file names are marked up, sometimes not.
On Tue, 2020-05-05 at 21:09:05 +0200, Helge Kreutzmann wrote:
# bug report numbers → bug report numbers of bugs
#. type: Plain text
#: deb-changes.man
msgid ""
"A space-separated list of bug report numbers that have been resolved with "
"this upload. The distribution archive software might use this field to " "automatically close the referred bug numbers in the distribution bug " "tracking system."
I think the original is correct here. This is a list of bug-report
numbers. Maybe hyphenating here would make this more clear? Otherwise
could you say what seems wrong?
# Why is this bold but not the others?
#. type: TP
#: dpkg-buildflags.man
#, no-wrap
msgid "B<lfs>"
Hmm the other feature names are in bold too. Or are you referring to something else here?
Right, I've got an unfinished patch laying around fixing pathnames to
be in italic, but I think I'll postpone this one for now until the
switch to POD, so that I can use F<> instead of I<>. There's also the
problem with pathnames that contain variable parts, which up to now
were represented as B</some/pathname/>I<variable-part>B</rest>, and
with all pathnames in italics gets rather cumbersome.
I'll push later today.
On Sat, May 09, 2020 at 10:19:18PM +0200, Guillem Jover wrote:
On Tue, 2020-05-05 at 21:09:05 +0200, Helge Kreutzmann wrote:
# bug report numbers → bug report numbers of bugs
#. type: Plain text
#: deb-changes.man
msgid ""
"A space-separated list of bug report numbers that have been resolved with "
"this upload. The distribution archive software might use this field to "
"automatically close the referred bug numbers in the distribution bug " "tracking system."
I think the original is correct here. This is a list of bug-report
numbers. Maybe hyphenating here would make this more clear? Otherwise
could you say what seems wrong?
Well, you don't resolve bug report numbers, you resolve bugs. So the
list is of course the numbers, but afterwards you actually close the
bugs themselves.
# Why is this bold but not the others?
#. type: TP
#: dpkg-buildflags.man
#, no-wrap
msgid "B<lfs>"
Hmm the other feature names are in bold too. Or are you referring to something else here?
In the po file the others are not all bold:
msgid "qa"
…
msgid "B<bug>"
…
msgid "B<canary>"
…
msgid "sanitize"
…
and so on. I suppose they all should be bold?
Right, I've got an unfinished patch laying around fixing pathnames to
be in italic, but I think I'll postpone this one for now until the
switch to POD, so that I can use F<> instead of I<>. There's also the problem with pathnames that contain variable parts, which up to now
were represented as B</some/pathname/>I<variable-part>B</rest>, and
with all pathnames in italics gets rather cumbersome.
I see.
Hopefully the transition to pod keeps the fuzzy strings to a minimum.
after your recent push the man pages no longer build, i.e.
git clean -d -X -f
autoreconf -f -i
./configure
make -C man update-po
fails with:
Fehler: »msginit -i po/dpkg-man.pot --locale add_de -o ?po/de.add --no-translator« endete mit dem Wert 1.
If I remove the "?", this line suceedes:
helge@samd:/tmp/dpkg/man$ msginit -i po/dpkg-man.pot --locale add_de -o po/de.add --no-translator
po/de.add wurde erstellt.
I'm workin on stable, if this matters.
On Tue, 2020-05-12 at 19:42:02 +0200, Helge Kreutzmann wrote:
after your recent push the man pages no longer build, i.e.
git clean -d -X -f
autoreconf -f -i
./configure
make -C man update-po
fails with:
Fehler: »msginit -i po/dpkg-man.pot --locale add_de -o ?po/de.add --no-translator« endete mit dem Wert 1.
If I remove the "?", this line suceedes:
helge@samd:/tmp/dpkg/man$ msginit -i po/dpkg-man.pot --locale add_de -o po/de.add --no-translator
po/de.add wurde erstellt.
I'm workin on stable, if this matters.
Hmm, right that would not work entirely. :/ The latest po4a release
changed the default for the --porefs option, and removed the old way
to change that default, so code that changed the default cannot
specify it in a way that is backwards compatible. This should mostly
affect wrapping, so I guess I could also relax the Build-Depends, but
I assume we'll get flip-flops in the .po depending on where it got
updated.
I'm also wondering about the addenda, which I refactored to specify
them only once in the config, but that only works in testing/sid. We
removed references to man page authors some time ago, so was
considering whether to do the same for the addenda and remove them to
match the upstream part, which would also remove that problem entirely.
Not sure how that would fly with translators though?
On Fri, May 15, 2020 at 02:57:28PM +0200, Guillem Jover wrote:
On Tue, 2020-05-12 at 19:42:02 +0200, Helge Kreutzmann wrote:
I'm workin on stable, if this matters.
Hmm, right that would not work entirely. :/ The latest po4a release
changed the default for the --porefs option, and removed the old way
to change that default, so code that changed the default cannot
specify it in a way that is backwards compatible. This should mostly
affect wrapping, so I guess I could also relax the Build-Depends, but
I assume we'll get flip-flops in the .po depending on where it got
updated.
Ok, then I run this in a sid chroot.
I'm also wondering about the addenda, which I refactored to specify
them only once in the config, but that only works in testing/sid. We removed references to man page authors some time ago, so was
considering whether to do the same for the addenda and remove them to
match the upstream part, which would also remove that problem entirely.
Not sure how that would fly with translators though?
I would rather keep the translators, because when translation issues
arise they should be known as first point of contact.
Also translation
is a significant effort often overlooked so having the names there is
also a way to acknowledge that effort and saying "thank you".
(And except this hopefully temporary issue the maintenance effort for
your side is almost zero).
On Fri, 2020-05-15 at 22:04:36 +0200, Helge Kreutzmann wrote:
On Fri, May 15, 2020 at 02:57:28PM +0200, Guillem Jover wrote:
On Tue, 2020-05-12 at 19:42:02 +0200, Helge Kreutzmann wrote:
I'm workin on stable, if this matters.
Hmm, right that would not work entirely. :/ The latest po4a release changed the default for the --porefs option, and removed the old way
to change that default, so code that changed the default cannot
specify it in a way that is backwards compatible. This should mostly affect wrapping, so I guess I could also relax the Build-Depends, but
I assume we'll get flip-flops in the .po depending on where it got updated.
Ok, then I run this in a sid chroot.
I've improved this now in master, and the --porefs value will be
selected based on what is needed, so it should be safe to run it on
stable again.
I'm also wondering about the addenda, which I refactored to specify
them only once in the config, but that only works in testing/sid. We removed references to man page authors some time ago, so was
considering whether to do the same for the addenda and remove them to match the upstream part, which would also remove that problem entirely. Not sure how that would fly with translators though?
I would rather keep the translators, because when translation issues
arise they should be known as first point of contact.
Ok, that makes sense. More so because with the switch to POD, the
copyright header (for now) does not end up in the generated man pages,
so even checking the source would not give any such indication.
Also translation
is a significant effort often overlooked so having the names there is
also a way to acknowledge that effort and saying "thank you".
Oh I'm completely aware, I've done translation stuff too and I know
it's an endless ton of work and time, so please do not take this as undervaluing that work!
I also think documentation is important, but personally I tend to find
AUTHOR sections in man pages distracting (even when I'm one of them :).
First because it's usually not clear whether this is about the
program or the man page, then because it tends to get out of sync with
the copyright header, and finally because it feels like details that
if interested in can be checked in the source code.
(And except this hopefully temporary issue the maintenance effort for
your side is almost zero).
Sure, it's not a big deal, and I'm fine with keeping them, so let's do
that then.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 16:05:29 |
| Calls: | 6,646 |
| Calls today: | 1 |
| Files: | 12,190 |
| Messages: | 5,327,107 |