Hi Joost, On Mon, 2008-08-18 at 06:48 -0700, Joost Cassee wrote: [...] > As a starting point I created a template filter that does the > replacing [1] (only for Arabic and Farsi at the moment), and now I'm > looking for the correct place to integrate localized digits into the > Django translation system. I thought the best place to integrate such > a function would be django.utils.translation.trans_real.py in function > ugettext (because localized digits will always be in unicode). Also, > localized dates would need to pass the replacement function. I'm also > not sure were the digits would be stored: django.utils.translation? > django.contrib.localflavor?
Any time you feel the need to patch core, it's a warning sign that some real design work is needed. The first thing to consider here is whether these digits need to go anywhere at all or if there's just going to be a correct answer all the time. By which I mean, it's not a style choice what the localised version of a Farsi digit is. There's a single right answer. So we treat it like dates, decimal separators, first day of the week, etc and include data as to what the local form is. If Django didn't have to support Windows, this would be relatively trivial, since the information already exists in POSIX locale files. That's a fantasy world, though. Post-1.0, we'll introduce something, most likely based on the Unicode Common Locale Data for each locale we support, but the exact details will wait until then, because we just have time right now. We also need to think through the consequence of always translating every number we output and what the performance will be like. It sounds like a *lot* of string manipulations, breaking every potential number up into digits and then recombining them, so this isn't a trivial issue. I can't imagine that if we add support for this, we're going to be able to get away with just "translating" some digits and not others unless we've thought through the issues very carefully to support our position, so, again, work is needed here. In short, right now, things like filters in your templates are the way to go and manage the source whatever works for you. Post-1.0, bring this up again when we start working on the UCLD (or similar) support. Ticket #7980 is probably an appropriate ticket to add your "cc" to if you want to be alerted when we start doing stuff and then help out. I really don't mean to put you off here. I definitely want help from people with experience in understanding these problems. But right now is a bad time for me and some other people to be doing any serious design thinking on this because it's hard and requires a lot of concentration to review proposals and all our spare time (and then some) is devoted towards getting 1.0 out in two weeks. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
