On Mon, Apr 4, 2016 at 5:21 PM, Niklas Laxström niklas.laxstrom@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.
- 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.
- 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