On Mon, Apr 4, 2016 at 5:21 PM, Niklas Laxström <niklas.laxst...@gmail.com> wrote:
> 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. > *nod* one big difficulty with doing a CX-like model for documentation pages is in synchronizing updates... I think that in combination with good diff/changeset displays, the CX model can be extended to support updating translations for edited pages when we're translating the way we do documentation: with one master copy, usually English, that has translated 'clones' in other languages. It would likely be much harder to support back-and-forth edits for multilingual pages that aren't required to be kept in sync with a master, as with Wikipedia articles in different languages. It would be a little different from how <translate> blocks work in that when new text is added and hasn't been translated yet, you don't see the updated English text on your localized page. But we can automate a marker that says the English page has been updated and can link you back to it. > > 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. > *nod* with a master->translation model, this is something that can be human-assisted; note that good heuristics in diff detection can already do things like detect moved paragraphs, which should help. > 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. > +1 on all this. :) For marking untranslatable bits, I suspect it may be better to default all text to translatable except where code blocks are explicitly marked. We can perhaps provide a markup like <nowiki> for <notranslate> as well, which should be something that can be integrated in both source and visual editors. > > 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. > +1 -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
