Bug 162453

This is not major.  It also may not be easy to fix right because the glibc locale data is so broken.

Yeah, these aren't marked for i18n.  This should probably be an upstream bugzilla.gnome.org bug, though.  (More likely to get fixed because community eyes will be on it.)

Mono has its own locale data, although it might be generated from the glibc data (although I think not, because it has to be compatible with .NET).

But it sounds from the report like we're currently localizing some parts of the output but not other ("III 3" isn't correct in English either.)

We can fix most of this by using things like System.Globalization.DateTimeFormatInfo.MonthDayPattern. That will just leave "Today" and "Yesterday", which we should mark as translatable, but since there might not be enough time left to get translations everywhere, we can just hack the code to fall back to using the date format instead if it doesn't have a translation.

Fixed in CVS; the translated strings for Today, Yesterday, etc, are all already there from the old UI.

Reopening. In SuSE Linux RC2, Czech locale it still uses "Přijato: III 14" instead of "Přijato: 14. 3." (or "14. bře"). Note that "14. III" is not used in recent Czech language and "III 14" is not considered as a date format by some users.

it seems, that proper string in the po file exists:
#: ../Util/StringFu.cs:82
msgid "MMM d"
msgstr "d. MMM"

With beagle-gui-0.2.3-30, I get things like "Přijato: 13. IV". It looks like you  ave a version of beagle-gui without the fix.

The date format is because the code is currently doing:

ShortMonthDayPattern = DateTimeFormat.MonthDayPattern.Replace ("MMMM", "MMM");

which I guess doesn't work in all locales. :) We do that for a few other short patterns too; they aren't all already translated though. I'll figure something out.

Confirming that upgrade of beagle-gui from RC2 to STABLE changes the format to "13. IV", which is still not good, but it is much better.

This just got reassigned to me.  What's the status, is it still broken?

Now it uses "24. I" and "11:00", which is better than previous, but still not correct. Correct would be "24. 1." (or less frequent "24. I." used a hundred years ago) and "11.00" ("11:00" does not conform official rules, but is widely used).

But now it may be a problem of locale file, not code.

Ok, I think this might be an issue in the locale data.  The docs have this to say about the format specifiers:

M - Represents the month as a number from 1 through 12. A single-digit month is formatted without a leading zero. For more information about using a single format specifier, see Using Single Custom Format Specifiers.

MM - Represents the month as a number from 01 through 12. A single-digit month is formatted with a leading zero.

MMM - Represents the abbreviated name of the month as defined in the current System.Globalization.DateTimeFormatInfo.AbbreviatedMonthNames property.

MMMM - Represents the full name of the month as defined in the current System.Globalization.DateTimeFormatInfo.MonthNames property.

In en_US, the date is specified as "MMMM d" ("February 15") and on cs_CZ it's "d. MMMM" ("15. únor").  For a shortened date, we replace "MMMM" with "MMM", making it "MMM d" for en_US and "d. MMM" for cs_CZ.  The values inside AbbreviatedMonthNames are:

Jan
Feb
Mar
(etc.)

... for English.  For Czech, they are:

I
II
III
(etc.)

So I think that it's a bug upstream.

For the time format ("11:00" vs. "11.00"), I don't see anywhere offhand where the time is displayed.  Can you tell me specifically where you're seeing an incorrect time?

Time is displayed for documents changed Today.

It seems that it should be re-assigned to maintainer of Czech translation to fix either AbbreviatedMonthNames (to included final dot) or change to "d. MMM.", or even better, use abbreviations or numbers for months, not roman numbers.

The date is in cs.po:
msgid "h:mm tt"                                                                                                                           
msgstr "HH:mm"

Jakub, can you provide is with the change to check into upstream and 11.0?

Jakub?

Beagle is dead upstream, we switched to tracker and we won't fix this in a maintenance update for old versions of openSUSE => WONTFIX.