[GSoC] i18n status

0 views
Skip to first unread message

Marc Garcia

unread,
Jun 8, 2009, 10:06:38 AM6/8/09
to Django developers
Hi folks!

Most of what I did previous week is represented by changeset 10956
[1], that basically implements the base for localizing date and number
format on Django.

Summarizing, right now, Django uses gettext and translation catalogs
to store some formats, that are used in few places on Django (admin
list, and object list basically). The idea is moving format
definitions (for every locale) to a specific place for formats, and
use them everywhere in Django, when displaying numbers, dates or any
data sensitive to locales.

For now, I created a first version of this new way to get formats, and
I'm already using it on places where dates were already localized.

There is a little bit of documentation and tests, just as a reference
for myself to know where to complete them after the code is discussed
and modified according to the feedback.

I'll really appreciate your comments, specially the ones complaining
about the code or the way I'm doing something.

Thanks, and kind regards,
Marc

[1] http://code.djangoproject.com/changeset/10956

Marc Fargas

unread,
Jun 8, 2009, 12:36:43 PM6/8/09
to django-d...@googlegroups.com
Hi Marc,

On Mon, Jun 8, 2009 at 4:06 PM, Marc Garcia<garci...@gmail.com> wrote:
> [...] I'll really appreciate your comments, specially the ones complaining
> about the code or the way I'm doing something. [...]

IMHO; Not very important but I'd strip the "Default ...." part of the
settings comments, even from the pre-existing ones; Only date related
settings have this "Default ..." prefix in it's comments and feels
very repetitive, we all know global_settings is about defaults.

Also, those functions that are going to be deprecated should raise
some DeprecationWarning to make sure anybody using them for something
gets warned. Also makes it easier for the release+1 to spot thing to
remove.

I am wondering.. Maybe that's being discussed before, but anyway:
From what I see you intend to have a conf/locale/XX/formats.py being
XX the language codes, if this is the case, how will you allow further
customization? I mean, right now one can place custom .po files in
his/her project path and override Django provided translations, that
new behaviour seems to make it hard (if not impossible) to override
the date/time (or any other formatting) related translations on a
per-locale basis.

That goes toghether with allowing per-application "format strings".

Nice work!

Just my 0.02,
Marc
--
http://www.marcfargas.com - will be finished someday.

Reply all
Reply to author
Forward
0 new messages