bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26621: hint for translators is missing from POT file, but is opaque


From: Benno Schulenberg
Subject: bug#26621: hint for translators is missing from POT file, but is opaque anyhow
Date: Thu, 27 Apr 2017 19:41:12 +0200

On Tue, Apr 25, 2017, at 03:20, Paul Eggert wrote:
> On 04/24/2017 12:57 PM, Benno Schulenberg wrote:
> > (Also, when dd is done copying records, the USB stick isn't
> > ready yet:
> 
> You might need to use 'eject' on the stick before unplugging it. Perhaps 
> dd should have an option to eject the output when done?

That might be useful, but in practice I don't need it: as soon
as dd actually exits, my system detects that something new has
appeared on its USB port and automatically mounts it and opens
a file browser there.  I check that the stick now contains what
I expected to see, and then click unmount in the file browser.


> > /* TRANSLATORS: The translations of the next three msgids should
> > be of ascending length.  That is: each subsequent msgstr should be
> > longer than the preceding one. */
> 
> That's not technically correct, as the msgstr length itself is not 
> directly relevant; what matters are the numbers of bytes and columns in 
> the formatted output.

But how is a translator supposed to know exactly which numbers
can occur with what msgstr?  The translator is not going to change
the PRIuMAX, and all the other things are %s.  What length can they
have?  The translator is not going to analyze the whole program.
And he shouldn't need to.  It should be the program's responsibility
to present its output in a way that it can't get messed up.

> To some extent this translator note is pedantic, as translations are 
> quite likely to have the desired property

If the note is pedantic, then please leave it out.  Such notes are
meant to clarify things, so that the translator doesn't need to look
at the code in order to understand what a message means or in what
context it occurs.  If all the note says is to look at a comment in
the code, this is annoying.  And as that comment is incomprehensible,
it is useless.

But, since now the normal progress message contains the time with
a whole-second resolution, I suggest to split up the message again
and to properly pluralize it.

Depending on the prefix:

    ngettext ("%"PRIuMAX" byte copied",
              "%"PRIuMAX" bytes copied",
              select_plural (w_bytes), ...);
OR
    ngettext ("%"PRIuMAX" byte (%s) copied",
              "%"PRIuMAX" bytes (%s) copied",
              select_plural (w_bytes), ...);
OR
    ngettext ("%"PRIuMAX" byte (%s = %s) copied",
              "%"PRIuMAX" bytes (%s = %s) copied",
              select_plural (w_bytes), ...);

followed by

    ngettext (" in %.0f second -- %s/s",
              " in %.0f seconds -- %s/s",
              select_plural (time_in_second_resolution), ...);

If the entirety of that output can have a varying width
that sometimes gets shorter than it was before, then dd
should first print that output to a string, record its
longest length, and then always fill up the string with
spaces to that length.  dd should do the work, not the
translator.

Benno

-- 
http://www.fastmail.com - Access all of your messages and folders
                          wherever you are






reply via email to

[Prev in Thread] Current Thread [Next in Thread]