Re: Default Pluralize logic
> Regardless, the context for that discussion is quite > different to the context of this current discussion. I take back what I said on my last note. -Alen On May 6, 8:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Tue, May 6, 2008 at 2:16 PM, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> 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 %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
On Tue, May 6, 2008 at 2:16 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
> 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! :-)) 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" <[EMAIL PROTECTED]> wrote: > On Tue, May 6, 2008 at 6:10 AM, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > > Important, related, post on the dev list: > > > "Ditch pluralisation entirely" > > http://groups.google.com/group/django-developers/browse_thread/thread... > > 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 %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
On Tue, May 6, 2008 at 6:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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=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 %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
> 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'.
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=plural#83c18a7a4b2e136e
Regards,
-Alen
On May 5, 2:59 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Mon, May 5, 2008 at 8:20 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > 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
>
> > 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" <[EMAIL PROTECTED]>
> > wrote:
> > > On Mon,
Re: Default Pluralize logic
On Mon, May 5, 2008 at 8:20 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>
> 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
> 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" <[EMAIL PROTECTED]>
> wrote:
> > On Mon, May 5, 2008 at 1:16 AM, [EMAIL PROTECTED]
> >
> > <[EMAIL PROTECTED]> 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
Re: Default Pluralize logic
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.
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" <[EMAIL PROTECTED]>
wrote:
> On Mon, May 5, 2008 at 1:16 AM, [EMAIL PROTECTED]
>
> <[EMAIL PROTECTED]> 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 %-)
Re: Default Pluralize logic
On Mon, May 5, 2008 at 1:16 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
I think you are assuming too much here. The verbose name and verbose 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, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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. > >> (I'm not even sure if you are proposing it >> here?). > > I pretty much am proposing it here. I wanted to confirm my > 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. >> > > Example of some exceptions/special cases are irregular plural nouns. > 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" <[EMAIL PROTECTED]> wrote: >> On Sat, May 3, 2008 at 5:39 AM, [EMAIL PROTECTED] >> <[EMAIL PROTECTED]> >> wrote: >> >>> 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 >> >> Doc for this is >> here:http://www.djangoproject.com/documentation/model-api/#verbose-name-pl >> ... >> >>> 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. 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 > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
> 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. > (I'm not even sure if you are proposing it > here?). I pretty much am proposing it here. I wanted to confirm my 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. > Example of some exceptions/special cases are irregular plural nouns. 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" <[EMAIL PROTECTED]> wrote: > On Sat, May 3, 2008 at 5:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > 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 > > Doc for this is > here:http://www.djangoproject.com/documentation/model-api/#verbose-name-pl... > > > 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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Default Pluralize logic
On Sat, May 3, 2008 at 5:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 > Doc for this is here: http://www.djangoproject.com/documentation/model-api/#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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
