Hello,
We cannot translate the following string in french: #: src/dd.c:307 msgid "" "\n" "BLOCKS and BYTES may be followed by the following multiplicative suffixes:\n" "xM M, c 1, w 2, b 512, kB 1000, K 1024, MB 1,000,000, M 1,048,576,\n" "GB 1,000,000,000, G 1,073,741,824, and so on for T, P, E, Z, Y.\n" "Each KEYWORD may be:\n" "\n"
This is because people from France would like to write 1.000.000 and the ones from canada would like to write 1,000,000. To fix this issue, there is three solutions: either split the translation for both country (quite overkilling), choose that the solution from France should apply worldwide (quite rude) or use fprintf to have the LC_NUMERIC field from locales to do the job automagically.
The following patch do the third one. Could you consider applying this?
Thanks, Mt. PS: please keep me or the list of french translators CCed in replies.
Afficher les réponses par date
Martin Quinson mquinson@ens-lyon.fr wrote: ...
"BLOCKS and BYTES may be followed by the following multiplicative suffixes:\n" "xM M, c 1, w 2, b 512, kB 1000, K 1024, MB 1,000,000, M 1,048,576,\n" "GB 1,000,000,000, G 1,073,741,824, and so on for T, P, E, Z, Y.\n"
...
This is because people from France would like to write 1.000.000 and the ones from canada would like to write 1,000,000. To fix this issue, there is three solutions: either split the translation for both country (quite overkilling), choose that the solution from France should apply worldwide (quite rude) or use fprintf to have the LC_NUMERIC field from locales to do the job automagically.
Hi Martin!
Thank you for the patch.
Taking df's --help as an example, what do you think about this as an alternative to writing out 1,000,000 and 1,048,576?
SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024 and so on for G, T, P, E, Z, Y.
I'm reluctant to encourage the use of `%'d', for fear that it's not portable enough. However, maybe there is hope in the longer term: we could use a replacement version of printf on systems that don't support `modern' :-) features like that.
Jim
Jim Meyering jim@meyering.net writes:
Taking df's --help as an example, what do you think about this as an alternative to writing out 1,000,000 and 1,048,576?
SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024 and so on for G, T, P, E, Z, Y.
I like this suggestion.
Also, the French translation can use this idiom, even if the original English remains unchanged. That way, the French translation will be portable between Canada and France, even if the original English is not.
On Wed, Mar 26, 2003 at 07:10:50PM +0100, Jim Meyering wrote:
Martin Quinson mquinson@ens-lyon.fr wrote: ...
"BLOCKS and BYTES may be followed by the following multiplicative suffixes:\n" "xM M, c 1, w 2, b 512, kB 1000, K 1024, MB 1,000,000, M 1,048,576,\n" "GB 1,000,000,000, G 1,073,741,824, and so on for T, P, E, Z, Y.\n"
...
This is because people from France would like to write 1.000.000 and the ones from canada would like to write 1,000,000. To fix this issue, there is three solutions: either split the translation for both country (quite overkilling), choose that the solution from France should apply worldwide (quite rude) or use fprintf to have the LC_NUMERIC field from locales to do the job automagically.
Hi Martin!
Thank you for the patch.
Taking df's --help as an example, what do you think about this as an alternative to writing out 1,000,000 and 1,048,576?
SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024 and so on for G, T, P, E, Z, Y.
I'm reluctant to encourage the use of `%'d', for fear that it's not portable enough. However, maybe there is hope in the longer term: we could use a replacement version of printf on systems that don't support `modern' :-) features like that.
I like this suggestion very much. It solves our problem with fr_FR vs fr_CA, and make clearer for the user what it is all about, IMHO.
Sorry, I didn't knew that some system still don't support printf...
Thanks, Mt.
SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024 and so on for G, T, P, E, Z, Y.
...
I like this suggestion very much. It solves our problem with fr_FR vs fr_CA, and make clearer for the user what it is all about, IMHO.
Good! I'll make that change after coreutils-5.0.
-
Jim Meyering -
Martin Quinson -
Paul Eggert