Wiki url paths should be case-insensitive

[Joehuu]

https://opentabletdriver.net/Wiki/FAQ/MacOS and https://opentabletdriver.net/Wiki/FAQ/macOS

The correct casing of macOS 404s. Should be corrected, but making paths case-insensitive and redirect to the desired casing has to happen too (to prevent the first link from not working). Wikipedia and the osu! wiki does case-insensitive.

Noticed that on lazer, there was no faq listed on macOS because it was outdated. I wanted to update it, but had to resort to this:

$@"https://opentabletdriver.net/Wiki/FAQ/{(RuntimeInfo.OS == RuntimeInfo.Platform.macOS ? @"MacOS" : RuntimeInfo.OS)}"

because RuntimeInfo.OS returns macOS.

[gonX]

I think this is a limitation of GitHub pages. We could workaround this by duplicating filenames to some desired paths (e.g. MacOS -> macOS) but I can also foresee this becoming cumbersome to keep up.

[InfinityGhost]

I think this is a limitation of GitHub pages. We could workaround this by duplicating filenames to some desired paths (e.g. MacOS -> macOS) but I can also foresee this becoming cumbersome to keep up.

It can be symlinked as git does support symbolic links

[gonX]

I think this is a limitation of GitHub pages. We could workaround this by duplicating filenames to some desired paths (e.g. MacOS -> macOS) but I can also foresee this becoming cumbersome to keep up.

It can be symlinked as git does support symbolic links

Yes, but duplicating content across pages generally (or at least used to) wreck SEO. If this is to be implemented it should preferably be via redirects, to the specific page casing that we want people to see.

We do have the option of redirecting the user with Javascript (since a 404 page on Github Pages keeps the invalid URL in the address instead of redirecting to a 404 page), but this would require us to keep track of valid filenames and using more client side code, as well as a compile-time list of valid URLs that can be inserted into the client side code. This is because our paths are not consistently lowercased, and as such we cannot determine the correct casing magically.

With that being said, we could probably transition to all-lowercase URLs and then let the 404 page redirect on the client-side.

Other solutions include the official jekyll/jekyll-direct-from plugin which uses a META-REFRESH meta tag in the HTML header, which doesn't depend on JS.

So, in short, we have the following options:

• Duplicating with symbolic links
  • Pros:
    • Simple
  • Cons:
    • "Duplicates" content in the sense that search engines cannot differentiate between 2 of the same page
    • Forces us to always support any casing that has ever been used
    • Clutters the repository
• Client side Javascript redirect on e.g. 404 page
  • Pros:
    • Guaranteed result
    • Once set up, should never need modification (other than eventual maintenance)
  • Cons:
    • It's a JavaScript redirect
    • Likely needs custom Jekyll plugin to get casing correct, unless the lowercase solution from below is used
• Lowercase everything in addition to client side redirect on 404 page
  • Pros:
    • Same pros as "Client side Javascript" above, as well as:
    • Always predictable URL's
  • Cons:
    • It's a JavaScript redirect
    • Breaks all existing links into the least ideal client-side redirect
• jekyll-direct-from plugin
  • Pros:
    • Uses META-REFRESH tag, which is loved in SEO
    • Easy to set up
  • Cons:
    • Adds another plugin
    • Must specify redirects "manually"
    • Possibly surprising results (e.g. why doesn't this link work - because an unexpected file stole the path)

If you ask me, the perfect solution would be to have a server-side redirect and then just go with lowercase on everything, but we don't have that luxury at the moment.