On Sat, 2007-09-22 at 01:35 +0000, [EMAIL PROTECTED] wrote: > Ticket 5446 discusses some ideas for putting more international > country data into Django. The ticket is here - > http://code.djangoproject.com/ticket/5446 > > The last comment is a request to bring to this list for comment. So, > here I am ;) > > The gist is that this is a request to add some capabilities to Django > to have certain country -> admin area -> language relationships in a > contrib app. It's sort of a meta-localflavor but I don't think it > replaces it. I'm using it in Satchmo so it is all available in the > form of Django models and xml data file to load. There would be no > external dependencies. The maintenance would most likely be accepting > patches for changes to the xml data. > > The typical use case would be for someone that wants to add a drop > down to a form to choose a country and have it select the appropriate > states (or provinces, etc) that are a member of that country. As it > stands now, the models in Satchmo support this behavior. We could > easily add additional information for languages, currencies, etc. > > I find this information useful and would imagine others would be > interested in harnessing a pre-populated list of iso codes. The risk > of integrating is pretty small since it could be bundled as a > contrib. Of course, developer feedback is appreciated.
The recommended approach for something like this is to first create it as a third-party app so that people can try it out and we can harvest some real-world experiences. Then it can be migrated to django/contrib, if necessary. So, if no core changes are necessary (and I can't see that they are), that would be the path to take. The other advantage of that approach is that the availability is not blocking on acceptance into the main tree. I'm generally in favour of the general idea of more l10n support facilities either in core, where necessary, or as available third-party packages. Form validation, for example, is an area where we can leverage existing data formats and provide at least minimal reasonable stuff and make it easy for people to utilise functions from babel or other system of their choice if they have it installed. There's another ticket open to extract language name translations from our existing translations. That's kind of superseded by your approach, although the former method has the advantage of always being available. I think there are probably some technical implementation issues that need to be addressed. Your current approach is based on a 1.6 megabyte XML file that has to be read and parsed to do anything for a single locale. Since people are generally operating in one locale at a time and only in a few locales across the board at any given moment, reducing the memory/processing footprint is a good goal. It's a runtime memory penalty that would be good to optimise. May be some other things as well; I haven't read the code carefully enough yet. [This is the same problem I've been thinking about with how to utilise portions of the Locale Data Markup Formats to work with newforms validation: any given locale should only load as little as possible, so some pre-processing of the standard stuff will be necessary.] So, in short, I think the goal is admirable. Create a self-contained app for it so that people can test it out and put it on Google code or somewhere and let's see what it looks like. That's the first step. 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 -~----------~----~----~----~------~----~------~--~---
