Re: L10N (was Re: humanize middleware)

[Nebojša Đorđević]

On 28 Jul 2006, at 18:09, GinTon wrote:

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

When the tables are finished it is not necessary add any more so it is
not necessary update the Django projects. Anyway this is not any
problem because until version 1.0 could suffer changes significatives.

And you'll still end up with x tables * django projects with *identical* data.

I say you what I already made it until now.

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.

I say you the disadvantages about use LC*:

1) You need all locales installed in your system to let the correct
localization to users of whatever country.

Correction, *not on system* only in django.

Country to locale is not 1-1 mapping lot's of countries uses more than one locale and also some locales are shared between more than one country. Note that we here tying i18n with l10n, so when user selects *existing* locale it will see translated texts with localized numbers, dates,... It's no use (and also confusing) to show localized numbers when rest of interface is in i.e. english.

2) This system is more slow that use directly the data base:

will be more slow when you have s system with a lot of users with
different locales.

You have to use a tool to get data from a directories and files, and it

FILE BASED:





No duplicated data.

DATABASE BASED:

Hmmmmmm, so you saying that current i18n approach is slower than database based? Let's see: When server thread/process is started all locale files (for the default locale) are loaded and parsed and stored in the memory. When a new locale is accessed it is loaded and parsed in the same way. So we have 1 default locale load/parsing + (number of requested locales * load/parsing) *per process loading*. You can emulate above with database result caching but you'll be always use more resources or you can load data as requested so you'll end up with database access *per page view* at least. All of django applications will have duplicated localization tables with the same data.

If you think that using directories and files is more fast that using a

data base then I don't know why you are using a framework based on a
data base.

--
Nebojša Đorđević - nesh
Studio Quattro - Niš - Serbia
http://studioquattro.biz/

Database is meant to store data which will be searched, CRUDed .... L10N (and I18N) data is load *only once* per process/thread so with avoiding database overhead we come with faster solution. You can newer beat filesystem in any *read-only* operations. Huh, this conversation getting longer and longer :). I'll will soon have my solution ready for publishing an then we can compare results. 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