On Tue, 2007-07-10 at 18:26 +0000, [EMAIL PROTECTED] wrote: > > On Jul 9, 10:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > Maybe an addition to django.contrib.humanize? > > If we decide to only support English, then I am fine with including > this as part of django.contrib.humanize. > If we decide to properly internationalize humanize, then I am fine > with that as well. (you don't use commas in German, you use periods > for instance).
Don't decide that this hinges on "fully internationalize humanize or it shouldn't go there". Incremental changes are good. > There are four reasons why I feel it is better to have this as part of > the core: > 1. Hyphenation is a media standard and crucial for non-html templates. > Sites which want to generate printable PDF's of say conference > programs, or in a standard news media style will want this as much as > they want pluralize, widthratio, rjust, and center. This is more than > a template filter, but is a text utility. Not seeing why that does or doesn't support your argument. It's not something you need all the time (more appropriate to print layout than HTML, as a rule), so including it by default, given that HTML output is the common case, isn't a requirement (and saves on memory usage when its not included, for example). Having it in contrib/ puts it exactly one import away. > 2. reduce duplication of code and confusion > The actual code being duplicated is extremely minimal, but having two > text wrappers in very different locations is confusing to both > developers and users. For template filters, it would be better to have > them documented together. > > 3. Internationalization > To properly implement this we need to integrate with the > internationalization code and have the core language developers help > with maintaining the hyphenation rules. It does not feel DRY to have a > separate internationalization system in humanize, and it does not seem > right to have sections of the core only used by a contrib module > (though this is done for admin). This is a based on a mistaken assumption, it look like. Everything in contrib is already supported by translators. However, there's another consideration here, too: it's highly unlikely that a normal translator will be able to maintain the hyphenation databases. They are very technical data structures. > > In the end if those wiser than I decide it should be in humanize I > have no problem changing the patch and writing up the doc and unit > tests. I will need help with the internationalization parts. I do not > have enough experience with the i18n system to make the proper > architectural decisions. I was thinking about this a bit yesterday. It shouldn't be too hard. I'm a few days away from implementing anything, since I'm not going to instantly bump this to the top of my list, but it's a solvable problem. For my money, if we include this, putting it in contrib somewhere feels better. It will also make maintenance easier, since we can give Ned (or designated sock puppet) commit access to that part of the tree for ongoing bug fixes. Regards, Malcolm -- The early bird may get the worm, but the second mouse gets the cheese. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
