Opened 15 years ago
Closed 14 years ago
#5970 closed bug (fixed)
Applications do not know if 24-hour clock is in use
Reported by: | Karvjorm | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System | Version: | R1/alpha2 |
Keywords: | 24-hour clock Country Locale | Cc: | Karvjorm |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Applications do not know if 24-hour clock is selected by the Locale preflet. For example, Deskbar and dstcheck applications do not know it. I tried to fix some problems with it, but because I cannot build the Haiku system, so I do not know, if my changes are correct. For example there can be missing header files, etc.
Anyway, I enclose here 4 patches and a picture about dstcheck application without 24-hour clock information. Because I had to change Country-class a bit, I started to modifications for en_US@utf8 type constructor and handling of encoding. But it can be faulty, because I do not know, if I saved that encoding information to corret place.
I also localized the dstcheck application.
My testing environment is r1alpha2.
Attachments (5)
Change History (10)
by , 15 years ago
Attachment: | correct-time-inquiry.png added |
---|
by , 15 years ago
Attachment: | preferences_locale.patch added |
---|
Preferences/locale patch for 24-hour and Country encoding
follow-up: 2 comment:1 by , 15 years ago
I couldn't yet find time to look at the patches, but maybe one of the guides is helpful to you in getting a proper build environment set up. This part of the localization kit can definitely use your help! :-)
by , 15 years ago
Attachment: | locale_header.patch added |
---|
A locale header patch for 24-hour and Country encoding.
by , 15 years ago
Attachment: | bin_dstcheck.patch added |
---|
Localization and 24-hour patch for the dstcheck application
comment:2 by , 15 years ago
Replying to stippi:
I couldn't yet find time to look at the patches, but maybe one of the guides is helpful to you in getting a proper build environment set up. This part of the localization kit can definitely use your help! :-)
I have already got all (?) other things to work in my development environment, but always when there is "B_TRANSLATE(" something in my new code, jam starts to complain about implicit declaration. So something is missing or not uptodate with my environment.
follow-up: 4 comment:3 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I don't understand the use of the "encoding" part of the patch, since everything in Haiku is using utf-8.
As for dstcheck, one should use the formatter in BCountry, not strftime. See the deskbar code for the proper way to do it. This is because we need something more flexible, look at what happens if you select an arabic language in the preflet, for example. The ":" character isn't even used, and strftime can't handle such things.
Also, as ICU is handling most of the backend stuff, you don't need to store the fact that the clock is 24 hours, and you don't even have to decide if the clock is 12 or 24 hours. What if some country decides to use a 30-hour day or something else ? Let ICU handle that, they know better than us :)
comment:4 by , 14 years ago
Replying to pulkomandy:
I don't understand the use of the "encoding" part of the patch, since everything in Haiku is using utf-8.
Oops. Does that mean that utf-8 is mandatory for all locale settings in Haiku? In linux I have used to define for example "export LANG=fi_FI@ISO-8859-15" and when I download an ISO-8859-15 encoded html page from web, I can open a terminal window and write there "nano index.html". Then nano opens with Finnish menu items and html page opens with correct character forms. No need to convert characters to utf-8, for example. Then I can edit html page and upload it back to my web server.
As for dstcheck, one should use the formatter in BCountry, not strftime. See the deskbar code for the proper way to do it. This is because we need something more flexible, look at what happens if you select an arabic language in the preflet, for example. The ":" character isn't even used, and strftime can't handle such things.
The orginal code is: strftime(timestring, 15, "%I:%M %p", &tm);
Here "%I" and "%p" are problems. In my patch I only "quessed" some solution to solve this "%I" and "%p" problem. You can simply forget my patches.
Also, as ICU is handling most of the backend stuff, you don't need to store the fact that the clock is 24 hours, and you don't even have to decide if the clock is 12 or 24 hours. What if some country decides to use a 30-hour day or something else ? Let ICU handle that, they know better than us :)
If ICU provides some means to handle this, please, use it. In my patches I mixed this "%I, %p" problem (due to 12/24 hour clock) and localization of text to the same ticket. It is my mistake. I should have done only localization patch in one ticket and guessed some solution for 12/24 hour and encoding in another tickets.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed dstcheck (hrev37297) and deskbar. The other parts are not needed.
Not localized dstcheck application without 24-hour information