987544 - Page Move: allow moves that only differ with capitalization

Status: RESOLVED WORKSFORME

(developer.mozilla.org Graveyard :: Editing, enhancement)

Description

[Jean-Yves Perrier [:teoli]]

What did you do?
================
Tried to move an article to a slug differing only by capitalization.

E.g.
https://developer.mozilla.org/en-US/docs/Web/API/document.lastModified$move

to 
Web/API/Document.lastModified

(Note the capital D

What happened?
==============
Result: 

Your requested move cannot be completed due to slug conflicts:

Please choose a different slug value.


What should have happened?
==========================
1. Slug renamed to the new version
2. No redirect page created

Is there anything else we should know?
======================================
This is a common error of newbies. There is no way in fixing it via the admin panel, AFAIK.

We have around 100 such pages to fix and new ones are created at a rate of 1-2 every month.

Comment 1

[John Karahalis [:openjck]]

Slugs appear to be case-insensitive. Yet it seems that the capitalization that was used first is the "default" that all others redirect to. Maybe someone on the Django side can shine more light on this.

Either way, we may be able to tackle this from another angle. I don't think page move itself is the issue.

Comment 2

[James Bennett [:ubernostrum]]

I think page move should not try to handle this; it would introduce a rather significant special-case handler (since moves to a differently-capitalized slug would have to have their own special conflict-checking logic *and* would have to disable the redirect creation page move normally does).

Do we have an estimate of how often we need to fix capitalization problems? That's going to be the decider (at least for me) on how best to craft a solution for it.

(also, as a bad but temporary workaround, you can move the page to some other completely different slug, then move it back to the correctly-capitalized original, I believe)

Comment 3

[Jean-Yves Perrier [:teoli]]

We probably have about 100 slugs to fix (especially under API) now. Then 1-2 times a year.

I think I will just use the workaround (didn't thought of it), as except for the initial batch, it is a fairly rare event.

Closing this as WORKFORME, I will reopen if the workaround appears not to work well enough.