Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I admit, I have my own truncate filter on my website so why should I care about bringing the truncate filter up? Heck, I've got a pretty big patchset of features I need but "just wont be accepted". However, feedback on an application can come from anywhere. When someone just discovers a framework,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Right, sorry -- I'm gonna have to go with Eric on that, there are builtin libraries that do just that (from unicodedata import normalize). J. Leclanche / Adys On Thu, Dec 31, 2009 at 1:30 AM, James Bennett wrote: > On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche wrote: > When truncating characters, we are obviously talking about truncating just > that: characters. Truncating bytes is a behaviour implemented by |slice. You misunderstand: I'm not talking about bytes, I'm talking about

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 4:46 pm, James Bennett wrote: > 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). Right now what's on the

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

> 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.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 2:35 PM, Jerome Leclanche 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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

What's this supposed to mean? If something is trivial to implement, it shouldn't be in the core? Tell me I'm reading it wrong, please, because I can think of 1000 reasons why this argument doesn't hold ground. J. Leclanche / Adys On Wed, Dec 30, 2009 at 11:39 PM, Alex Gaynor

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 3:36 PM, dannyr wrote: > > Alex, > > What's the rationale of including truncatewords into the core? How is > truncatewords different to truncate (characters)? > > On Dec 30, 12:29 pm, Alex Gaynor wrote: >> Ok, we get it, some

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex, What's the rationale of including truncatewords into the core? How is truncatewords different to truncate (characters)? On Dec 30, 12:29 pm, Alex Gaynor wrote: > Ok, we get it, some people want this feature.  I'd like to kindly > request that people just saying

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

flo...@gmail.com wrote: > I have a custom filter that does just this that I use in virtually > every single Django project I use. It's such a common pattern that it > seems almost silly not to have it included in core. It's also small > enough that it won't add much in the way of maintenance.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 12:49 pm, Sean Brant wrote: > The last thing that needs to happen is bulling this into core. It's no > good for the community and that could be part of the perceived > perceptions problem. Just because enough people bitch does not mean > that its a good thing.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Couldn't this problem actually be solved by actually just expanding the truncate_words syntax? instead of just allowing :"nr_of_words" to something like 'count[cw],ellipsis'. e.g. '10c,...' actually meaning cut after 10 characters instead of words, of course always rounded up or down for the last

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

The last thing that needs to happen is bulling this into core. It's no good for the community and that could be part of the perceived perceptions problem. Just because enough people bitch does not mean that its a good thing. With that said the reason behind the ticket being closed no longer seems

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On 12/30/09 3:29 PM, "Alex Gaynor" wrote: > Ok, we get it, some people want this feature. I'd like to kindly > request that people just saying "+1" stop. The number of people in > this thread is minuscule compared to the size of the django user > population, trying to

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 3:29 PM, Alex Gaynor wrote: > The video I linked earlier had a critical point that I think a lot of > people are missing, adding a single filter may not add a lot to the > developer's burden directly but it impacts the perceptions (and > realities)

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

PS; I don't see anybody "just saying +1". So far everyone has explained why they agree with inclusion, which is not the case of most of the (very few) comments against inclusion. J. Leclanche / Adys On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it, some people want this feature. I'd like to kindly > request that people just saying "+1" stop. The number of people in > this thread is minuscule compared to the size of the django user > population,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I think umovi makes a great point here when he mentions that templates are often used for things that are not HTML. "Be decoupled from HTML" is one of the core design philosophies listed in the docs. I'm not really advocating for or against adding a truncate filter, but I do think that "you

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Ok, we get it, some people want this feature. I'd like to kindly request that people just saying "+1" stop. The number of people in this thread is minuscule compared to the size of the django user population, trying to extrapolate from 1, 10, or even 100 people in this thread to a large

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I'm +1 on adding a string truncation filter. I've yet to see a good reason not to, and there have been countless times I've needed it on real-world projects. As someone who has used the Django template language perhaps more extensively than anyone else out there, and as someone who has written

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Seems this thread is saying a few things: 1) It's already there with slice or using a CSS hack (eek!) 2) You should never truncate text on character boundaries anyways 3) Nobody is asking for it I'm new to Django and my first order of business was creating a truncate filter because I couldn't

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Just to add more confusion to this, how is truncation handled in other languages? Is it always and ellipse? What about Chinese, Japanese, Korean, and Arabic? I recently had to do some truncation stuff and switch from an ellipse to an image overlay with CSS that faded out the line at the end

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I use templates sometimes to produce plain text, emails *without html*, etc, so CSS is not always a solution. -- 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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 7:06 am, Russell Keith-Magee wrote: > Secondly, IMHO raw truncation based on characters is bad practice for > human readable text. A sentence is composed of words, not characters. > Truncating a sentence mid-word isn't a typographical practice that I >

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 11:50 AM, David Zhou wrote: > Using CSS to truncate email addresses defeats the purpose of > truncating email addresses.  Not exactly "better", is it? That depends on whether your purpose is to make it fit in the space allotted, or to obfuscate the

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 1:37 PM, Ian Kelly wrote: > All of which could be handled just as well or better using CSS, unless > there's something I'm missing, which is the reason I asked. Using CSS to truncate email addresses defeats the purpose of truncating email

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

The css tricks you linked are shady towards cross-browser compliance. Using XUL on a website just to have it working in firefox? No, thank you. What about serving plain text or actually any kind of non-html content? Why would I use CSS there? How far are you going to go just to prove that every

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 11:21 AM, Jerome Leclanche wrote: > > On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly wrote: >> >> What I haven't seen yet for this filter is a clear use case.  If >> you're just trying to get something working quickly, then slice is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly wrote: > > What I haven't seen yet for this filter is a clear use case. If > you're just trying to get something working quickly, then slice is > fine. When you're ready to go back and do it right, then the optimal > solution is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:25 AM, Nic Pottier wrote: > On Dec 30, 8:55 am, Alex Gaynor wrote: >> I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it >> this *exact* question >> comes up and Russ, Malcolm, and a few other

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 8:55 am, Alex Gaynor wrote: > I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it > this *exact* question > comes up and Russ, Malcolm, and a few other people discuss the pros > and cons of adding new template tags/filters. > > Alex

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:53 AM, Nic Pottier wrote: > On Dec 29, 10:01 pm, Alex Gaynor wrote: >> Adding the ellepsis is as simple as: >> >> {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} >> >> Given that the recent expansion of the {%

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee wrote: > Secondly, IMHO raw truncation based on characters is bad practice for > human readable text. A sentence is composed of words, not characters. > Truncating a sentence mid-word isn't a typographical practice

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 29, 10:01 pm, Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} > > Given that the recent expansion of the {% if %} tag makes that so easy > I don't think it's a compelling reason to add a {%

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 2009, at 6:06 AM, Russell Keith-Magee wrote: > Firstly, as James points out, slice already exists, and the ellipsis > difference between slice and truncate can be easily overcome with > additional code. In the past I have had the need for a filter that works not just on the end of

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Dec 30, 2009 at 08:06:02PM +0800, Russell Keith-Magee wrote: > On Wed, Dec 30, 2009 at 8:15 AM, Nic Pottier wrote: > > > > New to Django, but certainly not web development.  After being > > pleasantly surprised with a

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

There is a truncate filter, it's called 'slice': http://docs.djangoproject.com/en/1.1/ref/templates/builtins/#slice To show the first 10 chars do: {{ mystring|silce:":10" }} There's also truncatewords to make sure you always get whole words:

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 8:15 AM, Nic Pottier wrote: > > New to Django, but certainly not web development.  After being > pleasantly surprised with a lot of the available Django filters I was > rather surprised not to see a string truncation filter included. > > A little

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} Come on Alex, in what universe it qualifies as "simple"?! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I have a custom filter that does just this that I use in virtually every single Django project I use. It's such a common pattern that it seems almost silly not to have it included in core. It's also small enough that it won't add much in the way of maintenance. Also, there already exists a

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Will, I meant its usage on strings. Admittedly, it's probably not the best thing to do. On Wed, Dec 30, 2009 at 8:11 AM, Thomas K. Adamcik wrote: > On Wed, Dec 30, 2009 at 08:04:47AM +0200, Jerome Leclanche wrote: > > Users expect it to be called "truncate", that alone is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 08:04:47AM +0200, Jerome Leclanche wrote: > Users expect it to be called "truncate", that alone is sufficient reason. > There's truncate_html, truncate_words. Designers and others who are not familiar with Python might expect the 'truncate' name. While developers

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

> Deprecate slice, move it to "truncate" and add the ellipsis for consistency. Slice has other uses, please don't deprecate it :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Users expect it to be called "truncate", that alone is sufficient reason. There's truncate_html, truncate_words. Deprecate slice, move it to "truncate" and add the ellipsis for consistency. No harm done, happy users. J. Leclanche / Adys On Wed, Dec 30, 2009 at 8:01 AM, Alex Gaynor

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Tue, Dec 29, 2009 at 11:59 PM, John Debs wrote: > > > On Dec 29, 9:08 pm, James Bennett wrote: > >> It is built in, though, it's just called "slice". The only thing >> people seem to offer to differentiate this proposal from the existing >> filter

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 29, 9:08 pm, James Bennett wrote: > It is built in, though, it's just called "slice". The only thing > people seem to offer to differentiate this proposal from the existing > filter is that the proposed "truncate" would add an ellipsis at the > end, and honestly

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Tue, Dec 29, 2009 at 6:15 PM, Nic Pottier wrote: > I'd be curious to hear what the reason for not accepting this patch > is.  String truncation is a pretty common task, and having it built in > seems like a no-brainer. It is built in, though, it's just called "slice".

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Last time I asked on IRC, dev answer was "because nobody asked for it". Of course one could cat ~./irc/logs/django | grep -i truncate and just look at how ridiculous that statement is. Unfortunately, more often than not, the needs of the developers don't leave room for contributions from other