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