Discussion for #5446
chris....@gmail.com
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.
-Chris
Malcolm Tredinnick
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
chris....@gmail.com
> 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 understand and can agree with your process. However, since it's
already in Satchmo and meets my needs, I don't have the capacity to
spin it off and maintain it. If there is someone on the list that is
willing to do it, I will certainly help but I feel like I barely have
time to keep Satchmo up and running as it is now!
>
> 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.]
I do agree about the memory footprint. I have some ideas to split it
up into smaller chunks so people have more options to configure for
their own needs.
>
> 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.
Once again, if anyone on the list wants to spearhead this one, I'll be
happy to help them out but I'm not in a position where I can run it
right now.
Thanks,
Chris