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

[Nic Pottier]

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 googling shows I'm not the only one, there are tons of people
writing their own filters to accomplish this, and sure enough a nice
looking patch submitted two (TWO!) years ago to add a |truncate.

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.

For your reference, here's the ticket and patch:
<http://code.djangoproject.com/ticket/5025>

Thanks,

-Nic

[Jerome Leclanche]

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

J. Leclanche / Adys

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[James Bennett]

On Tue, Dec 29, 2009 at 6:15 PM, Nic Pottier <nicpo...@gmail.com> 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". 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 I'm not really convinced that's a significant enough
use case to warrant adding another built-in filter.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[John Debs]

On Dec 29, 9:08 pm, James Bennett <ubernost...@gmail.com> 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 I'm not really convinced that's a significant enough
> use case to warrant adding another built-in filter.

For what it's worth, it's something I've wanted (and wondered about)
for several of my projects, and I've heard the same from others. It
seems to me that more often than not, developers want an ellipsis when
truncating strings like that.

I thought about suggesting adding an option to the existing slice
filter but I really think that's its own use case and that there
should be a new truncatestring filter that matches the syntax of
truncatewords.

It's especially unclear to new developers that they should accomplish
this with slice (and an if statement checking the length of the
string) - and it's not very DRY. The convenience of having slice is
undermined by the fact that many aren't clever enough to use it this
way - it certainly didn't occur to me.

So, +1 to this idea.

John

[Alex Gaynor]

> --
>
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>

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 {% truncate %} tag.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Jerome Leclanche]

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

[Will Hardy]

> Deprecate slice, move it to "truncate" and add the ellipsis for consistency.

Slice has other uses, please don't deprecate it :-)

[Thomas K. Adamcik]

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 experienced with Python see this as list
slicing, thus the 'slice' name.

> Deprecate slice, move it to "truncate" and add the ellipsis for consistency.
> No harm done, happy users.

Renaming will thus only move the problem, what might come closer to real fix here
is documenting that slice can be used as a truncate-filter.

-Thomas Adamcik

[Jerome Leclanche]

Will, I meant its usage on strings. Admittedly, it's probably not the best thing to do.

As an experienced python developer, I don't expect a "slice" filter on strings, just as much as I'd expect a getattr filter. If I do know about the slice filter, yes, I'd expect it to work on strings.

Here is the real issue, people are asking for a truncate filter and have been for at least two years. As I said, you just have to grep irc logs to see just how often this comes up. You can't say "the situation is fine" and not change anything. Docs have to be clarified, and to be honest I don't see the actual harm in adding an additional truncate filter. There are other, much less commonly-used filter which should move out of the core. Looking randomly at the list, one example between ten would be phone2numeric.

Enough from me for now, late night (early morning) calls.

[flo...@gmail.com]

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 truncate_words, which has nice symmetry with the
proposed name. Finally, as has been said before, it's something that
new users intuitively expect to find, so let's not disappoint them.

I quite strongly feel that slice is not a suitable alternative,
because 1) adding the ellipses requires a non-trivial amount of
additional template logic (and this logic need be repeated every time
ellipses are wanted) and 2) it makes the actual markup of the template
less semantically relevant.

Count me as a big +1 for including this.

Thanks,
Eric Florenzano

[Ivan Sagalaev]

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"?!

[Russell Keith-Magee]

On Wed, Dec 30, 2009 at 8:15 AM, Nic Pottier <nicpo...@gmail.com> 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 googling shows I'm not the only one, there are tons of people
> writing their own filters to accomplish this, and sure enough a nice
> looking patch submitted two (TWO!) years ago to add a |truncate.
>
> 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.

I disagree.

Firstly, as James points out, slice already exists, and the ellipsis
difference between slice and truncate can be easily overcome with
additional code.

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
particularly want to encourage.

I would be marginally more inclined to support a truncate filter that
obeyed word boundaries i.e., no more than 50 characters, but stop at
the end of the last complete word. However, even with this
modification - what's the use case for an N character truncation? It
can't (or shouldn't be) to make sure that text will fit into a visual
space. You can't guarantee how wide N characters will be at
render-time due to differences in character width. If you want to
truncate for display purposes, you should be looking at CSS overflow
properties or other display-level tricks.

So - put me down as -0 as well. I just don't see that there is a huge
gain in adding another built-in filter. If you really have a need for
this filter, it's easy to support it as an external library.

As for why this patch has languished for so long - one major reason is
that nobody has made an issue of it previously. By my count, this
thread is only the third time that someone has made the case for a
built-in truncate filter, and one of those times was as a late
addition to a thread about adding a completely different bunch of
tags.

Yours,
Russ Magee %-)

[Ratty]

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:
http://docs.djangoproject.com/en/1.1/ref/templates/builtins/#truncatewords

Hope that helps,
Ryan

[Arthur Furlan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This feature, of truncating in word bondaries or truncating
based on characters, could be added as an option. I think it's valid
to take a look at the truncate[1] filter of the Smarty Template Engine
because it solves some of the problems that have been discussed here.

[1]. http://www.smarty.net/manual/en/language.modifier.truncate.php

- --
Best regards,

Arthur Furlan (afurlan)
afu...@afurlan.org
http://blog.afurlan.org
Public GPG KeyID: 27D81084

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLO0fKAAoJEOW5JtQn2BCENIMP/0ex/IKnSFlwHwQTiclfnRyK
ooXODJXsk90sh8GaocLBic3NJ+pminMKHclavZKdlXYgA9RSMTlfLXRJU7WFvEJx
hZ5U2eDUGXyMy++Onj04fAJG8Q7+4mRRlgkEH520b2RRPndyBw4RMpbIaTYzi+Pc
FA1hgTmK+j3ojbkRZeQIYn3w53n0R4n990YumrfclcpOtWc7/YW0g0+uEBdLJ4pZ
B8uAFlDZCABcfj6wS6kewJfXRxDzX+6ch5cMgTle1LfRlWOyu+RAeV5An8fxykw9
pGZClIVHrE5zeFus8J7RawnodbaiuxfTgEGnWqLii/ddrjBEMebeKOrWaEYen/bF
30jFbrfJ+OcqSJJQZO5rqA27ihFpEQH2Qlo297OlJo3yGN2AKVMGMjRERYKRipf6
Wr7JsHYACxxHi1cGtodoBUKuwIDb28UpaIjgTbgU70BwiOYdfO3nU3zDf/sigarz
2HV7OZQYOqoXyf3tQPu/vQ44nompG/zxpdXJAf3dMcZ/HtmAB06a+XROeoq7SkGu
FZllvvIY27x56M6WIw8ZwHJqSfq9u7HGNhJBLRY+dxB6rbAWqDPLyMNvlibzLT+6
H0c+C+Es6qA2HrCt9Oo5nrnMQWw9Xwd/uGdocQBZUY9w7kXzCPIQcXkubhxhwLn6
9SSLNn5nUbJ5xqLZ9f3e
=UCaA
-----END PGP SIGNATURE-----

[Sean Brant]

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 the string but sometimes in the middle. For example truncating a long filename, you might want to show the first bit and the last it.

myfilewithasuperlong...thisnameisreallylong.jpg

Doing this in the template is not a good idea, but with a template filter you can do it with an extra argument.

+1

[Nic Pottier]

On Dec 29, 10:01 pm, Alex Gaynor <alex.gay...@gmail.com> 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 {% truncate %} tag.
>
> Alex

Thank you for acknowledging that slice is not at all the same thing as
a real truncate. Having that kind of {% if %} scattered around your
templates is exactly the reason we need a filter.

Perhaps the use case just hasn't been explained enough.
truncate_words is not the same thing, and should indeed be used if you
are truncating a paragraph of text. truncate comes in when you have a
URL or filename, which won't have any spaces and you don't want to
blow off the end of your div or ruin your table cells.

I guess I don't understand the big drawback? There is obviously a
need, some quick googling finds quite a few independent
implementations of this filter for Django, plus we have a few patches
submitted, some IRC logs, and the people who've piped up on this list.

Is there a big overhead I'm not seeing in adding this filter, either
in performance or maintenance? It certainly seems like a lot of users
want it, and as others have said, it probably would garner more usage
than some of the other stranger filters present in core.

-Nic

PS. I agree that smarty's truncate seems like a pretty reasonable spec
if we really want to do it right:
<http://www.smarty.net/manual/en/language.modifier.truncate.php>

I'd be perfectly willing to write up a patch to that spec against the
current code base if I knew it wouldn't languish.

[Jerome Leclanche]

On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee <freakb...@gmail.com> 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
particularly want to encourage.

Please...

Please, please, please, do NEVER assume the use cases on your own websites are the only ones other users will ever need.

Are you going to truncatewords on long filenames?

What about on hashes? On Email addresses?

Here is where I use truncate: http://db.mmo-champion.com/i/35191/schematic-wonderheal-xt68-shades/ - bottom of the right box. I can't truncate such small names based on words alone. 

> As for why this patch has languished for so long - one major reason is
> that nobody has made an issue of it previously. By my count, this
> thread is only the third time that someone has made the case for a
> built-in truncate filter

Oh NO you don't. PLEASE. grep your irc logs for truncate+filter, I know you've been on irc long enough.

J. Leclanche / Adys

 

[Alex Gaynor]

> --
>
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>

I'd highly recommend watching
http://www.youtube.com/watch?v=tscMnoS4YU8 in 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.

[Nic Pottier]

On Dec 30, 8:55 am, Alex Gaynor <alex.gay...@gmail.com> 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

Thanks, that's a useful link. The relevant portion starts at ~15:00
for those that are interested.

But really, the sum total of that discussion with regards to truncate
seemed to be:
1) truncate doesn't exist because it wasn't useful in Journalism
2) you can add it yourself
3) we cover 80/20

What it explicitly doesn't say is that there is a huge cost to having
a new filter in core.

Don't get me wrong, I absolutely agree on the 80/20 principle, and on
that a clean and simple interface is hugely valuable. (The PHP mess is
a clear counterpoint here)

But I disagree that truncate is somehow an esoteric filter. RoR has
it, Smarty has it, as do countless others, it just isn't that
unusual.

-Nic

[Ian Kelly]

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 to use CSS [1]. If you only want to truncate at word
boundaries, then you'll just use truncate_words. What requirement
does a truncate filter satisfy that these other solutions don't?

[1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/

Ian

[Jerome Leclanche]

On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly <ian.g...@gmail.com> 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 to use CSS [1].  If you only want to truncate at word
boundaries, then you'll just use truncate_words.  What requirement
does a truncate filter satisfy that these other solutions don't?

[1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/

Ian

Then perhaps you should read the past few mails, I've given 5 different use cases.

J. Leclanche / Adys

[Ian Kelly]

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.

Ian

[Jerome Leclanche]

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 single person who has ever asked for a "truncate filter" is wrong? because there's a hell of a lot of them.

J. Leclanche / Adys

Ian

[David Zhou]

On Wed, Dec 30, 2009 at 1:37 PM, Ian Kelly <ian.g...@gmail.com> 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 addresses. Not exactly "better", is it?

CSS is not a universal panacea.

-- dz

[Ian Kelly]

On Wed, Dec 30, 2009 at 11:50 AM, David Zhou <da...@nodnod.net> 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 address. I had understood it to be the
former. For the latter, using truncate isn't a good solution either.
What if the address happens to be shorter than the truncated length?

Ian

[John Debs]

On Dec 30, 7:06 am, Russell Keith-Magee <freakboy3...@gmail.com>
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
> particularly want to encourage.

I think the question that needs to be asked now is: What would it take
to convince the core members that this belongs in core?

There are obviously a *lot* of django developers that want this, best
practice or not, and web development is often about making trade-offs
that work best for your scenario. Two of Django's core philosophies
(correct me if I'm wrong...) are making common developer tasks easy,
and keeping things DRY, and the current state of string truncation in
Django is neither of those things.

I've seen a few +1's but no -1's, despite some resistance. Can we get
the opinions of a few more core developers so that this has a chance
of slipping in before the Jan. 5 feature deadline?

[umovi]

I use templates sometimes to produce plain text, emails *without
html*, etc, so CSS is not always a solution.

[Peter Landry]

Hello,
To address specifically this point, I would suggest that there might be use
cases where CSS isn't available to accomplish truncation (non-HTML text
output). It would be hard predict with certainty every context in which a
django template will be rendered.

Peter

[varikin]

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 because of the translation issues of truncating.

I really don't think this is worthwhile because it is easy to write
truncation to meet your requirements. One person wants word
boundaries, another wants ellipse in the center for long names.
Someone else might not want any ellipse, but not now to just use slice
instead. I see truncation as a design decision. Can true filter be
added such that it works for 80% of the use cases while being easy to
use?

[Eric]

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 find one. I also found it pretty
odd that it wasn't supported out of the box. I don't think slice is
the same thing since ellipses are important in this case and adding
conditionals in templates to accomplish this is cumbersome and sloppy.

I also feel the argument that there is no reasonable scenario for
wanting to truncate text on character boundaries is pretty arrogant.
I've found many situations where this is desirable -- like the long
file paths mentioned earlier.

I joined this group, just so I can ask for it to be added to core. It
doesn't look like I'm alone.

I don't understand the argument for not including it. It's pretty
obviously wanted and it's not going to turn journalism on it's ear.
It would appear there is also very little cost to including it.

Eric

[je...@jeffcroft.com]

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 books on CSS and web
standards, I can confirm without a doubt that string truncation is
needed in the real world, and that accomplishing it using slice and
adding the ellipsis using template code, as Alex Gaynor suggested, is
both ugly and not DRY at all.

So...why not?

[Alex Gaynor]

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 percentage of the community wants this is
simply not possible.

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) of what kinds of things are reasonable for inclusion in
core. The simple fact is some people want this, and some don't. Not
having this is not an intractable problem for people who need it, in
fact it's a trivial one.

I don't really care whether this is included or not, but it seems to
me that there's very little in terms of new ground in the discussion.

[Taylor Marshall]

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 should be using CSS instead" is an invalid argument against it.

On Wed, Dec 30, 2009 at 2:33 PM, umovi <ad...@todanoticia.com> wrote:
> I use templates sometimes to produce plain text, emails *without
> html*, etc, so CSS is not always a solution.
>

[Jerome Leclanche]

On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor <alex....@gmail.com> 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 extrapolate from 1, 10, or even 100 people in
this thread to a large percentage of the community wants this is
simply not possible.

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

[Jerome Leclanche]

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 <alex....@gmail.com> wrote:

--

[David Zhou]

On Wed, Dec 30, 2009 at 3:29 PM, Alex Gaynor <alex....@gmail.com> 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) of what kinds of things are reasonable for inclusion in
> core.

No one's ignoring that. But the truncate filter, specifically, isn't
breaking new ground in terms of included filters. There's *already* a
truncatewords filter. Adding this will not meaningfully impact the
perceptions of core.

-- dz

[Peter Landry]

On 12/30/09 3:29 PM, "Alex Gaynor" <alex....@gmail.com> 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 extrapolate from 1, 10, or even 100 people in
> this thread to a large percentage of the community wants this is
> simply not possible.
>
> 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) of what kinds of things are reasonable for inclusion in
> core. The simple fact is some people want this, and some don't. Not
> having this is not an intractable problem for people who need it, in
> fact it's a trivial one.
>
> I don't really care whether this is included or not, but it seems to
> me that there's very little in terms of new ground in the discussion.
>
> Alex

Sorry if this takes things too far off-topic, but what is the proper way to
express support for a feature/ticket then? If the original argument is "not
enough people want it", I think it's fair that people voice their support,
and most have included specific use cases. What is the alternative?

Peter

[Sean Brant]

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

A template filter for shortening a string seems like a logical
addition to truncatewords. At the very least reassessing the ticket
status might be a good start.

[Killian De Smedt]

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 word so we don't end in the middle, and finally having a 3-dot ellipsis. This can be done perfectly backwards-compatible as far as I know and doesn't flood the namespace with dozens of filters with similar functionality. Adding truncate now would mean a 3th filter that does more or less the same (and then I even don't count slice), which in my opinion is only even more confusing.

I'm also no big fan of putting this logic into templates anyway, I think too many people use views just as a passthrough for object managers and do the real data transform for viewing in the template, which isn't the purpose of a template language. In general I am even against many of the already included filters, so for me adding a new filter is certainly vote -1.

2009/12/30 Sean Brant <brant...@gmail.com>

[Nic Pottier]

I'll make this my last reply.. promise. :)

But how is this bullying?

I mean, there was a clean patch submitted, complete with unit tests,
years ago. There is clearly demand, and has been for at least a few
years.

If anything, the bullying seems to be against the 'users' by the
'devs' rather than the other way around. It all seems like a bit of a
mountain out of a mole hill. It is one tiny filter, with clear demand
and no side effects to other parts of the system. I couldn't think of
a lower risk patch.

I guess my question is, what in the world is the minus? You satisfy a
demonstrated need for a very low effort and with no side effects.

As a last little quip, I have to say I do understand the resistance to
change, and also fully understand how one becomes a bit entrenched in
a way of doing things after working on a product for many years. But
at the same time, you really have to appreciate what users, especially
NEW users say about their experience. It is near impossible to get
into that mindset again after you have used a system for a while.
Yes, truncate is something that is easily worked around, but it is
also something that lots of new users to Django seem to miss, and it
is a shame to make them all reinvent that wheel again and again.

That is all from me. ;)

-Nic

[Bas van Oostveen]

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. Also, there
> already exists a truncate_words, which has nice symmetry with the
> proposed name. Finally, as has been said before, it's something that
> new users intuitively expect to find, so let's not disappoint them.
>
> I quite strongly feel that slice is not a suitable alternative,
> because 1) adding the ellipses requires a non-trivial amount of
> additional template logic (and this logic need be repeated every time
> ellipses are wanted) and 2) it makes the actual markup of the template
> less semantically relevant.
>
> Count me as a big +1 for including this.
>
> Thanks,
> Eric Florenzano
>
>

Agree +1 on including it into Django.
(both truncate and truncate_html)

I'm having similar experiences as Eric, think 7 out of 10 sites
eventually use it in one way or another. To give some quick
examples; filenames, links, fullnames with hover, limiting user
generated content, csv exports, etc.

Sometimes in conjunction with truncate_words, like:

{{ content|truncate_words:40|truncate_letters:200 }

To make sure that text (mostly from user content, or scrapers)
get's limited to some fair amount even one words are extremely
long.

We also include it in django-extensions as truncate_letters.

It always seemed strange why truncate_words is included and
something to truncate letters isn't. Seems a logical pair

I also feel slice isn't an alternative, if it where then by the same
token we could remove truncate_words because you could also
split and slice. And it means repeating yourself many times over
when it can be solved with a simple template_tag.

Regards,
Bas

[dannyr]

Alex,

What's the rationale of including truncatewords into the core? How is
truncatewords different to truncate (characters)?

[Alex Gaynor]

> --
>
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>

Probably that truncate_words is *slightly* less trivial to implement.
Plus it's been there since forever, removing it would be an extremely
large backwards compatible change.

[Jerome Leclanche]

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

[James Bennett]

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

[Jerome Leclanche]

> 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

--

[flo...@gmail.com]

On Dec 30, 4:46 pm, James Bennett <ubernost...@gmail.com> 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 table with #5025 is a single filter: truncate.

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

I agree that this is a separate issue that needs to be solved for
truncatewords.

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

Good catch! Quite an edge case, but luckily it turns out the
unicodedata module from the standard library can do all of the
normalization for us.

> 3. Is adding more filters really the way to do this? Could existing
> filters have their functionality expanded instead?

I think the filter in the patch is the clearest way of expressing this
idea. That being said, I'm sure proposals to other filters would be
met with consideration.

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

It's no use discussing these details if the core committers and
influential contributors are against the idea of a truncate filter in
general.

I'd like to propose that we have BDFL rule on this issue. It seems
that most if not all of the arguments have been put on the table. If
the decision is yes, let's include some kind of truncate tag, then we
can continue on these discussions about the finer details. If the
decision is not to include a truncate tag, then we won't have wasted
any time arguing about a moot point.

Thanks,
Eric Florenzano

[James Bennett]

On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche <ady...@gmail.com> 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
composed and decomposed characters.

For example, 'ü' can be represented as either:

1. 00fc (LATIN SMALL LETTER U WITH DIARESIS), or

2. 0075 (LATIN SMALL LETTER U) *followed by* 0308 (COMBINING DIARESIS)

Option 1 is composed, option 2 is decomposed and is actually *two
Unicode characters*, not "two bytes", and so character-based slicing
will chop off the combining diaresis. The only way to avoid this is to
have the filter do Unicode normalization to composed characters (e.g.,
normalization form NFC or NFKC).

[Jerome Leclanche]

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

[Russell Keith-Magee]

On Thu, Dec 31, 2009 at 12:54 AM, Jerome Leclanche <ady...@gmail.com> wrote:

> On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee
> <freakb...@gmail.com> 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
>> particularly want to encourage.
>

> Please...
> Please, please, please, do NEVER assume the use cases on your own websites
> are the only ones other users will ever need.

Quoting:

"""
However, even with this modification - what's the use case for an N
character truncation?
"""

> Are you going to truncatewords on long filenames?
> What about on hashes? On Email addresses?
> Here is where I use
> truncate: http://db.mmo-champion.com/i/35191/schematic-wonderheal-xt68-shades/
> - bottom of the right box. I can't truncate such small names based on words
> alone.

Fine. Those are some use cases. I'm not sure I agree that tail
truncation is the right solution for all of them, but that's a
different battle.

>> As for why this patch has languished for so long - one major reason is
>> that nobody has made an issue of it previously. By my count, this
>> thread is only the third time that someone has made the case for a
>> built-in truncate filter
> Oh NO you don't. PLEASE. grep your irc logs for truncate+filter, I know
> you've been on irc long enough.

I would ask you to please consider the following:

* I made no reference to IRC in my comments.

* Some people (including myself) don't keep historical logs of IRC
chats, due to the ephemeral nature of IRC conversations.

* I don't recall anybody mentioning the truncate filter on django-dev
while I was in the room *and* participating in the conversation.

* If someone did mention truncate in IRC while I was present, they
didn't leave a lasting impression.

* The Django core team has *never* used IRC as communication channel
of record. There is an official django-dev IRC room, but we don't use
it to make announcements or to archive design decisions. If we make an
important decision on IRC, it is usually backed up by a message on the
django-dev mailing list summarizing and archiving the decision.

I would then reiterate my original comment. In the archive of record -
the django-dev mailing list - there are *exactly* three mentions of
truncate. A truncate filter *wasn't* suggested for inclusion in the
1.2 feature list.

I don't deny that people want this feature. However, those people
haven't gone out of their way to draw attention to their pony until
this thread. The original question was "why has this ticket
languished?" The simple reason is that the issue hasn't been raised
seriously by those that want it.

Yours,
Russ Magee %-)

[Jerome Leclanche]

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, IRC is a pretty safe bet to go to to solve first-hand problems.

It's the most common of these first-hand problems application developers should make easier to tackle/understand/deal with in order to make the application as awesome as possible and the user experience as smooth as possible. I'm pretty sure that's what all of us in this thread want.

J

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
J. Leclanche / Adys