On Sun, Apr 3, 2016 at 10:48 PM, Niklas Laxström <niklas.laxst...@gmail.com> wrote:
> 2016-04-03 11:29 GMT+03:00 Jon Robson <jdlrob...@gmail.com>: > > The Translate tag has always seemed like a hack that I've never quite > > understood. > > I am happy to direct to our documentation [1] anyone who asks, or > explain if the documentation is not sufficient. > > The word hack can have both positive and negative meanings and it is > unclear what do you mean with it here. > FWIW I didn't mean this in a negative way. Hack is always a neutral word in my vocabulary :-). Possibly a more descriptive term would have been "oddity". I've personally had to push changes in MobileFrontend that felt wrong, but were necessary due to the environmental constraints I worked in. (Side note: In return have to put up with insulting comments such as "MobileFrontend is an abonimation" from people that haven't taken the time to understand why things are done the way they are). I've ignored those people and still consider the work I've done as useful and important, just as I value the work everyone has put into our language support. The least I can do is elaborate on my brevity earlier (sent via mobile during hackathon :-)) I think Subbu has covered very well my feelings around this so I don't have much to add to what he's said. My original concern however was not around the documentation, but how we have 2 mechanisms for doing languages - create a separate site or use the translate tag. It wasn't clear to me which predates the other and why that decision was made. The advantage of a separate site is that it is the simplest possible way to translate.. through no effort whatsoever an editor can translate an article on a mobile device for example by navigating to their project and clicking the edit button. On the other hand Special:Translate doesn't work [1] and the current plan is to make it redirect to desktop which is disappointing and I'd guess loses us lots of potential editors (myself included). > > > The translate tag causes lots of issues on mobile (impacting usability > and > > performance) due to not playing well with the rest of the language > > ecosystem. > > I was under the impression that mobile does not work with the wikitext > directly. Translate tags never appear in the parsed wikitext output. > Can you please point me to the tasks in Phabricator where these are > explained? I am especially curious about the part about "rest of the > language ecosystem" because having worked on many parts of it, I don't > feel the same way. > > [1] https://www.mediawiki.org/wiki/Help:Extension:Translate When we experimented with the first versions of the editor, we found that edits significantly increased when we loaded sections rather than the entire article - so less wikitext leads to greater number of edits. The translate tag makes the wikitext more confusing and bloats it when translations exist, but I've not investigated so this would need more investigation. To take a more concrete example of impact on mobile - we've made the mobile skin play nicely with language interwiki links (we've even dedicated this entire quarter to improving language switching on mobile web [2] ). On the other hand, the languages tag does not work the same way as an interwiki link. It does it's own thing which is sadly suffering from usability issues on mobile [3]. The point being that when we don't consolidate systems that do similar things, we are losing opportunities to benefit from things elsewhere or waste engineer time fixing 2 identical problems. The main issues I have are more from an architecture perspective. I would expect a function along the lines of ArticlePage->getLanguages() to exist and be agnostic to where languages come from - translate tag or interwiki link for consumers such as skins and apps. I hope my views on this are a little clearer to you now and apologies for putting you on the defensive if I did. I'd love to see our new language switcher compatible with the output of the translate tag and the translation mechanisms available on mobile phones, so readers can view translations and edit seamlessly around our projects. > > > -Niklas > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > [1] https://phabricator.wikimedia.org/T102922 [2] https://phabricator.wikimedia.org/T121919 [3] https://phabricator.wikimedia.org/T106361 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
