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

[Assaf Gordon]

tags 26621 fixed
close 26621
stop

(triaging old bugs)
Pushed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=7ea15a57c7a8b876daa3d4d01f1192af3f58f3c7
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=d1f5616b2d9b851298f377ae7888b2d718802140

So closing as "fixed".

-assaf

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

[Benno Schulenberg]

On Mon, Apr 24, 2017, at 09:38, Paul Eggert wrote:
> Benno Schulenberg wrote:
> > It would be nicer to use a fixed number of
> > decimals so that the message doesn't unnecessarily "jump".
> 
> Yes, and since the messages you're talking about are supposed to come out 
> once a 
> second, dd should just omit everything after the decimal point.

Well, in the past week I have been writing several ISO images
to a USB stick, and dd's progress messages first come out at
about 1.1 second intervals, then slow down to about every four
or five seconds, and after about a minute start to arrive again
at close to every 1.0 seconds.

(Also, when dd is done copying records, the USB stick isn't
ready yet: it continuous blinking for nearly a minute, but dd
sits there as if nothing is happening.  I don't know if this is
feasible, but it would be nice if dd would continue to count up
the seconds, and slowly reduce the transfer rate.)

> Thanks for your other comments. I installed the attached patch, which I hope 
> addresses them.

Okay.  If I understand the new comment well, I would have written:

/* 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. */

Benno

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
  love email again

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

[Paul Eggert]

On 04/24/2017 08:23 AM, Bernhard Voelker wrote:

Yes, and since the messages you're talking about are supposed to come out
once a second, dd should just omit everything after the decimal point.

Not quite - you can still get them with 'kill -USR1 $pid'.


In current master "kill -USR" messages use %g, as the signal might 
arrive at any time. %.0f is used only by ordinary status=progress 
messages, which are as close to the 1-second boundaries as can be arranged.

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

[Bernhard Voelker]

On 04/24/2017 09:38 AM, Paul Eggert wrote:
> Yes, and since the messages you're talking about are supposed to come out
> once a second, dd should just omit everything after the decimal point.

Not quite - you can still get them with 'kill -USR1 $pid'.

Have a nice day,
Berny

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

[Paul Eggert]

Benno Schulenberg wrote:

Fourth, the first part of the comment begins with this:

 The instances of "s" in the following formats are
 the SI symbol "s" (meaning second), and should not be translated.

Why should they not be translated?  In order to avoid problems
with grammatical congruence in languages like Polish?


Yes. This is part of the SI standard. SI abbreviations are supposed to be 
identical in all languages, regardless of grammar issues.



It would be nicer to use a fixed number of
decimals so that the message doesn't unnecessarily "jump".


Yes, and since the messages you're talking about are supposed to come out once a 
second, dd should just omit everything after the decimal point.



Sixth, the format string uses %g, which means that the
number of seconds will be displayed in exponential form
when the number becomes very large.  Is that intentional?


Yes, it's been that way since that code was introduced in 2004 (before 
status=progress was added). The idea I had back then was that we want more than 
1 digit when transfer times are short, and that we needn't bother with lots of 
digits when transfer times are long. I've never heard of a real-world situation 
where the exponential notation actually gets used (more than 11 days for the 
transfer, if I calculate aright) so the issue is to some extent academic.


Thanks for your other comments. I installed the attached patch, which I hope 
addresses them.
From fa9510a8bba71fc468694ae81ccdfe45bc1814e3 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 24 Apr 2017 00:06:00 -0700
Subject: [PATCH] dd: status=progress outputs "6 s", not "6.1 s"

Problem reported by Benno Schulenberg (Bug#26621).
* NEWS: Document this.
* src/dd.c (print_xfer_stats): With status=progress,
format times with %.0f rather than %g.  Improve
translator comments.
---
 NEWS |  4 
 src/dd.c | 47 +--
 2 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/NEWS b/NEWS
index 07cb283..72981b6 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,10 @@ GNU coreutils NEWS-*- outline -*-
 
 ** Bug fixes
 
+  dd status=progress now just counts seconds; e.g., it outputs "6 s"
+  consistently rather than sometimes outputting "6.1 s".
+  [bug introduced in coreutils-8.24]
+
   df non longer interacts with excluded file system types, so for example
   specifying -x nfs will no longer hang with problematic nfs mounts.
   [bug introduced in coreutils-8.21]
diff --git a/src/dd.c b/src/dd.c
index 8ab1efa..119f307 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -795,29 +795,48 @@ print_xfer_stats (xtime_t progress_time)
   if (progress_time)
 fputc ('\r', stderr);
 
-  /* TRANSLATORS: The instances of "s" in the following formats are
- the SI symbol "s" (meaning second), and should not be translated.
+  /* Use full seconds when printing progress, since the progress
+ report is output once per second and there is little point
+ displaying any subsecond jitter.  Use default precision with %g
+ otherwise, as this provides more-useful output then.  With long
+ transfers %g can generate a number with an exponent; that is OK.  */
+  char delta_s_buf[20];
+  snprintf (delta_s_buf, sizeof delta_s_buf,
+progress_time ? "%.0f" : "%g", delta_s);
+
+  /* TRANSLATORS: Because SI symbols should be the same in all
+ languages, the instances of "s" in the following formats, which
+ are the SI symbol "s" (meaning second), should not be translated.
  The strings use SI symbols for better internationalization even
- though they may be a bit more confusing in English.  If one of
- these formats A looks shorter on the screen than another format
- B, then A's string length should be less than B's, and appending
- strlen (B) - strlen (A) spaces to A should make it appear to be
- at least as long as B.  */
+ though they may be a bit more confusing in English.
+
+ These strings should be translated so that a new output line B
+ completely overwrites an old line A that is already present on
+ the screen, if (sB < sA ? sA - sB : 0) spaces are appended to B,
+ where sA == strlen (A) and sB == strlen (B).  For example, in a
+ UTF-8 locale where A is "8 bajtů zkopírováno, 1 s, 0 kB/s" (32
+ columns, strlen 35) and B is "19979567104 bajtů (20 GB, 19 GiB)
+ zkopírováno, 2 s, 10.0 GB/s" (61 columns, strlen 64), the
+ translation is OK because A looks shorter than B (32 vs 61
+ columns) even when no spaces are appended.  */
 
   int stats_len
 = (abbreviation_lacks_prefix (si)
? fprintf (stderr,
-  ngettext ("%"PRIuMAX" byte copied, %g s, %s/s",
-"%"PRIuMAX" bytes copied, %g s, %s/s",
+  /* TRANSLATORS: See comments in dd.c's print_xfer_stats.  */
+  ngettext ("%"PRIuMAX" byte copied, %s s, %s/s",
+ 

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

[Pádraig Brady]

On 23/04/17 08:17, Benno Schulenberg wrote:
> 
> Commit 2dab6cd3c2e18eb574b24e54fba86a33c80b6a27 changed
> the progress messages for dd, but in doing so separated
> the instruction/hint for translators from the call to
> ngettext().  For xgettext to pick up such comments, the
> comment must end of the line directly before the call.
> So the current POT file for coreutils does not contain
> this comment/hint/instruction.
> 
> Second, the comment seems to consist of two parts that
> appear to be unrelated.  So it would be better to split
> the text into two separate paragraphs.
> 
> Third, the second part of that comment reads like this:
> 
>  If one of
>  these formats A looks shorter on the screen than another format
>  B, then A's string length should be less than B's, and appending
>  strlen (B) - strlen (A) spaces to A should make it appear to be
>  at least as long as B.
> 
> I don't understand what it is trying to say.  Does it say
> that if, of those four strings, untranslated string A is
> shorter than untranslated string B, that then also the
> translation of string A must be shorter than the translation
> of string B?  If yes, then: 1) please reword, 2) why?, and
> 3) does the program blow up if not?  Or is this part of the
> comment not meant for translators at all?
> 
> Fourth, the first part of the comment begins with this:
> 
>  The instances of "s" in the following formats are
>  the SI symbol "s" (meaning second), and should not be translated.
> 
> Why should they not be translated?  In order to avoid problems
> with grammatical congruence in languages like Polish?  But for
> a language like Dutch I would accept the mild incongruence
> when the elapsed time is exactly x.1 seconds, which will be
> a rare occasion.  For all other numbers it will be much clearer
> to say "seconden" instead of just "s".  So I would suggest to
> change this part of the comment to:
> 
>  The instances of "s" in the next four strings are the SI
>  symbol "s" (meaning seconds).  It may be preferrable
>  to leave them untranslated, to avoid problems with
>  grammatical congruence.
> 
> Fifth (and this is the reason I arrived here), when using
> status=progress, the elapsed time that is printed is shown
> with four or five decimals.  1) Is the time measurement
> really this accurate?  2) Sometimes the last one or two
> or three decimals happen to be zero, and then they get
> truncated, making the progress message a bit shorter for
> one second.  It would be nicer to use a fixed number of
> decimals so that the message doesn't unnecessarily "jump".
> 
> Sixth, the format string uses %g, which means that the
> number of seconds will be displayed in exponential form
> when the number becomes very large.  Is that intentional?
> Wouldn't it be better to use %f?  I've played a bit with it,
> and I think %.1f is best, because also the other numbers
> in the progress message, when they are in decimal form,
> use a single decimal of precision.

Yes the different width numbers is not great.
This jumps around on my system:
  dd status=progress if=/dev/zero of=/dev/null bs=2M

Yes, 
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-123-g2dab6cd
changed from %.6f to %g.

You can get some sense of the I/O overhead by looking
at the less significant decimal digits,
so I find the precision useful.

I'll change this back to .6f I think to avoid the jumping,
and fix up the TRANSLATOR notes.

cheers,
Pádraig

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

[Benno Schulenberg]

Commit 2dab6cd3c2e18eb574b24e54fba86a33c80b6a27 changed
the progress messages for dd, but in doing so separated
the instruction/hint for translators from the call to
ngettext().  For xgettext to pick up such comments, the
comment must end of the line directly before the call.
So the current POT file for coreutils does not contain
this comment/hint/instruction.

Second, the comment seems to consist of two parts that
appear to be unrelated.  So it would be better to split
the text into two separate paragraphs.

Third, the second part of that comment reads like this:

 If one of
 these formats A looks shorter on the screen than another format
 B, then A's string length should be less than B's, and appending
 strlen (B) - strlen (A) spaces to A should make it appear to be
 at least as long as B.

I don't understand what it is trying to say.  Does it say
that if, of those four strings, untranslated string A is
shorter than untranslated string B, that then also the
translation of string A must be shorter than the translation
of string B?  If yes, then: 1) please reword, 2) why?, and
3) does the program blow up if not?  Or is this part of the
comment not meant for translators at all?

Fourth, the first part of the comment begins with this:

 The instances of "s" in the following formats are
 the SI symbol "s" (meaning second), and should not be translated.

Why should they not be translated?  In order to avoid problems
with grammatical congruence in languages like Polish?  But for
a language like Dutch I would accept the mild incongruence
when the elapsed time is exactly x.1 seconds, which will be
a rare occasion.  For all other numbers it will be much clearer
to say "seconden" instead of just "s".  So I would suggest to
change this part of the comment to:

 The instances of "s" in the next four strings are the SI
 symbol "s" (meaning seconds).  It may be preferrable
 to leave them untranslated, to avoid problems with
 grammatical congruence.

Fifth (and this is the reason I arrived here), when using
status=progress, the elapsed time that is printed is shown
with four or five decimals.  1) Is the time measurement
really this accurate?  2) Sometimes the last one or two
or three decimals happen to be zero, and then they get
truncated, making the progress message a bit shorter for
one second.  It would be nicer to use a fixed number of
decimals so that the message doesn't unnecessarily "jump".

Sixth, the format string uses %g, which means that the
number of seconds will be displayed in exponential form
when the number becomes very large.  Is that intentional?
Wouldn't it be better to use %f?  I've played a bit with it,
and I think %.1f is best, because also the other numbers
in the progress message, when they are in decimal form,
use a single decimal of precision.

Benno

-- 
http://www.fastmail.com - Email service worth paying for. Try it for free