Django localization and internationalization
django django · internationalization · localization
We have been using the localization and internationalization ( l10n& i18n ) from Django quite a bit for our translations, and although we haven’t had to tackle anything difficult like Arabic or Persian yet there are still some shortcomings in the system.
The standard Django module for input of dates and datetime stamps is quite restrictive. It depends on a module, I think written by Simon Willson which uses the PHP notation rather than the Python/C strftime / strptime notation. Thus although its easy to display dates or datetime based upon the included locale files, parsing them is not so trivial from what I can see. To get around it, a configuration is placed to try and parse the date or datetime’s until a match is found. Looking at the code it does indeed use a try and except method of matching, mean potentially 10/10/10 could be any combination.
Secondly we use the JS18n/ url which outputs translations to be used by Javascript, but this is not in the form that the Javascript Date object can understand so one has to create a function to parse the datetime:
[cc lang=“Javascript”]
formats[‘DATETIME_FORMAT’] = ‘N j, Y, P’;
[/cc]
That can’t be understood by Javascript unless you do so.
Looks like there is some work to be done there, but mid-project is not the time to start making patches to code libraries.
comments powered by Disqus