Opened 14 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)

correct-time-inquiry.png (11.0 KB ) - added by Karvjorm 14 years ago.
Not localized dstcheck application without 24-hour information
preferences_locale.patch (687 bytes ) - added by Karvjorm 14 years ago.
Preferences/locale patch for 24-hour and Country encoding
kits_locale.patch (3.2 KB ) - added by Karvjorm 14 years ago.
A 24-hour and country encoding patch
locale_header.patch (1.1 KB ) - added by Karvjorm 14 years ago.
A locale header patch for 24-hour and Country encoding.
bin_dstcheck.patch (2.6 KB ) - added by Karvjorm 14 years ago.
Localization and 24-hour patch for the dstcheck application

Download all attachments as: .zip

Change History (10)

by Karvjorm, 14 years ago

Attachment: correct-time-inquiry.png added

Not localized dstcheck application without 24-hour information

by Karvjorm, 14 years ago

Attachment: preferences_locale.patch added

Preferences/locale patch for 24-hour and Country encoding

comment:1 by stippi, 14 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! :-)

http://www.haiku-os.org/guides

by Karvjorm, 14 years ago

Attachment: kits_locale.patch added

A 24-hour and country encoding patch

by Karvjorm, 14 years ago

Attachment: locale_header.patch added

A locale header patch for 24-hour and Country encoding.

by Karvjorm, 14 years ago

Attachment: bin_dstcheck.patch added

Localization and 24-hour patch for the dstcheck application

in reply to:  1 comment:2 by Karvjorm, 14 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! :-)

http://www.haiku-os.org/guides

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.

comment:3 by pulkomandy, 14 years ago

Owner: changed from nobody to pulkomandy
Status: newassigned

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 :)

in reply to:  3 comment:4 by Karvjorm, 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 pulkomandy, 14 years ago

Resolution: fixed
Status: assignedclosed

Fixed dstcheck (hrev37297) and deskbar. The other parts are not needed.

Note: See TracTickets for help on using tickets.