Update Polish administrative entites

[Piotr Lewandowski <django@…>]

Attached file contains a list of Polish administrative entites from a ​official government source.

[Piotr Lewandowski <django@…>]

Updated version with recent changes introduced by government

[Piotr Lewandowski <django@…>]

+ PL_CITIES

[Piotr Lewandowski <django@…>]

The main part of pl_regions.py can be easily generated from official source using a script described on PolishLocalflavor.

[Malcolm Tredinnick]

I think this is too much data, even for something as loose as localflavor. We're not going to carry around megabytes of every city in every localflavor like this. Django isn't meant to be an encyclopedia.

[Piotr Lewandowski <django@…>]

• PL_{CITIES,COMMUNES}

[Piotr Lewandowski <django@…>]

How about after removing information about communes and cities?

• pl_region.py now has 11.1kB (versus 13.67kB of total size of pl_administrativeunits.py and pl_voivodeships.py),
• it's up-to-date and the source of information is authoritative (versus Wikipedia),
• naming is coherent with #8276.

[Malcolm Tredinnick]

We already have this information in the code, so let's not just add it in a different format. Update the existing files if there are errors, but that should be enough.

[Piotr Lewandowski <django@…>]

pl_regions.py has serveral advantages over current state:

• it merges information from two files into one (pl_regions.py) which is coherent with other localflavors (cl, es, sk, uk). Currently, file names don't reflect changes from [8345].
• it can be automatically generated what makes future updates easy (see PolishLocalflavor for details).
• it doesn't use manually crafted key values for *_CHOICES tuples so collisions are unlikely. Currently, there are 10 duplicates in ADMINISTRATIVE_UNIT_CHOICES - it's because there are counties in Poland with the same name. I can't imagine how this outdated, buggy data could get into Django 1.0.
• TERYT codes (which are used for keys in pl_regions.py) contain additional information - they enable user to group counties by province they belong to (it's impossible to do it now). Such possibility would be very handy - instead confusing user with a counties list which has about 400 items, you can ask him for province in a first place and then show a list with only ~25 counties.

I'm willing to prepare transition patch (replacing pl_administrativeunits.py and pl_voivodeships.py by pl_regions.py).

[Malcolm Tredinnick]

As I mentioned above, please feel free to fix the existing data (and open a new ticket for those changes, since this is really becoming about pl_regions.py and I want to close it out). It is not worth making such a change in the data structures right now. If you'd come up with this proposal before the 1.0 feature freeze, it might have been a different story, but we're in the final approach to 1.0 and these changes simply don't fix bugs in a way that cannot be fixed less intrusively.