Also, if for some reasons two tags have the same slug, then posts are missing too...

I'm wondering if this issue is with Archives or with Jekyll (since the Archives code simply iterates over the tags and gets the posts for each). Can you check the size/contents of site.tags["test-tag"]?

Can you check the size/contents of site.tags["test-tag"]?

It would be 1, of-cource. I think the issue is particularly with Archives, as it uses a slugged file name to generate an archive.

But, probably it needs to be fixed in jekyll itself.

As intermediate solution I'd propose to add a number suffix to the slug so the archives would not be missed. This would also address jekyll/jekyll#2965

I think most of the issues causing this originate from Jekyll itself; it would probably better to move this conversation to the main repo (it would get some more exposure as well), but I'll keep this issue open until the problem's resolved.

I don't like the idea of adding a number suffix, since that complicates the slug readability in the end. It is a solution, though, so we can discuss it further.

So, infact we have 2 problems here which lead to the loss of entires on archive page:

1. Tags/Categories with different cases
2. Tags/Categories with the same slug

I'll investigate further into the first problem (it should be a problem with Jekyll though). Can you give an example of the second problem?

it should be a problem with Jekyll though

They put 3.0 milestone on it.

Can you give an example of the second problem?

Basically it is the problem with non-latin alphabets (can I call them alphabets?) where all non-latin letters are stripped from the slug. So for different words it will generate the same slug (empty almost every time).

So in that case issue 2 would be jekyll/jekyll#2965, no? I'm just trying to check if there's anything specific to Archives that is causing these issues.

Yes, these are jekyll/jekyll#2965 and jekyll/jekyll#2977

I actually think it's a problem with how the tag and cat hashes are accessed, see my comment here: #43 (comment)

Hmm, my position on this is still: are tags supposed to be insensitive or not? If they are case-insensitive, we shouldn't be merging them; if they are case-sensitive, something should be done with Utils.slugify in the main repo.

The current method of generating tags creates merge conflicts in tag hashes. Post arrays are over-written and dropped as a result of the merge conflicts, and this causes the missing pages in the post archives. I give an explanation in #43 (comment). This problem is not limited to casing only, it also occurs when tags have dashes, as demonstrated by 18F/18f.gsa.gov#1947 and #82.

So regardless of tag casing, the merge-conflict problem needs to be fixed so that arrays are not dropped and tag archives are generated properly.

My opinion is that tags should default to insensitive, while supporting a way for blog author to set custom casing for specific tag archive pages. I demonstrate my approach in #43 (comment) however there is probably a better way to handle this.

I just realized that a part of my previous comment didn't make any sense. 😛
I meant to say, if tags are case insensitive, we do need to merge them, as you suggested.

In #82, I suggested as the case-insensitive solution, to slug the tags and merge them that way; this would fix both this issue (it would convert all tags to lowercase), and the dashes one. It would also guarantee there would no longer be any URL conflicts (since we use the same slugify to generate the URL).