Opened 5 years ago

Closed 22 months ago

#11343 closed enhancement (fixed)

Locale prefs formatting doesn't work on time in Tracker

Reported by: humdinger Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Kits/Locale Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


This is hrev48029.

I've set the formatting in the Locale prefs to German, but checked the box to "use month/day-names from preferred language" (which is English).

With this Tracker shows the "Modified" column like this:

Tracker screenshot

The German "um" should be "at", English like the rest of the date.
We may want to change that option to "Use date/time names from preferred language"?

I guess this is a Tracker issue?

Attachments (2)

locale_time.png (3.0 KB) - added by humdinger 5 years ago.
Tracker screenshot
tracker_format_error.png (30.7 KB) - added by Duggan 2 years ago.

Download all attachments as: .zip

Change History (14)

Changed 5 years ago by humdinger

Attachment: locale_time.png added

Tracker screenshot

comment:1 Changed 5 years ago by humdinger

Oh, and add a comma in front of the "at {time}".

comment:2 Changed 5 years ago by pulkomandy

Component: Kits/libtracker.soKits/Locale Kit
Owner: changed from nobody to pulkomandy
Type: bugenhancement

Tracker is using Locale Kit for the formatting, and using it correctly. The problem seems to be that te unusual english/german mix isn't handled well. I'm not really surprised by this. The "um" is part of the german format, if you want an "at" there you need to use an english format.

We can't do better than this, and the checkbox labelling reflects it. So it would seem there is no bug here ;)

comment:3 Changed 5 years ago by humdinger

OK. Maybe we could mitigate the awkwardness by using the same delimiter as between name of the day and the date: "," ? So that'd be "Wednesday, 7. May 2014, 17:16:25". Sort of like the shorter version for narrower columns is already, e.g. "07.05.2014, 17:16".

Last edited 5 years ago by humdinger (previous) (diff)

comment:4 Changed 5 years ago by pulkomandy

We don't have much control on this, as ICU decides which format is appropriate. For example in French there are no separators at all. There can't be an automatic solution to this,which is why I don't like this checkbox much.

In the early versions of the locale preflet the formats were completely customizable, but it was decided that the UI was too complex and the idea was dropped.

comment:5 Changed 5 years ago by axeld

We could

  1. add a non-UI option to set the date/time format using a standard formatter string.
  2. patch the known issues of the time/date format strings. In this case, I think there is no need for neither "at" nor "um".

comment:6 Changed 2 years ago by Duggan

Related issue: on hrev51048, inconsistent formatting between AM and PM times (", " for PM, " at " for AM).

Changed 2 years ago by Duggan

Attachment: tracker_format_error.png added

comment:7 Changed 2 years ago by Duggan

Has a Patch: set

comment:8 Changed 2 years ago by Duggan

Has a Patch: unset

comment:9 Changed 2 years ago by pulkomandy

@Duggan: it's just that Tracker decides for each item, the longest format it can fit in the column. In your case, the line with PM would be slightly longer with the full format and wouldn't fit. So, it goes with a shorter format which doesn't include the "at" and uses 3 letter month names. Enlarge or shrink the column and see how this changes. It is not related at all to AM/PM, but to the fact that your PM times tend to have 2 digits, and your AM ones, only one (working only during the night it seems?)

Maybe we should just remove the longest formats from the list?

Last edited 2 years ago by pulkomandy (previous) (diff)

comment:10 in reply to:  9 Changed 2 years ago by humdinger

Replying to pulkomandy:

Maybe we should just remove the longest formats from the list?

+1 to that. It unnecessarily ruffles the columns on resize for no real gain.

comment:11 Changed 2 years ago by pulkomandy

It is as easy as removing some entries from the list here:

(and adjusting the loop just below to not use hardcoded "5" and use array_count or similar instead).

comment:12 Changed 22 months ago by pulkomandy

Resolution: fixed
Status: newclosed

Done in hrev51300, and I think it removes most of the hardcoded strings.

Note: See TracTickets for help on using tickets.