Cannot access $delete or $history pages for (un)"translated" article

[jmswisher]

Summary The French version of Invoke getters from autocomplete gives a 404 error for its $history and $delete options.

Steps To Reproduce (STR) How can we reproduce the problem?

1. Go to https://wiki.developer.mozilla.org/fr/docs/Tools/Web_Console/Invoke_getters_from_autocomplete
2. In the Advanced menu, click "Historique" (History). Then go back.
3. In the Advanced menu, click "Supprimer cet article" (Delete).

Actual behavior What actually happened? The history and delete pages give 404 errors.

Expected behavior What did you expect to happen? Get the standard History and Delete pages for this article.

Additional context Is there anything else we should know? The English version of the article does exist.

[peterbe]

Being able to delete content (when the parent is already deleted) is important to get rid of content that is potentially severely out-of-date. For example, we now have a list of documents that were never translated and being able to delete them will require this issue to be addressed.

Also, we (I coded, Ryan reviewed) did something similar to the $edit endpoint. So now might be a good time to tackle this one too. It wasn't particularly hard because the change is entirely without a UI.

[peterbe]

Actually, the problem is more weird. That page doesn't exist! I.e.

>>> Document.all_objects.filter(locale='fr', slug='Tools/Web_Console/Invoke_getters_from_autocomplete').count()
0

(on Prod)

If you try to view it, what actually happens is that somewhere in Kuma it realizes "This doesn't exist in locale=fr, but it does exist in en-US and it's better to show something in English than nothing at all."

So the problem isn't really with the $delete or $history at all. Those are probably fine.

What I think is that the page shouldn't 200 OK at all. It should have 404'd. We can't apply that logic to the read-only site because it would be too intrusive to change something so fundamental. But the wiki is a writers-tool and we can afford to be a bit more blunt there.

My suggestion is; Find the code that falls back on en-US and expand that a bit so that if the site is the Wiki it doesn't fall back at all. Who's with me?

[peterbe]

@escattone @SphinxKnight @chrisdavidmills @jmswisher @wbamberg @Elchi3 @a2sheppy Feedback please. (You can start immediately with my latest comment above). It would probably be an easy fix (yeah right Kuma!) and it would remove a lot of potential confusion.

[SphinxKnight]

Adding to @jmswisher's case: seen on that other page

Feedbacking: I agree those pages should 404 in the first place.

[peterbe]

Feedbacking: I agree those pages should 404 in the first place.

I couldn't agree more. But it's dangerous to act unless you fully understand the history of why the site uses a fallback. It could be deeply related to linking. EIther way, the effort to academically revive the history/justifications, plus actually doing the work might just not be worth it.