On 28 Jul 2006, at 13:48, GinTon wrote:
I'm going to repeating some things:We have to be flexible, and not thinking that a user have to have selected those variables, or that if is using a system different from *Unix we could have to copy those *LC files. As I said this is very dirty, and in addition those *LC files have been created thinking into a operating system and not into a framework that is USING A DATA BASE,so why don't use that data base for create a full localization with alladvantages of database?
Correction: LC_* are *directories* not files - just like LC_MESSAGES directory.
With LC_* (or maybe some of L10N XML based formats <ducks>) approach *all* of the django projects will be using the *same* files - no need to update all of the django projects when new locale is added. And LC_* approach *is* standard (at least on POSIX systems) for storing this type of information (number, currency, date and time), see http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html.
For the same reason django uses .po files instead database based translations.
I already have created tables about countries, languages, countries & languages, subdivisions, and time zones. With all those data there are many possibilities in order to make the easiest life to the administrators and the own users.
And I don't need this. I just need the following functionality (IMHO bare-bones L10N):
1. |number filter which will format number according to the current locale
- something like |floatformat but locale aware. 2. |money filter or maybe a tag if exchange rate is to be supported.3. {% now %} tag (for now we can use something like {% now _ ('DATETIME_FORMAT') %}). 4. |date filter (for now we can use something like |date:_ ('DATE_FORMAT')). 5. |time filter (for now we can use something like |time:_ ('TIME_FORMAT')). 6. Collation order - in django this responsibility is delegated to database layer.
And for above, what exactly are advantages for database based approach (except for caching exchange rates for the money filter)? As I already said, I'm talking about a *core* L10N functionality.
IMHO we have two options to accomplish that:1. Use technical message IDs in django(js).po which is the current solution (and only change now, date and time to use appropriate technical ID as default) or,
2. Move all relevant L10N data inside LC_* hierarchy where (by POSIX standards) they belong and change above filters and tags to use current locale formats as the default (and keep backwards compatibility).
-- Nebojša Đorđević - nesh Studio Quattro - Niš - Serbia http://studioquattro.biz/http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ | http://trac.studioquattro.biz/djangoutils/
Registered Linux User 282159 [http://counter.li.org]
PGP.sig
Description: This is a digitally signed message part
