Page MenuHomePhorge

Improve current client error 404/403 pages
Open, NormalPublic

Description

Thinking about it, we could do with a better 404 and 403 error page.

Error pages are almost wasted talent, as we don't really want people to see them, but alas, sometimes they do, and they shouldn't be terrible.

This will also need translation in the languages that we can do before a new 403/404 page is deployed since we have a multilingual audience.

Event Timeline

While having this page available in as many languages would be nice, I'm not really sure if it's feasible.

It means we then need to develop a way for the community to provide translations and find a way to manage exporting those back to the error pages. By their nature, they are likely to be flat HTML, and then we have to do lots of funky magic working with languages in headers, which may rely on things we don't have available. Alternatively, we could display English and link off to all the other languages as HTML files/hidden "sections" with JS?

The biggest difficulty in this idea is that users are able to set their language in MediaWiki, but nothing about the HTTP environment carries forward that language setting, so when an HTTP request is made and hits an error page, there's little-to-nothing to go off of in that request to indicate what the target language should be as it isn't querying their MediaWiki user preferences. When I think of ideas for creating a localized error page in a wiki environment, Wikipedia comes to mind with their localization in the subdomain (e.g. en.wikipedia.org, fr.wikipedia.org, etc), where you could theoretically make an nginx if statement that picks up the subdomain and returns a different error_page directive depending on the subdomain. However on ShoutWiki where the domains don't indicate the site language, that doesn't work. Even if you were to query the site's content-language response header before returning a PHP-based error_page, the site's content-language could be different than the user's customized preferences.

That leads me to suggest instead of handing HTTP error pages to the user, to just forward them to a MediaWiki page based on their request_uri, so if somebody tries to hit http://en.brickimedia.org/Testing for example, redirect them to http://en.brickimedia.org/wiki/Testing, which gives them a more user-friendly way of seeing the page was not found (and advises them that they could create the page, leading them to become a wiki contributor if that's something they're trying to do), and also would display in the user's language preference if they're logged in.

lewiscawte triaged this task as Normal priority.Jun 14 2020, 2:36 PM