--- Begin Message ---
|
Subject: |
df: "block" is not a French(+) word |
|
Date: |
Thu, 08 Aug 2013 23:54:10 -0400 |
|
User-agent: |
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 |
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.
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.
--
Filipus Klutiero
http://www.philippecloutier.com
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#15054: df: "block" is not a French(+) word |
|
Date: |
Thu, 29 Aug 2013 00:57:36 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 08/09/2013 05:24 AM, Pádraig Brady wrote:
> 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)
I confirmed that this fixes the specific issue,
and pushed the above.
thanks,
Pádraig.
--- End Message ---