2016-04-04 16:00 GMT+03:00 Subramanya Sastry <ssas...@wikimedia.org>: > Niklas and the language team: thanks for your efforts in enabling > translation features. They are truly important and necessary.
And I want to thank you for your positive and constructive approach for solving this issue. > 1. Given the success of CX, and the increasing use of VE, is explicit > wikitext markup still necessary for enabling translation? I am actually eager to try out non mark-up approach for Translate's page translation feature. I am not aware of any fundamental reason for not being able to work without additional wikitext mark-up. But I would like to clarify some things about the relation of Translate (specifically its page translation feature) and Content Translation (CX). The use case for CX is very different from Translate's page translation. Former supports one-time "free form" translation from one language to one language. The latter supports maintaining content-preserving translations from one language to hundreds of languages so that translations can be kept in sync when the source text changes. Along the same line the occasional suggestions about replacing either extension with the other one is not practical. My opinion is that the way to bring these closer together is to take the best parts of both (and also others like VE) and combine them to produce tools which are tailored for each use case and which are consistent in appearance and functionality. Translate does so much more that it is easier to add a new translation interface to Translate than it is to re-implement all the backend tracking functionality in CX. > 2. Identifying document fragments for translation is another instance of the > same problem of associating metadata with document fragments *across edits*. > Citations, content-translation, comments-as-documentation, authorship > information, maintaining-association-between-translated-fragments, etc. are > all different instances of this problem. Translate extension seems to be > using comments in wikitext markup as one way to maintain this > cross-edit-association. Maybe there is value in thinking about this problem > broadly. Definitely. As we have discussed earlier, the definition of what is a "breaking change" does vary between the different use cases, and in fact is left to a humans (translation admins) to decide in the page translation feature. But the other approach of each tool implementing it from scratch is not ideal either. One thing to remember here is that there are two goals with the current mark-up. The association of content across edits is only one of them (these are the T-comment you refer to). The other goal is to specify what is and what is not translatable. For example, one frequent use case is to mark for translation only the image captions but not rest of the image wikitext mark-up. I am hopeful that some heuristics with additional tools for manual correction would reach good results for this goal. Yet another thing related to this is that we will want to support WYSIWYG/HTML translation in Translate. As you might know already, Special:Translate has two modes: the list view and the page view. Page view should be replaced with interface not much unlike CX, but we also need some support for the list view. > 3. Are there incremental steps we can take to start deprecating the existing > <translate> extension solution and move towards some structural metadata > solution? Given that translate extension is not used on *all wikis*, looking > at the wikis where translation is enabled, is there a possibility of making > this a VE-only / CX-only feature? CX, for example, is already doing work to > maintain association between translated fragments across document edits. What to do with the translate tags is a delicate question and whether to stop supporting them altogether is a question that has lots of dependencies such as how long there will exist third party wikis (where Translate is also used a lot) that prefer to use wikitext instead of VE and parsoid or alternatives. See also my thoughts to your first question. Right now my answer is no: we cannot make this implementation of the feature VE or CX only. My preference is to start developing a parallel mark-up-less system and to provide migration tools. This new system can depend on VE and parsoid and other modern functionality. Its implementation will require cross team planning and collaboration. -Niklas _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
