what number
the ticket is.
- Gabriel
On Mar 6, 6:18 am, Jerome Leclanche wrote:
> http://groups.google.com/group/django-developers/browse_thread/thread...http://code.djangoproject.com/ticket/5025
>
> The proper solution would be a truncate filter, unfortunately, the
> ticket is still sittin
http://groups.google.com/group/django-developers/browse_thread/thread/924112bf84709225?pli=1
http://code.djangoproject.com/ticket/5025
The proper solution would be a truncate filter, unfortunately, the
ticket is still sitting on "Design decision needed". (Could someone
PLEASE just tak
suggestions for the docs, they are treated exactly like code:
they're in the repository [1] and are open for patches like any of the code.
Given the frequent requests for a truncate filter, I think that the
requested doc changes would be welcome. Feel free to submit a ticket with a
patch for
Hello,
Truncatewords is in Django, but I've been missing the (for me) more
obvious "truncate"-filter, which truncates to a specified amount of
letters, which is really important to me for formatting purposes.
After some thorough looking on Google, I found out that I didn'
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 discov
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 l
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
> wrote:
> > When truncating
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
composed and decompose
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 ye
t; > 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 the
gle
> 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 le
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 wrote:
> On Wed, D
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 people want this feature. I'd like to kindly
>
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 "+1" stop. The number of p
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. Al
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. With that said the reason
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 w
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 v
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 extrapolate from 1, 10, or
t 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
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, some people want this fea
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-
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
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 percentag
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 boo
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
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
mething 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
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 unsubs
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
> particularly want to encourage.
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 address. I had understo
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 addresses. Not exactly "better",
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
On Wed, Dec 30, 2009 at 8:37 PM, Ian Kelly wrote:
> On Wed, Dec 30, 2009 at 11:21 AM, Jerome Leclanche
> wrote:
> >
> > On Wed, D
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 d
ion 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/
>
; unusual.
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
boundarie
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
Thanks, that's a useful lin
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 {% if %} tag makes that so easy
>> I don't think
ead 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
--
You received this message because you are subscribed to the
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 {% truncate %} tag.
>
> Alex
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
nce 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
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.djangopr
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
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
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 trunc
t;
> > 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.
&
real fix
here
is documenting that slice can be used as a truncate-filter.
-Thomas Adamcik
--
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 uns
> 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 django-develop...@googl
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 wrote:
> O
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 is that the proposed "truncate" would add an e
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 I'm not really convinced
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". The only thing
people se
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 use
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
55 matches
Mail list logo
