Page MenuHomePhabricator

Load a single section in Content translation's editor
Open, HighPublic

Description

We want to support expanding existing articles by translating new sections. Although the final designs have not been finalized yet, for the step where users do the actual translation it makes sense to reuse the translation editor that Content translation provides, at least for desktop. This would extend Content translation editor with a mode similar to the "edit section" capabilities that wikitext or Visual editors have.

Currently, Content translation editor loads a complete article. This ticket proposes to extend its capabilities to be able to load a single section instead. For example, based on a url parameter it should be possible to load the History section of the Ukulele article.

Design details

Expanding Content translation editor with a "section" mode requires some considerations:

  • The translation title. For this case both the article title (non-editable) and the section title (editable in the translation) will be shown.
  • Publishing behaviour. Publishing will add the new section to the target article at the end of the document. This will be refined in follow-up tickets (adjusting the action and messaging to the circumstances).
    • Section-translation Content published will include the "section-translation" tag in addition to the usual "content-translation" one.
  • Publish settings. We may need to initially remove the option to customize the target namespace when translating sections.
  • Access through the URL. As a first step, the section mode will be accessible through a URL parameter. Once the overall workflow for section translation is specified, the UI supporting other steps (e.g., letting the user pick a section to translate) will connect to the current step without the need for manually creating a URL.

Apart from the differences noted, the translation workflow should work in the same way it does when a full article is translated.


Since some of the current limitations of the current database schema may apply, it may be good to keep the following tickets in mind:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptTue, Oct 1, 11:54 AM
Pginer-WMF triaged this task as Normal priority.Tue, Oct 1, 11:55 AM
Pginer-WMF updated the task description. (Show Details)Wed, Oct 9, 10:23 AM
Pginer-WMF raised the priority of this task from Normal to High.Wed, Oct 9, 11:56 AM

@Pginer-WMF have you considered allowing users to choose where their published section translations should end up? In your mock ups, there was a way to choose which section to translate from source. Similar to that, we may enable users to choose between which sections in target article to insert newly translated one.

@Pginer-WMF have you considered allowing users to choose where their published section translations should end up? In your mock ups, there was a way to choose which section to translate from source. Similar to that, we may enable users to choose between which sections in target article to insert newly translated one.

Yes, there are some possible approaches I considered:

  • When the user selects the section, a preview is shown for the place where the published contents will be added. We can add an option to change the destination.
  • When publishing we can add an extra step for the user to select the destination.
  • After publishing, we can provide an option to (only requiring additional effort when the default placement is wrong).

My initial thinking is that adding it at the end by default may be enough for the initial version, assuming that the default position (with some considerations such as keeping references section always at the end) will be the intended place often. In other words, it may not be worth it to spend time on a destination placement selector until we observe that it is really needed. Based on user research, we'll explore the different approaches to check which works the best.

Technical implementation related notes:

  1. Even though we want to show only on section in source article to users, in the background we need to full article so that we can resolve inter-content references.
    • Show the full source article and highlight the selected section alone. for target article, either (a) show full existing article (b) just a place holder for the selected section. Option (a) has a problem of aligning target content against source content. Not an easy one to resolve. (May be, it can be solved if the target article is not aligned at all). Pros: Seeing the whole context of source and target will help translators and may be even allow to select where the published section goes.
    • Hide everything except the selected section alone. Cons: Translator miss the context of the article.
  2. Since we need to load the full source article, there is no need for any new api at cxserver.
  3. Publishing API would require changes so that we don't overwrite the existing article with single section.
    • Need to find the section offset to insert the new content - How exactly this can be done? (a) if we load the full target article to UI, we can do this insertion at browser. (b) if we do this at publish api(PHP), we need to fetch the existing target article content there and parse .

Looms mostly OK.

Just a few things:

One:

Publishing will add the new section to the target article at the end of the document. This will be refined in follow-up tickets (adjusting the action and messaging to the circumstances).

Does this mean that there is a plan that in the future there will be a way to publish somewhere other than the end of the article?

Two:
In the current image, the name of the section has the same appearance as the name of the article in the full-article mode. The name of the article is a new element, shown in a small font at the top. I suspect that this may be confusing. It makes more sense to me to show the article name and the section name identically to how they are shown in the full-article mode.

Three:
It's not exactly about this visual design, but generally about section translation: How will section translation actions be counted in CXStats? This feature will need some metrics.

Technical implementation related notes:

Thanks for putting this together, Santhosh.

  1. Even though we want to show only on section in source article to users, in the background we need to full article so that we can resolve inter-content references.

Ok, that seems a safe approach, and I'm ok going in that direction as an initial step. However, I think it would be worth exploring the possibility of actually loading properly the specific section. Mobile Visual Editor recently supported section loading, which may had to deal with similar challenges. Are they loading the whole article behind the scenes? Is there an alternative to load references from other paragraphs?

  • Show the full source article and highlight the selected section alone. for target article, either (a) show full existing article (b) just a place holder for the selected section. Option (a) has a problem of aligning target content against source content. Not an easy one to resolve. (May be, it can be solved if the target article is not aligned at all).

Pros: Seeing the whole context of source and target will help translators and may be even allow to select where the published section goes.

  • Hide everything except the selected section alone. Cons: Translator miss the context of the article.

The purpose of Section translation is to focus on a particular sections. So I'm inclined to hide all the unrelated sections on both the source and the target document from the user. Other steps on the workflow would help to provide context when needed.

I made a quick test on this translation by applying the following CSS to hide translation units before the "History" section:

#cxSourceSection0, #cxTargetSection0,
#cxSourceSection1, #cxTargetSection1,
#cxSourceSection2, #cxTargetSection2,
#cxSourceSection3, #cxTargetSection3,
#cxSourceSection4, #cxTargetSection4
{display:none}

Below you can see that paragraph alignment works (adjusting when the translation becomes longer) and references that are created in other paragraphs (like the last one) seem to be present:

  1. Since we need to load the full source article, there is no need for any new api at cxserver.
  2. Publishing API would require changes so that we don't overwrite the existing article with single section.
    • Need to find the section offset to insert the new content - How exactly this can be done? (a) if we load the full target article to UI, we can do this insertion at browser. (b) if we do this at publish api(PHP), we need to fetch the existing target article content there and parse .

Regarding publishing it would be great to make it resistant to changes that may happen in the article while the user is translating (especially if those happen in other sections the user is not working on).

Loading the target article seems to add unnecessary complexity of processing contents that are not going to be modified. The classic Wikitext editor supports section editing for a long time. So maybe we can check how the process of appending new contents on a particular section is supported.

Another concern about loading too much content: Would this path allow multiple users to translate different sections, and publish them without stepping their toes? That is, a user starts translating the "History" section of the Ukulele article into Tagalog while another user starts translating the "Tunning" section, and both can publish their section in any order without destroying the other's work.

Notes on how does section translation differs from full article translation

  1. A section translation is not equivalent to full article translation in terms of CX Statistics.
  2. A translator cannot say I created this article using CX.
  3. So this concept require differentiating between full translation and section translation in
    • database,
    • apis,
    • corpora relations,
    • statistics - APIs and CXStats page
    • CX dashboard.
  4. When we introduce section translation, more than one translator can works on a sourcearticle-sourcelanguage-targetlanguage-targettitle pair. We will need to rethink and improve our database schema and data access classes to get this correct
  5. While we are at it, it is becoming close to the idea of multiple translators doing full translation on same article at same time(TODO: link ticket for that)

Looms mostly OK.
Just a few things:
One:

Publishing will add the new section to the target article at the end of the document. This will be refined in follow-up tickets (adjusting the action and messaging to the circumstances).

Does this mean that there is a plan that in the future there will be a way to publish somewhere other than the end of the article?

Yes, but there are many possibilities. We need to observe users to learn whether the default placement is right most of the time. Depending on how frequent changing the default position is needed, we can provide a more or less prominent way to change the default. Some possibilities:

  • Users most of the time translate sections in the sequence order they expect. Providing a follow-up option after the section is published to move it, may be enough to correct the few cases where the default is not ideal.
  • Users most of the time need a section to be on a different specific place. Then an additional step to select the destination placement may be convenient.

So for the first iteration, I think it makes sense to start with a basic default.

Two:
In the current image, the name of the section has the same appearance as the name of the article in the full-article mode. The name of the article is a new element, shown in a small font at the top. I suspect that this may be confusing. It makes more sense to me to show the article name and the section name identically to how they are shown in the full-article mode.

Good point. Here I was trying to emphasize the main element the user is working on (the section), keeping the article as a secondary contextual element. However, it is true that this contradicts the usual document hierarchy, and we need to check how much distraction/confusion this may generate. In any case, I think that both pieces of information are needed and adjusting the style in one direction or another does not seem to be a blocker for the technical exploration.

Three:
It's not exactly about this visual design, but generally about section translation: How will section translation actions be counted in CXStats? This feature will need some metrics.

I'd expect section translation to be reflected as an edit with a special tag ("section-translation"). The metrics defined for the current fiscal year (T226171) are defined to allow obtaining the number of articles translated (with the current Content translation workflow), sections translated (with the future section translation workflow), or both.

Note that with this approach the articles translated with the classic Content translation workflow may contain several sections, but those are not counted as independent section translations.

Pginer-WMF updated the task description. (Show Details)Tue, Oct 15, 11:46 AM

This topic was discussed in details and the current undestanding is given below:

  1. The section translation workflow with in CX- from starting to publish will be a minimal CX both in terms of technology and user experience. CX Will have a newly defined mode-we can name it properly, for now "minimal"
  2. Minimal mode will be used for section translation. It will NOT HAVE the following features
    • Auto save or any kind of saving. Start, edit and publish in one go. No entries made to the CX central databse.
    • Category display and actions to add remove
    • No progress calculation
    • No translation progress based validation or abuse filter checks. Hence no error cards at all
    • No namespace selection since the article exist already
  3. CX Dashboard does not show any ongoing section translation or any statistics. No changes there
  4. CX Stats does not show anything about sections translation
  5. Published translation can have an edit tag