#15856 closed New feature (fixed)
Add a localflavor for Macedonia
Reported by: | Vasil Vangelovski | Owned by: | nobody |
---|---|---|---|
Component: | contrib.localflavor | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've created a localflavor package with form and model fields for a Macedonian localflavor. Tests and documentation are included. Also a translation for the mk locale is included. Although I'm not sure updates to translation are handled in this way anymore since the transition to transifex.
There's a pull request on GitHub https://github.com/django/django/pull/22
Attachments (1)
Change History (13)
comment:1 by , 14 years ago
Easy pickings: | unset |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 14 years ago
The alphabetical order in the municipalities list looks as if it is not respected when you read it as it is with latin characters. When the translation is applied in Cyrillic it is in alphabetical order respecting the Cyrillic alphabet ordering абвгд... (abvgd). So it is like that intentionally os it's sorted properly when the translation to Macedonian is applied.
comment:3 by , 14 years ago
The alphabetical order may be out of line when importing tests (mk should go before mx). I'll fix that.
follow-up: 5 comment:4 by , 14 years ago
Please attach the patch here for the sake of completeness.
Unless there is a specific reason, please don't prefix the MUNICIPALITY_CHOICES with "MK.".
Also, the translation updates shouldn't be part of the patch.
comment:5 by , 14 years ago
Replying to jezdez:
Please attach the patch here for the sake of completeness.
Unless there is a specific reason, please don't prefix the MUNICIPALITY_CHOICES with "MK.".
Also, the translation updates shouldn't be part of the patch.
Are you sure about the prefix? I can remove it without a problem, but I did that in order to be consistent with the existing codebase for localflavor. Looking at choices tuples for other localflavors I can see that tupples are prefixed with the country code example:
HR_COUNTY_CHOICES
(this is a new one)
IS_POSTALCODES
US_TERRITORIES
etc...
comment:6 by , 14 years ago
Disregard the pervious comment. I think what jezdez meant is that tuple wasn't prefixed with MK but it should have been. And I thought that I did prefix it. I've attached a patch with my latest work. I tried to keep stuff consistent with what is in other localflavors and reordered some of the code so it's sorted alphabetically.
comment:7 by , 14 years ago
I meant the name of the choice keys, e.g.:
MK_MUNICIPALITIES = ( ('MK.AD', _(u'Aerodrom')), ('MK.AR', _(u'Aračinovo')), # .. )
Unless there is some kind of sensible reason (e.g. a standard or common sense) to prefix the choice key with "MK." we should just leave it out:
MK_MUNICIPALITIES = ( ('AD', _(u'Aerodrom')), ('AR', _(u'Aračinovo')), # .. )
comment:8 by , 14 years ago
OK, got it. I removed the prefix and updated the code and docs accordingly. The reason they were prefixed is that the codes are HASC codes and those are hierarchical and prefixed wit the country code. But, I can't see a scenario where a conflict could arise if they are not.
comment:9 by , 14 years ago
Patch needs improvement: | unset |
---|---|
UI/UX: | unset |
comment:10 by , 14 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
This work looks pretty good and the request is reasonable. Accepting the ticket.
Reading through the patch, I noticed that sometimes the alphabetical order is not respected when inserting MK-related stuff in existing files; this should be fixed.