Page MenuHomePhabricator

[Epic] Support for Section Translation
Open, HighPublic

Description

Section Translation is intended to support users to expand articles by translating a new section, on desktop and mobile.
Supporting Section translation is a complex task, so this is an Epic ticket to capture the different parts and provide an overview of how are those connected. You can also check SectionTranslation, the design specification document and the Translation Boost page for more details.

Chapter: Core Workflow.png (768×1 px, 59 KB)
Chapter: Translation Editor.png (768×1 px, 78 KB)

Entry points

From the Translation dashboard:

Additional entry points:

Choosing a section

Translation editor

Desktop (adapting ContentTranslation ):

Mobile (CX-mobile) :

Publishing a section and follow-ups

Supporting services and activities

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedPginer-WMF
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedsanthosh
OpenNone
Resolvedsanthosh
Resolvedsanthosh
Resolvedsanthosh
DuplicatePginer-WMF
OpenNone
ResolvedPginer-WMF
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
Resolvedsanthosh
ResolvedBUG REPORTngkountas
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedngkountas

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I read somewhere that this is planned to be essentially a single page application inside a special page which is how Special:ContentTranslation currently works. Coming from the angle of skin architecture this seems problematic to me (for the reasons I detail in T259577#6398541) and I wondered whether you would consider making this a standalone skin as part of this work.

I'm currently in the process of improving the skin architecture as part of desktop improvements so if a skin doesn't make sense I'd be interested in your reasoning against doing that to understand where I can focus my energy best.

I'm also curious from an architecure perspective if static web page has been considered as an option and if not, why.

I read somewhere that this is planned to be essentially a single page application inside a special page which is how Special:ContentTranslation currently works. Coming from the angle of skin architecture this seems problematic to me (for the reasons I detail in T259577#6398541) and I wondered whether you would consider making this a standalone skin as part of this work.

I'm currently in the process of improving the skin architecture as part of desktop improvements so if a skin doesn't make sense I'd be interested in your reasoning against doing that to understand where I can focus my energy best.

I'm also curious from an architecure perspective if static web page has been considered as an option and if not, why.

From the user perspective what we wanted to achieve is to support a more focused activity. Translation requires to access different pieces of information and elements such as the sidebar were getting in the way. You can find similar patterns in e-commerce sites when doing focused activities such as the checkout, for example.

Having said that, it makes perfect sense to work as well as possible with existing systems such as the skin architecture. @santhosh can provide more detail on the technical decisions.

From the user perspective what we wanted to achieve is to support a more focused activity. Translation requires to access different pieces of information and elements such as the sidebar were getting in the way. You can find similar patterns in e-commerce sites when doing focused activities such as the checkout, for example.

You can achieve that even more so with a skin. Building this as a skin would give you complete control over the experience for example the skin would not render the sidebar.

Right now it seems from my uninformed position that you are fighting mediawiki internals by trying to make the special page look like a standalone app but under the surface you have a host of unnecessary technical baggage - as I've pointed out you are shipping a large amount of unused JavaScript and CSS that doesn't even apply to the page yet still executes.

@Jdlrobson Can you please guide us with this approach? I am not familiar with skins system. If we create a new skin, wouldn't it be globally available? Can it be used for just a special page? Can you give some pointers on where to start?

Definitely can help with that. When do you need to know by?

Out of interest is there anything stopping you using a static page like the Wikipedia portal does [1] e.g. requiring access to the mediawiki libraries?

[1] https://www.wikipedia.org/

Definitely can help with that. When do you need to know by?

  1. If we create a skin, won't it be available as preference for users for all pages? I guess, in our case, we don't want to list this skin as a general skin, but an internal one for Special:CX only. How to do that?
  2. Should we write it as a new Skin repository and make dependency for CX?
  3. Is there an example where a special skin is made only for a special page? Is it by conditionally change wgDefaultSkin based on current page name?

Out of interest is there anything stopping you using a static page like the Wikipedia portal does [1] e.g. requiring access to the mediawiki libraries?

Yes, for example, VisualEdior(Mediawiki target) is required for editing translations.

If we create a skin, won't it be available as preference for users for all pages? I guess, in our case, we don't want to list this skin as a general skin, but an internal one for Special:CX only. How to do that?

apioutput and fallback are skins but are hidden in preferences using $wgSkipSkins

Should we write it as a new Skin repository and make dependency for CX?

It's up to you but personally I'd ship it inside the extension.

Is there an example where a special skin is made only for a special page? Is it by conditionally change wgDefaultSkin based on current page name?

Here's some example code which forces timeless skin on a given special page:

	public function execute( $subpage ) {
		$skinFactory = MediaWikiServices::getInstance()->getSkinFactory();
		$output->getContext()->setSkin(
			$skinFactory->makeSkin( 'timeless' )
		);

Here's a demo to play around with: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/ /627382

Thanks @Jdlrobson!. I will try to take it forward.

I have a question, when the Section translation will be avaliable on Wikipedia?

I have a question, when the Section translation will be avaliable on Wikipedia?

Thanks for your interest in the project, @RodneyAraujo

We are early in the project. Right now it is available in the test server. Depending on the issues we find, we'd evaluate how useful and safe it is to release on Wikipedia. Then it will be released onWikipedia for one language, and research will be done to evaluate how it works for users when translating real content. Based on those results, analytics of content created/deleted and community input we'll decide to make it available for more languages. That's the general plan, but there are several decision points that make it hard to predict a specific date.

Giving it a try, and sharing either your excitement about the idea or the issues you find will always be helpful to keep the project moving forward to eventually reach all Wikipedias.

Thanks!

@Pginer-WMF I have a question: When it's ready the support of Section translation on desktop? Thanks.

@Pginer-WMF I have a question: When it's ready the support of Section translation on desktop? Thanks.

Right now it is hard to tell. There are multiple areas to cover for the tool (entry points, new article creation, desktop support, improving suggestion and mapping algorithms, support for references and other complex contents, etc.) and we'll decide what to focus on first based on the user feedback and research. We just enabled the tool so it is early to predict where in the list will desktop support be.

Having said that, it is useful to hear from users that this is a feature that they consider relevant. Thanks for asking!