bug-coreutils
[Top][All Lists]
Advanced

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

bug#15054: df: "block" is not a French(+) word


From: Pádraig Brady
Subject: bug#15054: df: "block" is not a French(+) word
Date: Fri, 09 Aug 2013 05:24:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 08/09/2013 04:54 AM, Filipus Klutiero wrote:
> My df outputs something like:
>> Sys. de fichiers blocks de 1K  Utilisé Disponible Uti% Monté sur
>> /dev/sda5            37534240 24181584   11439364  68% /
>> udev                    10240        0      10240   0% /dev
>> tmpfs                  756064      572     755492   1% /run
>> tmpfs                    5120        0       5120   0% /run/lock
>> tmpfs                 1845740        4    1845736   1% /run/shm
>> /dev/sdc3            20641788 16697020    2896128  86% /mnt/work
> 
> In English, the header would be:
>> Filesystem     1K-blocks     Used Available Use% Mounted on
> 
> So "1K-blocks" is translated to "blocks de 1K". It turns out that this isn't 
> a problem in the po file:
> 
>> #. TRANSLATORS: this is the "1K-blocks" header in "df" output.
>> #. TRANSLATORS: this is the "1024-blocks" header in "df -P".
>> #: src/df.c:545 src/df.c:554
>> #, c-format
>> msgid "%s-%s"
>> msgstr "%2$s de %1$s"
> 
> The po file does its best given the msgid given, but it's not given the 
> opportunity to translate "block" itself, which is "bloc" in French. For 
> French, this simply looks like a typo/translato. In Spanish and many other 
> languages, this must be more striking.
> 
> I believe this can be fixed by calling gettext with a string built using a 
> string already translated by gettext.
> 

This might fix it up:

diff --git a/src/df.c b/src/df.c
index c2c390e..949fe2f 100644
--- a/src/df.c
+++ b/src/df.c
@@ -539,7 +539,7 @@ get_header (void)
           char *num = human_readable (output_block_size, buf, opts, 1, 1);

           /* Reset the header back to the default in OUTPUT_MODE.  */
-          header = N_("blocks");
+          header = _("blocks");

           /* TRANSLATORS: this is the "1K-blocks" header in "df" output.  */
           if (asprintf (&cell, _("%s-%s"), num, header) == -1)

> A very different approach would be to reconsider the "block" terminology in 
> df. 1K here is not a block size in the technical sense, it's merely the 
> display unit. When run with --human-readable, there is no need to put unit 
> information in the header, as each cell indicates the unit. Instead of 
> displaying the unit, the header then reads "Size". Which makes you realize 
> that this header actually applies to the 3 size columns.
>
> So enabling human-readable by default would fix this. I thought the 
> disadvantage was verbosity, but human-readable balances verbosity and 
> precision very well and is actually shorter. So the only disadvantage is the 
> generally smaller precision. Even for the precise/fixed-unit mode, at least 
> in French, displaying the unit in each cell would still be more compact than 
> the current approach on my system.
>

Yes this could do with some improvement.
POSIX says -P should output 1024-blocks but doesn't mention translations
The 1K-blocks was a minimal width equivalent, though 1K is ambiguous (1000 or 
1024?)

Also there is awkwardness with -B:

$ df -B1K
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                13102208  11726468   1242672  91% /

$ df -BK
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs               13102208K 11726468K  1242672K  91% /

It would be good to clean this up a bit.

thanks,
Pádraig.





reply via email to

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