What problem would this feature solve? ====================================== When moving a page the translated pages are not automatically moved. This is the right thing - translated pages can include translated slugs. However, when moving a topic page, contributors can start translating pages at the new slugs, causing issues when moving translated topics, and making that process take much longer. Who has this problem? ===================== Staff contributors to MDN How do you know that the users identified above have this problem? ================================================================== We had many problems moving the translations of /Firefox_OS to /B2G_OS (bug 1279908). This was doubly confused by Zones, but it would have been a 1-2 hour task in May 2016, and was a 2-3 day task in July 2016, due to translations of the moved English pages How are the users identified above solving this problem now? ============================================================ 1) Diagnosing the issue from the "page move failed" email and multiple stacetraces 2) Manually moving translations back to the old name, then moving the whole topic 3) Running the page move outside of the web form, so that a partial page move will be executed, fixing collisions, and then resuming page moves Do you have any suggestions for solving the problem? Please explain in detail. ============================================================================== After moving a page, perhaps in the "page move successful" email, link to any translations of the original page and suggest moving them as well. Is there anything else we should know? ======================================

summary of discussion: Moving pages is a fairly common activity that includes archiving articles, so it makes sense to spend some development time on this. We'll go with adding this information to the email confirmation as John suggested in comment #0

safwan asked for some steps to reproduce this locally: 1) Create https://developer-local.allizom.org/en-US/docs/MoveTest 2) Create https://developer-local.allizom.org/en-US/docs/MoveTest/Page1 3) On https://developer-local.allizom.org/en-US/docs/MoveTest, create the French translation 4) On https://developer-local.allizom.org/en-US/docs/MoveTest/Page1, create the French translation 5) On https://developer-local.allizom.org/en-US/docs/MoveTest, select "Move this Article" 6) Select "MoveTestNew" for the new slug. It tells you that an additional subpage will also be moved. Select "Move 1 Page" 7) It says "Page Move Scheduled", and that it will email you on completion. 8) In /tmp/kuma-messages, a test email is created that says: ---- Page move completed. The move requested for the document with slug MoveTest in locale en-US, and all its children, has been completed. You can now view this document at its new location: https://developer.mozilla.org/en-US/docs/MoveTestNew. ---- This is the email that may mention that there are other pages that should be moved: https://developer-local.allizom.org/fr/docs/MoveTest However, this last step #8 is not working in my development VM. There is no email created, and the page is not moved by the async task.

So until bug 1301867 has been fixed, If anypne want to reproduce this issue in local development environment, they need to add "CELERY_ALWAYS_EAGER = False" in the .env file.

PR: https://github.com/mozilla/kuma/pull/3967

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/7022c0491ca3d0c8ac3b619ea840d7d7dc4f8e64 [Bug 1292624] Suggest moving translated pages also https://github.com/mozilla/kuma/commit/576621e5ada83ca506ed082420fc14f8ff896d1d Merge pull request #3967 from safwanrahman/move_page [Bug 1292624] Suggest moving translated pages after moving an English page

Fix tested in staging, pushed to stage and master. Thanks safwan!