Case sensitivity of individual `tags` entries

[zachleat]

Related docs: https://www.11ty.dev/docs/collections/

Aggregation issue for this!

Specifically, when assigning:

tags:
  - JavaScript

tags:
  - javascript

Right now the above two documents create two separate entries in the collections object. This causes further issues if you have pagination templates with something like: permalink: /{{ alias.tag | slugify }}/

Both slugify and slug filters change the strings to lower case.

• https://github.com/11ty/eleventy/blob/d082ead95ec6d53a4dfffd901941527bb09fcdb5/src/Filters/Slugify.js
• https://github.com/11ty/eleventy/blob/d082ead95ec6d53a4dfffd901941527bb09fcdb5/src/Filters/Slug.js

This will throw a duplicate permalink error!

[zachleat]

My hunch is that it’s obtrusive enough that I think we should slow play this with some kind of configuration API opt-in. Then we can swap the default value of this method with a major release and it will also allow folks to opt-out of the behavior later if they’re relying on it.

[zachleat]

Community discussion:

• Confused about tags with spaces or and capital letters eleventy-base-blog#89 has the additional concern of whitespace in the tags.
• Standardise each tag before creating a collection #2166 (comment) had some really great thoughts
• This discussion Should tags be case sensitive? #1461 has the most comprehensive discussion on it
• Wanted to specifically highlight this comment from @johnridesabike about an onCreateTag normalization callback Should tags be case sensitive? #1461 (comment)

[oliwarner]

Like many people I've hit this problem before. I fixed it by manually extracting tags from all my pages and sorting them to show similar tags, before going back in and letting me set which version I want to keep. It was hard.

The problem with doing this automatically is you won't get the case right for display. You need to preserve the user-input version to preserve quirks like McDonalds, acronyms like NFT or anything else that doesn't lend itself to a title filter.

My preference here is a build time warning that identifies clashes and their documents so users can standardise on the version they want to keep.

[Snapstromegon]

I've hit this one too before.

If I'm not mistaken, this works if you don't use the slugify filter for your links. Nonetheless I have reasons for flatout directly changing the behavior and not doing it.

• Windows does handle paths case insensitive, so on windows the two paths are the same even without slugify.
• An added config option to opt in would ease transition (like you mentioned)

Since all users already have to handle the current behavior, I think it's okay to use the second option to introduce a new API/config for this.

[TigersWay]

Had to face quite some times the same kind of trouble, and French authors with their accents never helped 😄
But I believe we are mixing 2 different troubles:

• "lowercasing" & tags: That's impossible and not a good idea. As said before, "Bush/bush" are not the same tag, "javascript/Javascript" could be but not "JavaScript", and in French "été/ete/summer" are clearly different tags again!
• Slugs now: Here is the real trouble. Even if we wanted we could not keep some of the differences.

I could imagine a slug function, warning when transforming a different input to the same result!

[freshyill]

I don't have a strong opinion as what should be the default, but I've encountered duplicate permalinks. I've mostly made content updates to fix this, since in my case, they were actually the same thing. It would be nice to have the option either way.