Niklas and the language team: thanks for your efforts in enabling
translation features. They are truly important and necessary.
As for the topic of hacks, I feel wikitext's history has been one where
people have stepped in to address critical issues / needs that existed
at the time with whatever resources were available at that time to get
stuff done. They have not necessarily been the most elegant solutions
always. So, I think wikitext's history is one of hacks in the best
possible sense of the term demonstrating resourcefulness to get things
done even while, when looked at from a technical lens, some of those
have also been hacks in the negative sense. I don't think there is
anything controversial saying that.
As a member of the parsing team, I have been interested in making
incremental progress in addressing this technical debt in wikitext
markup. We have been slowly trying to nudge wikitext towards semantics
that are more structural rather than being purely string-based. We have
been making RFC proposals towards this end. Now that Parsoid's utility
has been established, we have energy and mental space freed up to think
beyond the immediate problem of supporting visual editing. I believe we
have a very powerful change-management tool in Parsoid and we should try
to leverage it as such.
Anyway, let us think through what might be good ways of solving this
translation problem. Some high-level questions in that direction:
1. Given the success of CX, and the increasing use of VE, is explicit
wikitext markup still necessary for enabling translation?
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.
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.
Subbu.
On 04/04/2016 07:13 AM, Niklas Laxström wrote:
To Brion and other people who think the page translation markup is
annoying and a usability issue: As the (then volunteer) developer who
created it, I can only agree.
The way page translations currently works, which is extensively
documented at [0], is the result of lots of experimenting with what
works and what does not. When developing this feature, I got some
first hand experience working with the MediaWiki parser, which was not
always easy.
Yes, the wikipage translation feature can and should be improved as
technology progresses: we now have a visual editor which did not exist
when this feature was developed. However, as shown by statistics [1],
these issues do not prevent the feature from being used to translate
thousands of pages, including the weekly tech news. The markup issue
is not a reason to stop using this feature.
For this quarter the Language team is going to address high priority
issues in Translate that can prevent proper use of the page
translation feature [2]. Our team is small and has a huge scope of
work. Only with help of others it is possible to proceed faster and
cover more ground.
To remind us about our visions: we should "make efforts to support the
translation of key documents into multiple languages" [3] and we
should "provide the essential infrastructure for the support and
development of multilingual wiki projects" [4].
I do not wish to spend my time arguing repeatedly for these goals.
Instead I want to work on making them happen. My request is that we
(especially us English speakers and developers) accept some
inconvenience when necessary to support multilingualism. [5]
[0] https://www.mediawiki.org/wiki/Help:Extension:Translate
[1]
https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Reports/2016-March#Usage_data_2
[2] https://phabricator.wikimedia.org/project/profile/1854/
[3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles
[4] https://wikimediafoundation.org/wiki/Mission_statement
[5] Not limited to this thread, see
https://gerrit.wikimedia.org/r/#/c/214893/ and
https://phabricator.wikimedia.org/T39797 for examples which are stuck
for a long time.
-Niklas
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
