Bug 279174

Confirmed with 4.7.0 compiled from sources

This is broken in locale fr as well:
"JOURDELASEMAINECOURT MOIS jJ AAAA" is displayed as "MercrediCOURT Août 3 2011"

Apparently some of the items in the combo boxes are generated and not literal translation strings.

Using german locale de in branch 4.7 compiled from sources:
#: kcmlocale.cpp:2916
msgctxt "some reasonable date formats for the language"
msgid ""
"WEEKDAY MONTH dD YYYY\n"
"SHORTWEEKDAY MONTH dD YYYY"
msgstr ""
"WOCHENTAG, tT. MONAT JJJJ\n"
"WOCHENTAGKURZ MONAT tT JJJJ"

Long date format ComboBox has:
1) "WOCHENTAG, tT. MONAT JJJJ" OK, in catalog? see x-test
2) "WOCHENTAG TT MONAT JJJJ"   OK, not in catalog, generated
3) "WOCHENTAGKURZ MONAT tT JJJJ" broken, in catalog

#: kcmlocale.cpp:3034
msgctxt "some reasonable short date formats for the language"
msgid ""
"YYYY-MM-DD\n"
"dD.mM.YYYY\n"
"DD.MM.YYYY"
msgstr ""
"TT.MM.JJJJ\n"
"tT.mM.JJJJ\n"
"TT-MM-JJJJ"

Short date format ComboBox has:
1) "TT.MM.JJJJ" OK, in catalog? see x-test
2) "JJJJ-MM-TT" OK, not in catalog, generated
3) "YYYY-MM-DD" broken, not in catalog where does this come from?
4) "tT.mM.JJJJ" OK, in catalog?
5) "TT-MM-JJJJ" OK, not in catalog, generated

Using a patched locale x-test in master compiled from sources:
#: kcmlocale.cpp:2916
msgctxt "some reasonable date formats for the language"
msgid ""
"WEEKDAY MONTH dD YYYY\n"
"SHORTWEEKDAY MONTH dD YYYY"
msgstr ""
"xxWEEKDAY MONTH dD YYYY\n" patched to "xxWEEKDAY MONTH dD YYYYxx\n"
"SHORTWEEKDAY MONTH dD YYYYxx" patched to "xxSHORTWEEKDAY MONTH dD YYYYxx"

Long date format ComboBox has:
1) xxWEEKDAYxx xxDDxx xxMONTHxx xxYYYYxx -> OK, not in catalog, generated
2) xxWEEKDAY MONTH dD YYYYxx             -> broken, from catalog 
changed to xxWEEKDAYxx xxMONTHxx xxdDxx xxYYYYxx -> OK
3) xxSHORTWEEKDAY MONTH dD YYYYxx        -> broken, from catalog 
changed to xxSHORTWEEKDAYxx xxMONTHxx xxdDxx  xxYYYYxx -> OK

#: kcmlocale.cpp:3034
msgctxt "some reasonable short date formats for the language"
msgid ""
"YYYY-MM-DD\n"
"dD.mM.YYYY\n"
"DD.MM.YYYY"
msgstr ""
"xxYYYY-MM-DD\n" patched to  "xxYYYY-MM-DDxx\n"
"dD.mM.YYYY\n" patched to  "xxdD.mM.YYYYxx\n"
"DD.MM.YYYYxx" patched to  "xxDD.MM.YYYYxx"

Short date format ComboBox has:
1) xxDDxx.xxMMxx.xxYYYYxx   OK, not in catalog, generated 
2) xxYYYYxx-xxMMxx-xxDDxx   OK, not in catalog, generated 
3) YYYY-MM-DD               broken, not in catalog where does this come from?
4) xxYYYY-MM-DDxx           broken, in catalog
changed to xxYYYYxx-xxMMxx-xxDDxx -> OK
5) xxdD.mM.YYYYxx           broken, in catalog
changed to xxdDxx.xxmMxx.xxYYYYxx -> OK
6) xxDD.MM.YYYYxx           broken, in catalog
changed to xxDDxx.xxMMxx.xxYYYYxx -> OK

Hmmm.  Nothing has changed in the code since 4.6, so this should also be a problem under 4.6, and I don't think I changed that method in the big rewrite for 4.6 either so could have been around for ages.  Perhaps the translations were changed?  Dunno.

That said, the userToPosix() method is indeed naive and the root cause of the problem.  It takes the first match found in the format translation map rather than looking for the longest match.  A quick fix is to sort the format map by string length so it tries the longest strings first.

(In reply to comment #4)
> Hmmm.  Nothing has changed in the code since 4.6, so this should also be a
> problem under 4.6, and I don't think I changed that method in the big rewrite
> for 4.6 either so could have been around for ages.  

Yes, just checked this issue with locale de in a VM (Kubuntu 11.04 with KDE 4.6.2), it is broken as well :-(

Btw. this commented line in the diff is responsible for the strange untanslatable item in the Short date format ComboBox:
$ git diff kcontrol/locale/kcmlocale.cpp
diff --git a/kcontrol/locale/kcmlocale.cpp b/kcontrol/locale/kcmlocale.cpp
index 7eb6353..ec3ca15 100644
--- a/kcontrol/locale/kcmlocale.cpp
+++ b/kcontrol/locale/kcmlocale.cpp
@@ -3028,7 +3028,7 @@ void KCMLocale::initShortDateFormat()
     formatList.append( posixToUserDate( m_defaultSettings.readEntry( "DateFormatShort", cValue ) ) );
     formatList.append( posixToUserDate( m_countrySettings.readEntry( "DateFormatShort", cValue ) ) );
     formatList.append( posixToUserDate( cValue ) );
-    formatList.append( "YYYY-MM-DD" );
+    //formatList.append( "YYYY-MM-DD" );
     // TODO convert these to POSIX and US format!
     QString formats = ki18nc("some reasonable short date formats for the language",
                              "YYYY-MM-DD\n"

*** Bug 279633 has been marked as a duplicate of this bug. ***

*** Bug 280765 has been marked as a duplicate of this bug. ***

*** Bug 280851 has been marked as a duplicate of this bug. ***

*** Bug 286245 has been marked as a duplicate of this bug. ***

The bug is still there in KDE 4.7.2 (kubuntu 11.10).

Git commit c981dff4419f30b2c33deb96ae4d2d00d079c2a3 by John Layt.
Committed on 27/12/2011 at 16:06.
Pushed by jlayt into branch 'KDE/4.8'.

KCM Locale: Fix date code conversion for common stems

Fix the KCM so that it checks for the longest date/time codes first when
converting between user visible codes and the real codes. This si
especially a problem in languages like German.

Distro's may want to backport to 4.7 and 4.6
FIXED-IN: 4.8.0

M  +13   -5    kcontrol/locale/kcmlocale.cpp

http://commits.kde.org/kde-runtime/c981dff4419f30b2c33deb96ae4d2d00d079c2a3

That fix should stop any new cases from occurring, but it won't fix the existing saved settings.  You will need to manually change those by going into the KCM.