Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7225 closed bug (invalid)

Tracker: strange Locale behaviour, dates wrongly displayed

Reported by: MichaelPeppers Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: locale localization tracker Cc:
Blocked By: Blocking:
Platform: All

Description

hrev40501 here, browsing some folders I suddently found the "Name", "Size" and "Modified" strings in the tracker changed to Russian for the "apps" and "home" folders. Also, the dates of the folders in the "apps" folder are inconsistent with each other.

Strangely, the other folders are visualized with the proper strings and dates.

Attachments (1)

LocIssues.png (62.9 KB ) - added by MichaelPeppers 14 years ago.
Screenshot

Download all attachments as: .zip

Change History (10)

by MichaelPeppers, 14 years ago

Attachment: LocIssues.png added

Screenshot

comment:1 by MichaelPeppers, 14 years ago

Removing the tabs (Name etc.) and readding them solved the "changed strings" problem. The dates are displayed wrongly in a lot of folders, actually. I'm stressing the Tracker too much, I guess.

comment:2 by MichaelPeppers, 14 years ago

Summary: Tracker: strange Locale behaviourTracker: strange Locale behaviour, dates wrongly displayed

comment:3 by axeld, 14 years ago

I would argue that both problems aren't actual bugs:

  • Tracker stores the columns with all data (ie. the title) when you add them. If you had running Tracker in Russian and opened (or rather, closed) the "apps", and "home" folder for the first time, the Russian version will be stored. If you never switched Haiku to Russian, that would be a different issue, though. Please confirm.
  • The dates always try to be as expressive as possible with the given width. That might not always be the same version for all dates, which gives the maybe not so pleasing behaviour you've noticed. So this one could still be a candidate for an enhancement ticket, it's not a bug though, but has been the original intention (and was already like this on BeOS before OpenTracker).

comment:4 by MichaelPeppers, 14 years ago

As for the first problem, I only changed the Locale settings once, to set Italian as the preferred language.

About the dates, thanks for the clarification, I see what you mean. It makes sense. Still, it looks awkward.

Version 0, edited 14 years ago by MichaelPeppers (next)

in reply to:  3 ; comment:5 by anevilyak, 14 years ago

Replying to axeld:

  • Tracker stores the columns with all data (ie. the title) when you add them. If you had running Tracker in Russian and opened (or rather, closed) the "apps", and "home" folder for the first time, the Russian version will be stored. If you never switched Haiku to Russian, that would be a different issue, though. Please confirm.

That could potentially also be caused by unzipping a badly created package to /boot though. If it contained a home subdir with _trk attributes on it in Russian, the observed behavior could easily result.

in reply to:  5 comment:6 by MichaelPeppers, 14 years ago

Replying to anevilyak:

Replying to axeld:

  • Tracker stores the columns with all data (ie. the title) when you add them. If you had running Tracker in Russian and opened (or rather, closed) the "apps", and "home" folder for the first time, the Russian version will be stored. If you never switched Haiku to Russian, that would be a different issue, though. Please confirm.

That could potentially also be caused by unzipping a badly created package to /boot though. If it contained a home subdir with _trk attributes on it in Russian, the observed behavior could easily result.

Just searched through the programs I've downloaded and found the newest version of DosBox that's in Haikuware to be the cause. http://haikuware.com/directory/view-details/emulators/computer-systems/dosbox

So... I guess this bug report is invalid.

comment:7 by tangobravo, 14 years ago

Is there no way Tracker could store the "key" instead of the translated string? I suppose that couldn't work for custom attributes, but the standard ones could be whitelisted or something?

comment:8 by korli, 14 years ago

Resolution: invalid
Status: newclosed

Closing as invalid

comment:9 by axeld, 14 years ago

As a bug report it's invalid, but I see two possible enhancements:

  • If an attribute has an installed MIME type, use that one instead of the stored data (I guess only the column width should be restored from there). Only if there is no such MIME type, the column data should be used completely.
  • Choose a single date version depending on the column width, not one for each date - that should also speed up the mechanism.
Note: See TracTickets for help on using tickets.