#4036: Spanish (es) localflavor
------------------------------------------------+---------------------------
Reporter: [EMAIL PROTECTED] | Owner: oggie_rob
Status: new | Component:
django.contrib.localflavor
Version: SVN | Resolution:
Keywords: spanish es l10n i18n localflavor | Stage:
Accepted
Has_patch: 1 | Needs_docs: 0
Needs_tests: 1 | Needs_better_patch: 1
------------------------------------------------+---------------------------
Comment (by oggie_rob):
Replying to [comment:9 garcia_marc]:
> Hi oggie_rob, firs of all sorry for submitting a patch without letting
you know that I was working on that, but the fact is that I couldn't find
this ticket until I finished my work.
>
> I've checked your code and there is something that IMHO shouldn't be
like that, and it's arguments Nif and Cif. Whan you have to validate a NIF
field, usually is the customer or the provider in an invoice, and you
cannot know in advance if you are going to sell something to a company
(that has a CIF code), or to a individual (that has a NIF/NIE code). So I
think that you cannot pass an argument to specify it, you have to check it
inside the function.
>
> Anyway, I think that you're using some code better than mine, so any
kind of merge of both functions would be great. If you want me to assign
this ticket to myself, and make those final stepe, please let me know.
Hi garcia_marc,
My greatest concern about this is that I'm not sure I got the specs right.
I learned about these values by looking at the original patch and by
searching online for specifications (mainly from Wikipedia, as I couldn't
find many technical references). Also Spanish is not my first language,
although I feel that I understood most of the articles well enough. Having
said that, it seems to match up with what I had seen online.
Here are some of the things I considered when I was writing this:
1. As opposed to the original code, normalization and validation should
be the only functions of the Identity card field. We shouldn't suggest any
possible answers, as people really should know their own NIF in full
2. Translating the province names seems unnecessary and potentially a lot
of work, so I left them in unicode (rather than ugettext)
3. There are situations where users know if they will expect a NIF/NIS or
CIF, and so the author should be able to limit those choices. However, by
default both schemes are allowed. Your example of an invoice is one where
you need to allow both types, but in another example (e.g. an employee
form) you might only expect a NIF/NIS. It doesn't hurt to leave as-is.
If you would like to take it over, that would be fine by me. I think that
including the two-digit province code is an improvement, although the two-
character lookup is also handy. Something that allows searching of both of
those would be ideal.
Thanks,
-rob
--
Ticket URL: <http://code.djangoproject.com/ticket/4036#comment:10>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
