Default Pluralize logic
alen....@gmail.com
works in django?
a.) pluralize template filter
b.) Meta.verbose_name_plural
As default, I am expecting the pluralize to convert "country" to
"countries". For exapmle, this doesn't happen in admin so I define the
verbose_name_plural in the Meta inner class.
Its straightforward to implement a function that can seemlessly handle
this correctly as default, even if it was to read the pluralization
rules from a rules.<language_code> files or something equivalent.
Regards,
-Alen
Karen Tracey
Could someone please be kind to explain to me how the pluralize logic
works in django?
a.) pluralize template filter
b.) Meta.verbose_name_plural
As default, I am expecting the pluralize to convert "country" to
"countries". For exapmle, this doesn't happen in admin so I define the
verbose_name_plural in the Meta inner class.
Per the doc, the default pluralize (filter) behavior is to simply add an s. If that is not correct for the word in question, then you have to tell the filter what the correct suffix is. The doc also has an example of how to specify that pluralize should change a -y to an -ies.
For the model's verbose plural name, again the doc states the default behavior is to add an s. If that isn't correct, then you need to specify verbose_name_plural, as you have.
Its straightforward to implement a function that can seemlessly handle
this correctly as default, even if it was to read the pluralization
rules from a rules.<language_code> files or something equivalent.
Is it? Maybe. I don't know if anyone has proposed smartening-up Django's pluralization rules in the past (I'm not even sure if you are proposing it here?). My gut feeling is it's probably something that has lots of exceptions/special cases that would make it hard to get entirely right, particularly for all languages, but maybe I'm unduly pessimistic.
Karen
alen....@gmail.com
> pluralization rules in the past
anything directly related.
> (I'm not even sure if you are proposing it
> here?).
understanding of how the pluralize logic currently works in Django.
> My gut feeling is it's probably something that has lots of
> exceptions/special cases that would make it hard to get entirely right,
> particularly for all languages, but maybe I'm unduly pessimistic.
>
However, as default pluralize function, I believe we can handle a lot
more cases compared to the current functionality.
Also, by looking at having language specific rules files (maybe
linking this into the internationalization logic), we can quite easily
train the pluralize function to handle more exceptions/special cases
too without needing to modify the source code (decoupling the rules
from the source code, pluralize function).
The code to enhance the pluralize function is pretty straightforward.
I have already implemented this functionality in my own code base that
I would be happy to share. (I can create a patch/diff if there would
be interest.)
Regards,
-Alen
On May 3, 9:52 pm, "Karen Tracey" <kmtra...@gmail.com> wrote:
> On Sat, May 3, 2008 at 5:39 AM, alen.ri...@gmail.com <alen.ri...@gmail.com>
>
> > Could someone please be kind to explain to me how the pluralize logic
> > works in django?
> > a.) pluralize template filter
>
> Doc for this is here:http://www.djangoproject.com/documentation/templates/#pluralize
>
> > b.) Meta.verbose_name_plural
>
Michael Newman
name plurals are default pulled from a class name that might not
necessarily make sense to my editors in the admin. I need to have some
control to how it is actually displayed to the end user; no program is
going to be able to make my life easier by referencing a translation
block to make my class names read better. Also you assume some
standard in which class names are being written. It is my experience
that people name classes by whatever makes sense at that moment and
starfards are frequently developer/project based.
Michael Newman
On May 4, 2008, at 1:16 PM, "alen....@gmail.com"
Russell Keith-Magee
<alen....@gmail.com> wrote:
>
> > Is it? Maybe. I don't know if anyone has proposed smartening-up Django's
> > pluralization rules in the past
>
> I had a look through the mailing-list archive and couldn't spot
> anything directly related.
Then you haven't looked too hard. Pluralization comes up regularly,
both in the context of the pluralize filter, and the
verbose_name/verbose_name_plural option. And if you're calling
pluralization a simple task, you _really_ haven't done your research.
The short version is that pluralization is _hard_. Automatic
pluralization, which seems to be what you want, is an effectively
impossible task, especially in English. English doesn't have regular
rules for pluralization for anything but trivial cases. About the only
way to do it effectively is to have a dictionary of all possible
plurals - and then you hit the religious wars over whether the plural
of octopus is octopus, octopuses, or octopodes.
Even if you could get English sorted out, then you get the i18n
problem. A few eastern European languages have some very interesting
pluralization rules which further complicates the dream of an
automatic solution.
So, we have settled with the a naive solution, manually assisted, with
template helpers that cover 95% of cases. "Add an s" works for a good
majority of cases - if that isn't correct, you can manually correct it
in verbose_name_plural. The template filter can handle all the english
cases (worst case being different extensions for 1 and many). This
doesn't cover the needs of the previously mentioned eastern European
languages, but accommodating those languages while keeping the simple
case simple is almost impossible, so users of those languages can
write a custom template tag if they need one.
Yours,
Russ Magee %-)
alen....@gmail.com
Just to confirm, I am not referring to a perfect automatic pluralize
solution. I am very well aware that a silver bullet solution would be
very difficult, if even possible.
I will try make myself more clear now. What I am specifically
referring to is the 'verbose_name_plural' of the model.
This is what I have in mind:
1. Django initializes (contributes) the 'verbose_name_plural' on model
class with a call to the pluralize logic to attempt find the relevant
plural for the given singular.
2. If need be, developer overrides the 'verbose_name_plural' in the
model to define specialized plural.
3. Developer calls model_obj.verbose_name_plural in template.
Here is an example adapted from the "Diving into Python" book
regarding the pluralization that I have in mind:
######### plural.py #########
import re
def _regex_rules(lang):
rules_file = file("manager/pluralrules/%s" % lang)
for line in rules_file:
pattern, search, replace = line.split()
yield lambda word: re.search(pattern, word) and re.sub(search,
replace, word)
rules_file.close()
def pluralize(noun, lang='en'):
"""Returns a plural of a given noun"""
for rule in _regex_rules(lang):
result = rule(noun)
if result: return result
######### end - plural.py #########
######### ./pluralrules/en #########
[ml]ouse$ ([ml])ouse$ \1ice
child$ child$ children
booth$ booth$ booths
foot$ foot$ feet
ooth$ ooth$ eeth
l[eo]af$ l([eo])af$ l\1aves
sis$ sis$ ses
man$ man$ men
ife$ ife$ ives
eau$ eau$ eaux
lf$ lf$ lves
[sxz]$ $ es
[^aeioudgkprt]h$ $ es
(qu|[^aeiou])y$ y$ ies
$ $ s
######### end - ./pluralrules/en #########
Change in the Django code
######### django/db/models/options.py ##########
Replace:
-------------------
setattr(self, 'verbose_name_plural',
meta_attrs.pop('verbose_name_plural', string_concat(self.verbose_name,
's')))
With something like:
-------------------
setattr(self, 'verbose_name_plural',
meta_attrs.pop('verbose_name_plural', pluralize(self.verbose_name,
get_locale_code())))
*Note: get_locale_code() would return the current locale code (e.g.
'en' for English).
#############################################
As you can see in the django/db/models/options.py, a model class
contribution is made by adding the attribute 'verbose_name_plural'
with a simple 's' character append logic.
I believe we can handle more than just 's' on initialization with a
similar example as above. (Was very tempted to use the word 'simple'
again. Can't stand the heat though. :-))
Regards,
-Alen Ribic
On May 5, 4:57 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On Mon, May 5, 2008 at 1:16 AM, alen.ri...@gmail.com
Karen Tracey
Thank you for your replies.
Just to confirm, I am not referring to a perfect automatic pluralize
solution. I am very well aware that a silver bullet solution would be
very difficult, if even possible.
I will try make myself more clear now. What I am specifically
referring to is the 'verbose_name_plural' of the model.
This is what I have in mind:
1. Django initializes (contributes) the 'verbose_name_plural' on model
class with a call to the pluralize logic to attempt find the relevant
plural for the given singular.
2. If need be, developer overrides the 'verbose_name_plural' in the
model to define specialized plural.
So you still need to allow for the developer (me) to override the generated plural. Only now it isn't as clear when I need to do that. With the current rule, it is straightforward: if the word isn't pluralized by adding an 's', I need to provide the proper plural myself. With this proposal, I have no idea under what circumstances I need to provide the plural. Seems like I have to go look at the pluralization rules file and try to figure out if my exception is covered. Or just try it out with the default and see if it comes out right. Both seem like more work, and more error-prone, than just providing the proper plural if it isn't formed by adding an 's'.
Karen
alen....@gmail.com
> plural. Only now it isn't as clear when I need to do that. With the
> current rule, it is straightforward: if the word isn't pluralized by adding
The idea is that you wouldn't have to override the generated plural
all that often. However, in Django, there are no real restrictions as
to what the name of the Model class should be in the first place which
makes thinks a lot more challenging when it comes down to converting
singular to plural. Flexibility vs Convention I guess.
Important, related, post on the dev list:
"Ditch pluralisation entirely"
http://groups.google.com/group/django-developers/browse_thread/thread/951d113483083ce9/83c18a7a4b2e136e?lnk=gst&q=plural#83c18a7a4b2e136e
Regards,
-Alen
On May 5, 2:59 pm, "Karen Tracey" <kmtra...@gmail.com> wrote:
> On Mon, May 5, 2008 at 8:20 AM, alen.ri...@gmail.com <alen.ri...@gmail.com>
Russell Keith-Magee
<alen....@gmail.com> wrote:
>
> Important, related, post on the dev list:
>
> "Ditch pluralisation entirely"
> http://groups.google.com/group/django-developers/browse_thread/thread/951d113483083ce9/83c18a7a4b2e136e?lnk=gst&q=plural#83c18a7a4b2e136e
You might want to check the date on that thread before you pull it in
for moral support. November 2005 was in the 'pre-magic-removal' era of
Django - the discussion that is going on there was the start of some
fundamental changes to the way you compose queries - changes that are
now fully integrated into Django.
Yours,
Russ Magee %-)
alen....@gmail.com
> for moral support.
the decision to keep the pluralize simple was discussed and probably
introduced as the way forward at the time. Hence my reference. (Below
the belt Russ! :-))
Non-the less, I do have a better understanding now why it should
perhaps stay as is.
-Alen
On May 6, 1:41 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On Tue, May 6, 2008 at 6:10 AM, alen.ri...@gmail.com
> <alen.ri...@gmail.com> wrote:
>
> > Important, related, post on the dev list:
>
> > "Ditch pluralisation entirely"
Russell Keith-Magee
<alen....@gmail.com> wrote:
>
> > You might want to check the date on that thread before you pull it in
> > for moral support.
>
> If you bothered taking a look at the thread, you would have seen that
> the decision to keep the pluralize simple was discussed and probably
> introduced as the way forward at the time. Hence my reference. (Below
> the belt Russ! :-))
If you felt my comment was below the belt, I apologize. It wasn't
intended as such.
I did look at the thread, and I stand by my point. The discussion you
reference was from a time when pluralization was important for
different reasons. Pre-magic removal (the time from which that thread
comes), the plural name was used as part of the API - i.e., you didn't
ask for Entry.objects.all(), you said entries.get_list(). As a result,
the pluralization process was an important part of the API, so getting
pluralization right was important. The magic removal process turned
pluralization into almost entirely a presentation issue. The
requirements of pluralization in the API are quite different to those
at the presentation layer.
There is a side discussion in the thread about adding pluralize as a
class method. I suspect that this was also on the table for
pre-magic-removal reasons - back in the day, there were limitations on
your ability to associate methods with models. Since the magic has
been removed, this is no longer an issue - if you want to put a
pluralize() method on your models to assist with rendering, you are
free to do so. Regardless, the context for that discussion is quite
different to the context of this current discussion.
Yours,
Russ Magee %-)
alen....@gmail.com
> different to the context of this current discussion.
-Alen
On May 6, 8:43 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On Tue, May 6, 2008 at 2:16 PM, alen.ri...@gmail.com