1. Technical review of the idea

I thought of a new process for marking pages for translation which would work in a “reverse” way as current one. I would like you review this idea to validate, edit this task steps, or decline it.

Overview

Instead of adding Translate tags and markers to the source page, the source page content would be duplicated to a “Marked-page” which would get Translate tags and markers.

When a translation admin would use Special:PageTranslation?action=mark, Translate would parse the Marked-page:

• If the rendering (removing <translate> tags) gives a content equals to source page, then units could be created.
• Else, Translate would warn there are some differences which must be balanced.

Benefits

• Source pages will be much clean. (workaround for T131516)
• Source pages will be fully editable by VisualEditor. (workaround for T261181)
• There are no more need to keep a light Translate markup syntax:
  • <translate>== Heading ==</translate> will be possible.
  • <translate id="<unit ID>" context="inline"> will be possible.
• Extending Translate markup syntax will probably make easier to design tools to automatically prepare/update translatable pages.

Risks

• Applying a complex patch to Marked-page could be overwhelming, when multiple revisions have brought large changes to the source page.
  • However, since parsing Marked-page would render the pre-patch version, I think we could build a strong MarkUpdates tool (step 4.) which could automatically import all changes from source page to Marked-page.

Quick and dirty first implementation notes

I’m providing a first commit to show how this could be technically feasible. I am using a /qqt subpage as Marked-page. A properer way may be in a separate namespace, with a dedicated content model.

2. Implementation

We need a stronger implementation which make legacy process and this idea to coexist, in order to make it testable without breaking the previous process for translation admins.

I think we should not make the two marking ways exist for a same page, but we should provide a way for a translation admin which prepare/mark a new page for translation to choose between the both ways.

We probably should not allow to migrate pages from legacy system to the new one yet.

3. Volunteering test by translation admins

Some volunteer translation admins will mark pages with the new process for several weeks in a real context (I think about 3 months are needed)

4. Build a strong MarkUpdates tool

I think a good interface design is a side-by-side view, similar to how Netbeans handle diffs:

• Source page is at left side, Marked-page is at right side; both are editable.
• The challenge is: the diff engine should not actually use Marked-page as right side, but parsed-by-Translate Marked-page instead.
• Between changes, an arrow button allow to migrate changes from one side to the other side.
• The goal is that parsing Marked-page by Translate renders a content equals to source page.

5. Remove possibility to use legacy process

So, marking a legacy marked page should automatically create the Marked-page and clean markers from the source page.