Hello Guilllem,
Am Tue, Jul 30, 2024 at 07:10:57AM +0200 schrieb Guillem Jover:
> On Mon, 2024-07-29 at 10:29:05 +0000, Helge Kreutzmann wrote:
> > while working on the German translation, I spotted some potential
> > errors, could you review them?
> >
> > scripts/dpkg-gencontrol.pl
> > " -O[<file>] write to stdout (or <file>), not .../DEBIAN/"
> > reall 3 (three) dots?
>
> Yes, this tries to represent an undefined prefix pathname, and would
> usually be written as «…/DEBIAN/control» in a UTF-8 locale for
> example. I was looking into adding a TRANSLATORS marker, but the
> current code makes that cumbersome. I guess ideally once/iff I end up
> splitting each --help option description into its own string, to avoid
> the massive msgids, then I could add that marker.
I see, thanks for the explanation.
> > deb-src-control.pod
> > "the name of the source package in the debian/changelog file. A package name "
> >
> > Should "debian/changelog" be in italics?
>
> I've got a couple of branches either marking many files with F<> or I<>,
> I think the main problem was that in the docs, bold text is used to
> represent literal strings (including pathnames), and italics are also used
> to represent replaceable text, but if pathnames use F<> or I<> then
> that distinction becomes hard to make.
Global reformatting is a PITA for translators, so only make them when
you are 100% sure.
And yes, convention has italics for both file names and replacable
text, which is ambiguous, but in practice as translator I see hardly
problems with it.
> I guess I could look into merging the parts of those patches that mark at
> least all pathnames that have no replaceable text to at least make
> them have some uniform markup.
Yes, of course, if some paths contain replacable text then this could
be tricky.
> > dpkg-buildpackage.pod
> > "file has been specified it unpacks it anew and changes directory to it, if a "
> > "I<directory> has been specified it changes directory to it, otherwise it "
> >
> > "changes directory to it" is written twice?
>
> Yes, because in both cases it will change to it, but not for the case
> where it expects the current directory to already contain the source
> tree. I'm not sure how this could be refactored to avoid the duplication
> while not making it confusing. If you have suggestions, I'm happy to
> modify the text, which is currently:
>
> If a B<.dsc> file has been specified it unpacks it anew and
> changes directory to it,
> if a I<directory> has been specified it changes directory to it,
> otherwise it expects the current directory to contain the source tree.
I see, I'll review my translation if it is correct.
> > dpkg.pod
> > " dpkg -i /media/bdrom/pool/main/v/vim/vim_9.0.2018-1_amd64.deb\n"
> >
> > Is this really "bdrom" or should this be "cdrom"?
>
> This was meant as a modernization of the term, away from CDs which
> are rarer as time goes, and to go into Blu-Ray ROM discs, so bdrom discs.
Ok, I see. While "CDROM" is still a term common to me, "BDROM" is not,
so I expected a typo (C and D are close on my keyboard).
> Perhaps I could modify the previous paragraph to try to clarify this,
> like:
>
> To install a package, you first need to find it in an archive or
> media disc (such as a Blu-Ray ROM disc).
> ^-- new --^
> When using an archive based on a pool structure,
> knowing the archive area and the name of the package is enough to infer
> the pathname:
>
> =over
>
> dpkg -i /media/bdrom/pool/main/v/vim/vim_9.0.2018-1_amd64.deb
>
> =back
>
> ?
Possibly.
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: PGP signature