Mistakes in messages of util-linux-2.40-rc2

Mistakes in messages of util-linux-2.40-rc2

[Petr Pisar]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

Hello,

while translating util-linux-2.40-rc2 I notice a few messages which are, in my
opinion, incorrect:

> #: login-utils/lslogins.c:1461
> msgid " -p, --pwd                display information related to login by password.\n"

Other surrounding messages do end with the full stop charater. I recommend
removing it.

> #: misc-utils/lastlog2.c:117
> msgid " -S, --set               ySet lastlog record to current time (requires -u)\n"

"ySet" is a typo.

> #: misc-utils/lsblk.c:236
> msgid "write same max bytes, use <number> if --bytes is given"

There are multiple messages ending with "use <number> if --bytes is given".

I found the ", use" clause clumsy. Especillay the reference to "<number>".
I know it refers to an argument of the --bytes option, but it can be difficult
for users to realize it. Another issue I have is the same verb form of "write"
and "use". It takes time to realize "write" is a compound attribute of
"bytes", not a predicate.

I propose rephrasing it as "write-same max bytes, respect --bytes format".
Or "write same max bytes, respects --bytes format".

> #: misc-utils/lsfd.c:405
> msgid "extended version of MDOE (rwxD[Ll]m)"

"MDOE" should be "MODE".

> #: misc-utils/lslocks.c:92
> msgid "HOLDERS of the lock"

"HOLDERS" should be "holders". It's not a replacement word.

> #: misc-utils/waitpid.c:239
> #, c-format
> msgid "can't want for %zu of %zu PIDs"

"want" should be "wait".

> #: sys-utils/chcpu.c:208
> #, c-format
> msgid "CPU %u configure failed"

"configure" should be "configuration".

> #: sys-utils/irqtop.c:180
> msgid "cannot not create timerfd"

Duplicate "not".

> #: sys-utils/setpriv.c:135
> msgid " --rgid <gid|user>           set real gid\n"

"user" should be "group".

> #: term-utils/agetty.c:2466
> msgid " -J  --noclear              do not clear the screen before prompt\n"

There is missing a comma between the alternations of the option.

> #: term-utils/agetty.c:2471
> msgid " -N  --nonewline            do not print a newline before issue\n"

The same problem.

-- Petr


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Mistakes in messages of util-linux-2.40-rc2

[Benno Schulenberg]

[-- Attachment #1.1: Type: text/plain, Size: 1526 bytes --]


Op 26-03-2024 om 12:28 schreef Petr Pisar:
> while translating util-linux-2.40-rc2 I notice a few messages which are, in my
> opinion, incorrect: [ ...]

A patch for most of these issues is coming up.

Karel, would there be time for an rc3?  It wouldn't need to delay
things much: giving translators three or four days to update their
translations for these small changes should be enough.


>> #: misc-utils/lsblk.c:236
>> msgid "write same max bytes, use <number> if --bytes is given"
> 
> There are multiple messages ending with "use <number> if --bytes is given".
> 
> I found the ", use" clause clumsy. Especially the reference to "<number>".
> I know it refers to an argument of the --bytes option, but it can be difficult
> for users to realize it. [...]

If I read things correctly, the --bytes option takes no argument.
So to me the msgid makes zero sense.  :/

> I propose rephrasing it as "write-same max bytes, respect --bytes format".
> Or "write same max bytes, respects --bytes format".

What does "same" refer to?  "respects the --bytes option" would be a
good wording.

(As I don't understand what these descriptions are saying, I have not
touched them in my patch.)


>> #: sys-utils/chcpu.c:208
>> #, c-format
>> msgid "CPU %u configure failed"
> 
> "configure" should be "configuration".

Hm.  I think that this "configure" (and "deconfigure" further down)
refers to the --configure (and --deconfigure) "command".  So my patch
doesn't change those.


Benno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Mistakes in messages of util-linux-2.40-rc2

[Petr Pisar]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

V Tue, Mar 26, 2024 at 04:48:09PM +0100, Benno Schulenberg napsal(a):
> >> #: misc-utils/lsblk.c:236
> >> msgid "write same max bytes, use <number> if --bytes is given"
> > 
> > There are multiple messages ending with "use <number> if --bytes is given".
> > 
> > I found the ", use" clause clumsy. Especially the reference to "<number>".
> > I know it refers to an argument of the --bytes option, but it can be difficult
> > for users to realize it. [...]
> 
> If I read things correctly, the --bytes option takes no argument.
> So to me the msgid makes zero sense.  :/
> 
You are right.

> > I propose rephrasing it as "write-same max bytes, respect --bytes format".
> > Or "write same max bytes, respects --bytes format".
> 
> What does "same" refer to?

Same bytes.

The column simply prints a content of "write_same_max_bytes" file from sysfs.
That file is documented in Linux as:

    Some devices support a write same operation in which a
    single data block can be written to a range of several
    contiguous blocks on storage. This can be used to wipe areas on
    disk or to initialize drives in a RAID configuration.
    write_same_max_bytes indicates how many bytes can be written in
    a single write same command. If write_same_max_bytes is 0, write
    same is not supported by the device.

So write-same is a name of the operation.

-- Petr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Mistakes in messages of util-linux-2.40-rc2

[Karel Zak]

 Hi Benno and Petr,

On Tue, Mar 26, 2024 at 04:48:09PM +0100, Benno Schulenberg wrote:
> 
> Op 26-03-2024 om 12:28 schreef Petr Pisar:
> > while translating util-linux-2.40-rc2 I notice a few messages which are, in my
> > opinion, incorrect: [ ...]
> 
> A patch for most of these issues is coming up.
> 
> Karel, would there be time for an rc3?  It wouldn't need to delay
> things much: giving translators three or four days to update their
> translations for these small changes should be enough.

I need to release v2.40 today, it's already scheduled due to the end of
embargo for one CVE.

I guess we will have v2.40.1 very soon ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com