#3847 closed (fixed)
Add Finnish localflavor
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Contrib apps | Version: | dev |
| Severity: | Keywords: | localflavor, l10n, fi | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
Patch to add fi module to django.contrib.localflavor: FIZipCodeField and FIMunicipalitySelect.
Tests included.
Attachments (3)
Change History (16)
by , 18 years ago
| Attachment: | fi_localflavor.diff added |
|---|
comment:1 by , 18 years ago
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
comment:2 by , 18 years ago
| Patch needs improvement: | set |
|---|
comment:3 by , 18 years ago
| Triage Stage: | Ready for checkin → Accepted |
|---|
comment:4 by , 18 years ago
Thanks for your quick response and comments! I was a little bit uncertain about this, too. I'll modify the patch and add a better one ASAP.
by , 18 years ago
| Attachment: | fi_localflavor_unicode.diff added |
|---|
A better patch (hopefully). This time with unicode strings.
comment:5 by , 18 years ago
| Keywords: | l10n fi added |
|---|
Just noticed a thread on django-dev about documenting these localflavour add-ons. I'm happy to write docs for this one if needed. There's not much to document at the moment, though :)
comment:6 by , 18 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
by , 18 years ago
| Attachment: | fi_localflavor_social_security_number.patch added |
|---|
A Finnish social security number field
comment:7 by , 18 years ago
I added patch for Finnish localflavor. It contains new FISocialSecurityNumber field and regressiontests. Is it possible to add it at the same time? It would be nice to create one patch using FIZipCodeField, FIMunicipalitySelect and FISocialSecurityNumber.
comment:8 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:9 by , 18 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Whoops .. the extra patch was added just as I was committing Ville's work. I'll merge it together now. although the final patch here appears to be in an invalid format. "Patch" doesn't like it for some reason. Not to worry, though, I can do it manually.
comment:10 by , 18 years ago
Whoa. Malcolm was fat. I was just merging this other patch to mine. Oh, well :)
It seems that Trac likes only patches with filename ending '.diff'. Or something.
Thanks Malcolm for your efforts on this.
comment:12 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
I would prefer that the second argument in each tuple was marked as a Unicode string (u"..."). The problem with the current method is that Python will convert the second argument to a str object, rather than a unicode object. However, it doesn't attach any information to that object to indicate that it is UTF-8 encoded (rather than some other encoding or just a string of bytes). This can cause problems as the objects become further and further removed from their creation point. Further, you cannot use encode() or decode() on them in their current form (Python fails on ordinal values greater than 127, which happen frequently in UTF-8 strings from non-English locales).
To ease our transition to unicode internally and help avoid encoding problems, marking the strings as unicode objects is a better approach here.