#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)
Change History (10)
by , 14 years ago
Attachment: | LocIssues.png added |
---|
comment:1 by , 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 , 14 years ago
Summary: | Tracker: strange Locale behaviour → Tracker: strange Locale behaviour, dates wrongly displayed |
---|
follow-up: 5 comment:3 by , 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 , 14 years ago
As for the first problem, I only changed the Locale settings once, to set Italian as the preferred language, and way before opening those folders.
About the dates, thanks for the clarification, I see what you mean, and it makes sense. Still, it looks awkward.
follow-up: 6 comment:5 by , 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.
comment:6 by , 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 , 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:9 by , 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.
Screenshot