case insensitive tags

[GoogleCodeExporter]

I think it would be good to have the option of having case insensitive
tags.  E.g., convert all tags to lowercase before storing, so that
"Something" and "something" would show as the same tag, which they are.  

I understand there might be cases where you would want them to be
different, but for my apps I want them to be treated as the same tag, so
users don't get confused.  

Original issue reported on code.google.com by s3x...@gmail.com on 14 Jun 2007 at 12:03

[GoogleCodeExporter]

It should be stored as case sensitive to be correct with the language. An own 
name is
written in capital letters like the acronyms.

Correct use: 'France', 'RFC', 'RSS', 'Joan Francis'

After, to know if you have already a tag you would turning it to lowercase to 
compare
both.

Original comment by jonas....@googlemail.com on 18 Jun 2007 at 8:01

[GoogleCodeExporter]

s3x3y1, you can already control this behaviour.

Save the unfiltered user input with :
tag_list = models.CharField(maxlength=255)

And have a set_tags property that does the lowercasing.

Take a look at this example:
http://code.google.com/p/django-tagging/issues/detail?id=43&can=2&q=#c6

There is a mistake with the super(Subject, self).save() that should be 
super(MyModel,
self).save()

The caveat is that your tag clouds will be formated with the filters you have 
applied
on the tags ( lowercase ).

Original comment by samuel.a...@gmail.com on 18 Jun 2007 at 8:49

[GoogleCodeExporter]

I wanted something like this too, where the first time a tag was entered it 
would
keep that case, but then any similar tag (same but different cased) would 
reference
the original. I wrote up a snippet on how I achieved it:

http://www.djangosnippets.org/snippets/305/

Something like this might be nice, either as an option or by default...

Original comment by sciyoshi on 9 Jul 2007 at 6:03

[GoogleCodeExporter]

Tags should (optionally) be stored case-sensitive, but lookup should be case
insensitive for most cases. Perhaps this might go into django-tagging, but let 
the
user choose (settings)?

In my own tagging-application, which I used before knowing django-tagging, I did
chosse a quite different approach. All tags habe two fields (name and slug), 
the slug
is created out of the name using some (could be user-defined) filter on tag 
creation.
The slug is used when receiving tags from the database (and insite URLs), the 
name is
only for displaying the tag and can be changed in the admin.

This way I am able to store complex tags like tags containing special chars or
something like german umlauts. When making the filter replaceable (using 
settings)
the tagging-application might become even more flexible.

Original comment by david.da...@gmail.com on 24 Jul 2008 at 9:25

[GoogleCodeExporter]

I'd like to second David's suggestion of storing tag names case sensitized but 
searching either with a case 
insensitive search or else using a common conversion format and searching based 
on slugs.  Enforcing lowercase 
tags on the user is not something I'm willing to do (kind of defeats the "do it 
your way" flexibility of tagging), but 
I equally don't want to have "France" and "france" return two different result 
sets.

Original comment by georgeth...@gmail.com on 8 Feb 2009 at 5:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Clonning a twitter in GAE and would like thedb Objects store user nicknames in 
a case
insensitive manner.

Original comment by joseTo...@gmail.com on 1 May 2009 at 7:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think comment #3 by sciyoshi is a good idea. Would be nice if i doesn't get 
anymore
"Duplicate entry"-IntegrityError

Original comment by google-c...@jensdiemer.de on 10 Sep 2009 at 1:53

[GoogleCodeExporter]

Original comment by bros...@gmail.com on 22 Jan 2010 at 9:51

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Agree with 4 - I would also like to do case-sensitive storage/display but allow
retrieval to be case-sensitive or case-insensitive (code selectable, e.g. on the
with_any() call, plus global default)

Original comment by malcolm....@gmail.com on 6 May 2010 at 9:25