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