How to avoid to have duplicate tags due to case sensitivity?

[alexisju]

Wordpress avoids that problem decomposing tags into 2 entities : tag name (case sensitive) + tag slug (insensitive). When you add tags to an article, you can do it considering the case or not, but you won't create duplicate tags.

Scoop.it, i guess, uses something like that. Tags are case sensitive but, you cannot use another formating of an existing tag. Autocompletion only suggests the existing form. User should choose the wanted formating of his tags only once (or use a tool to rename/reformat tag).

This can seem a bit futile but, using everyday shaarli since years - 12 years of shared links (from delicious to shaarli) - , I could make this observation :
https://liens.effingo.be/?do=tagcloud

[nodiscc]

Several possible solutions:

• make tag search case-insensitive (so searching for europe and EUrope would return the same results). This might break tagging for some users that actually use casing to separate tags. You'd still have multiple cases in the tag list. Not perfect but maybe this is ok.
• Leave it as is. I'm ok with this.
• Convert tags to lowercase on save. I don't know. Maybe this is ok, but it doesn't work if the next point is not added, as users will not be able to fix their tags.
• Leave it as is, and add a new button in ?do=changetag: Make all tags lowercase. Well it would make all existing tags lowercase. I think this is the best solution.

[alexisju]

• Or Leave as is and create a tool to merge similar tags, in addition to the renaming tool.

[nodiscc]

This might be the best solution. What would the rules be? What are "similar" tags?

[alexisju]

Similar = same tag regardless of the case ?

[nodiscc]

So sometag and SomeTag would merge to sometag?

[alexisju]

I imagine rather a tool that detects potential duplicates, then the user could be able to choose or not to rename this tags bundle.

But, at the same time, to prevent the creation of these duplicates (or similar tags), autocompletion would require looking for existing tags regardless of the case.

[nodiscc]

I imagine rather a tool that detects potential duplicates, then the user could be able to choose or not to rename this tags bundle.

Not very KISS.

to prevent the creation of these duplicates (or similar tags), autocompletion would require looking for existing tags regardless of the case.

Yes, related to the future change to awesomplete in #49

[nodiscc]

Closing this. If you have tags with iMProPeR casing, find an easy to remember/respect convention like everythinglowercase. @alexisju you have a lot of tags, I suggest you rename SomeThingComplicated using the tag renaming tool to somethingcomplicated, or find another system using - or _ and stick to it. Tricks involving casing will confuse you anyway.

You have more than 3500 (!) tags. Don't use casing. Group your tags under broader terms.

[alexisju]

Maybe i have a lot of tags because i have a lot of links since many years? 12 years of shared links...

But thank you for your advice :-)

However I opened this issue not for my case but to help to make shaarli better through constructive and realistic suggestions.

Why did you close this issue? Only because i have a lot of tags? (seriously?)

Please, don't close to quickly issues and discussions on this community repo of shaarli.
At least, let other people take part to the discussion.

[nodiscc]

I closed this issue because I thought we concluded. No harm meant and I think you did a great job in keeping your link sharing active this long. This issue was about technical points, everyone is free to discuss management tricks and usability problems in the General discussion thread, even en français. That's what the thread is for.

The general guideline of the fork is to keep Shaarli simple (project and code maintenance, and features-wise), while providing customization capabilities (plugin system, making more settings configurable). We'll try to keep the number of open issues low so that we can keep focus. Issues can be reopened if there's a clear direction about particular ones. Of course anyone can send patches/pull requests, even incomplete and they'll be discussed.

This discussion would better fit in #44 so that we don't follow a slope where users and contributors have to track 90 "maybe" items. Separate issues about clear, separate steps can be opened after discussion.

We will also work on a directory structure that makes it easier to add third party templates. This is an important item and work has been started in #76 and https://github.com/shaarli/templates

So, regarding enhancements discussed here:

• someone could add a button in the tools menu to convert all tags to lowercase (open an issue?)
• a command-line tool to do more advanced operations on tags is also possible (fix typos?) but is a separate project, and we don't have clear steps to follow yet.
• We can't force all tags to be lowercase, because you and I agree that casing is part of the meaning of the tag.
• No automated system can do the job of thinking about tag organization. Keep it simple to spare your nerves :)
  • You having 3000+ tags is not a problem, it actually shows that managing this much is difficult, because it's mentally very taxing, even more if you take care of casing.
  • I frequently trim down and merge my tags (I only have ~200 for 2700 links, <1/10 ratio) as I can't seem to remember if I should tag something elec or électronique, something orchestra or acoustic. You have ~3000 tags for ~6000 links (1/2 ratio) which I understand is hard to manage.
  • I try to avoid éàè accents, casing and plurals because it can get confusing really quick.
  • Typos happen, and the tag renaming tool does a good job at triaging tags. Unless someone can come up with a better idea/implementation.
  • These tricks can be added to the wiki. It's world-writable (preferably in a separate page, and link it from the main page).
• The future tag suggestion library is case insensitive so that helps. This has been noted in the relevant bug report.

I can copy this to the general discussion if you want to continue it? (It's not the first time we close an unfinished discussion thread).

Maybe it'd help if we created a file with contribution guidelines about issue management, pull request/code review, etc. for the project.