The new fr_FR locale (from version 4.3 to 4.4) have made the length of month abbreviation variable from 3 to 5 characters, while they were 3 characters long before. This make the output of some programs (eg ls -l) unreadable. Please revert the change, or at least switch to a fixed length abbreviation like on other locales.
/bin/ls -l uses the format ISO on my computer (it's a fixed length) drwx------ 2 stephane stephane 4096 2008-12-09 08:40 work Do you use an alias? The choice to use variable length for has been discussed to avoid any drawbacks and the main constraint is to use short words when space is tight. Some other languages use longer abmon than 3 characters. This has been made to be fix sprintf %b in graphical application like the GTK+ calendar (users were puzzled about 'jui', 'juin' or 'juillet'?) and to conform to the official French abbreviations. 1 - abmon: jan -> janv. fév -> févr. mar -> mars avr -> avril mai -> mai jui -> juin jul -> juil. aoû -> août sep -> sept. oct -> oct. nov -> nov. déc -> déc. PS: ls -l --time-style=locale doesn't change anything...
> /bin/ls -l uses the format ISO on my computer (it's a fixed length) > drwx------ 2 stephane stephane 4096 2008-12-09 08:40 work > > Do you use an alias? No. I am the same output as you with an old coreutils version. With a recent one (>= 6.0), I get: drwxr-xr-x 12 aurel32 aurel32 4096 mai 26 2008 audio -rwxr-xr-x 1 aurel32 aurel32 4096 janv. 30 12:29 photos drwxr-xr-x 2 aurel32 aurel32 4096 déc. 21 20:46 work > The choice to use variable length for has been discussed to avoid any drawbacks > and the main constraint is to use short words when space is tight. Some other > languages use longer abmon than 3 characters. > > This has been made to be fix sprintf %b in graphical application like the GTK+ > calendar (users were puzzled about 'jui', 'juin' or 'juillet'?) and to conform > to the official French abbreviations. The problem is not the length of the abbreviation, it's important to be able to see the difference between 'juin' and 'juillet'. But variable lenght is really causing problems.
> drwxr-xr-x 12 aurel32 aurel32 4096 mai 26 2008 audio > -rwxr-xr-x 1 aurel32 aurel32 4096 janv. 30 12:29 photos > drwxr-xr-x 2 aurel32 aurel32 4096 déc. 21 20:46 work The same output with the old translation still a bit strange drwxr-xr-x 12 aurel32 aurel32 4096 mai 26 2008 audio -rwxr-xr-x 1 aurel32 aurel32 4096 jan 30 12:29 photos drwxr-xr-x 2 aurel32 aurel32 4096 déc 21 20:46 work because the year replaces the time when the year is different as the current one (I think) but it's another problem. May be it's also possible to fix coreutils assumption about the month length to display: drwxr-xr-x 12 aurel32 aurel32 4096 mai 26 2008 audio -rwxr-xr-x 1 aurel32 aurel32 4096 janv. 30 12:29 photos drwxr-xr-x 2 aurel32 aurel32 4096 déc. 21 20:46 work The length of the other fields is dynamic and other languages have the same problem on month abbreviations (> 3).
I wasn't able to see the problem because the link to /usr/share/locale/fr/LC_TIME/coreutils.mo is broken on Ubuntu 8.10 and 9.04 (I've reported the problem). The French translation of coreutils contains many mistakes and it's wrong to use the same translation as the English one for dates: #: src/ls.c:698 msgid "%b %e %Y" msgstr "%b %e %Y" -> "%e %b %Y" #: src/ls.c:706 msgid "%b %e %H:%M" msgstr "%b %e %H:%M" -> "%e %b %H:%M" but I can't fix the alignment problem with this simple string (do you see the hack before the %Y?). I'll continue to discuss the problem on the coreutils list.
The field has never been guaranteed to be of a fixed size. If this creates problems fix the user of the interfaces.
POSIX 2008 added the requirement for supporting field widths in strftime, but also makes it explicit that field widths for anything other than C, F, G, and Y is implementation-defined. Why not define the glibc implementation of strftime to allow: %5b as requesting an expansion to a string with any necessary leading space to occupy 5 columns (note that this is different than padding to 5 bytes), in locales such as French with variable-spaced abmon. That way, translators could once again provide a string that occupies fixed width when used in ls -l output, by requesting that strftime pad the short months to the same column width of the longer abbreviations, regardless of multibyte characters encountered during that padding. http://lists.gnu.org/archive/html/bug-coreutils/2009-03/msg00258.html
The support of field widths in strftime was a possible solution but the bug is now fixed by http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commith=612b647dd16d5abc03b295abe42d8b4a0fe660f7 Feel free to create a new bug report to talk about support of field widths in strftime.
*** Bug 10525 has been marked as a duplicate of this bug. ***
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.