[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: 2 date formats in KLocale
From:       Andre Charbonneau <yoamwmvs () umail ! corel ! com>
Date:       2000-11-22 17:59:11
[Download RAW message or body]

Christian Gebauer wrote:

> Andre Charbonneau wrote:
> > 
> > Hi,
> > 
> > I was looking at the KLocale class and I'm wondering why it was decided
> > to use 2 seperate date formats: a short date format and a long date
> > format. I'm asking this because I'm currently working on a regional
> > settings control panel that will work both at the system level (POSIX
> > locale files)
> > and at the KDE level (using KDE's locale config files).  Since there is
> > only one real date format in the POSIX locale files it is difficult to
> > syncronize the system-level settings with the KDE settings.  At the
> > system level, there is no such thing as a "short" date or a "long" date.
> > 
> > Why was it decided to have 2 seperate date formats?
> 
> Take a look at KNode. We use the short format for the listview and the
> verbose format in the article widget. The normal format is just too
> long for a listview.
> 
> Christian

I see your point.  But what I would like to know is what was the "initial" 
reason of deciding to put 2 date formats in KLocale, other than using one 
single date format like in system level locale.  

In the long run it would be nice if KLocale relied on the system level l10n 
functionalities to format date/time/numeric and monetary values.  
Currently, there are a lot of l10n/i18n features available at the system 
level that are not present in KLocale.  Also, by having multiple 
implementation of l10n functionalities, it is difficult to synchronise the 
locale settings on a system.  For example, if a user changes the locales 
settings using KDE's control panel, then only KDE apps will be affected by 
the changes.  All other apps (command line and non-KDE apps) will not 
follow the locale settings set by the user since they are not using KDE's 
KLocale class. (This is the reason I'm currently working on a regional 
settings control panel.)

On the other hand, if KLocale relied on what is already available at the 
system level, then a change in the locale settings would mean that all 
applications would be affected and therefore be properly localized.
The current implementation of localedef (the system level locale compiler) 
supports many new (and usefull) locale categories such as paper size, 
address and telephone number formatting etc...  Having all the available 
locale categories in a regional settings control panel would be a great 
thing, and would allow users to take full advantage of GNU Linux's l10n 
features already offered at the system level.  To my opinion, the right way 
to go would be to modify KLocale to use the system-level l10n features and 
then use a regional settings control panel that is capable of editing 
system-level locale files.

What do you think about all this?

Cheers,
-- 
Andre Charbonneau
GNU Linux Software developer  (Globalization)
Corel Corporation
-- 
The address in the headers is not the poster's real email address.  Do not send
private mail to the poster using your mailer's "reply" feature.  CC's of mail 
to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com".  
The poster's email address is "andrec@corel.com".

[prev in list] [next in list] [prev in thread] [next in thread]