> 1. How many filters are we talking about here? At the very least it > seems like two: one for plain text and one for HTML (since you don't > want tags or character entities getting chopped off partway).
Why not have just truncate and truncate words, both with an argument to truncate html? > 2. How does this interact with internationalization? Not every > language or locale uses an ellipsis for this (and, really, this needs > to be solved regardless so the existing truncate_words can play nice > with non-English use cases). This is an issue for truncate_words too, which is solved by adding an argument ellipsis="...". > 3. Similarly to the above two, how does this interact with languages > which commonly use composed characters in Unicode? Cutting a character > in half (and thus presenting output that's completely wrong) probably > isn't expected behavior, so how would such a filter deal with this? > Would it need to do Unicode normalization as well? When truncating characters, we are obviously talking about truncating just that: characters. Truncating bytes is a behaviour implemented by |slice. > 3. Is adding more filters really the way to do this? Could existing > filters have their functionality expanded instead? That's.. Well, if we go with what I described in my first answer, we will still only have two filters, but with additional behaviour. Truncating characters with truncate_words wouldn't make any sort of sense, so I'm positive if we do add a character truncating feature, it will require a new filter. As I also said a while ago, users just expect it to be called "truncate". If you have further questions/opinions (this goes for everyone against adding such a filter), voice them just like this and they will get an answer. Asking for people to "stop saying +1" just makes you look like you don't want people disagreeing with you. J. Leclanche / Adys On Thu, Dec 31, 2009 at 12:46 AM, James Bennett <ubernost...@gmail.com>wrote: > On Wed, Dec 30, 2009 at 2:35 PM, Jerome Leclanche <adys...@gmail.com> > wrote: > > This thread is 20 hours old, you've got a bunch of people who made clear > > points on why the filter was needed/expected. You don't want to take > lesson > > off that? fine, as I said you can browse IRC logs, or even google > > results[1]. I don't see anywhere any kind of mention of the "slice" > filter > > which, so far, has been the only working replacement proposed. > > [1] > http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=django+truncate+filter > > And yet there's also been some legitimate pushback, and no real > response to actual design problems raised by the proposal. Instead of > the litany of "+1, everybody needs this and it's so trivial, why won't > you listen to us", how about giving good answers to the following > questions: > > 1. How many filters are we talking about here? At the very least it > seems like two: one for plain text and one for HTML (since you don't > want tags or character entities getting chopped off partway). > > 2. How does this interact with internationalization? Not every > language or locale uses an ellipsis for this (and, really, this needs > to be solved regardless so the existing truncate_words can play nice > with non-English use cases). > > 3. Similarly to the above two, how does this interact with languages > which commonly use composed characters in Unicode? Cutting a character > in half (and thus presenting output that's completely wrong) probably > isn't expected behavior, so how would such a filter deal with this? > Would it need to do Unicode normalization as well? > > 3. Is adding more filters really the way to do this? Could existing > filters have their functionality expanded instead? > > These types of questions have to have answers before I'll even think > about supporting a change, but so far I don't really see anyone > proposing answers -- just an endless litany of "me too"-type comments > which don't add anything useful to the discussion. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
