<rant>Gah, replying inline in the new GMail is hard to begin with, and harder yet when the UI is RTL.</rant>
2013/11/27 Jon Robson jrobson@wikimedia.org
I had two topics I wanted us to discuss and agree upon that are causing lots of friction in mobile development and I would like us to resolve in current designs and future designs. (Feel free to forward to other mailing lists)
Articles Vs Pages Vs <insert word here> #################################### Recently all instances of the word 'article(s)' was switched with 'content pages' / 'pages'. This problem keeps recurring in our design and is starting to become a nuisance. I see both sides here - 3rd parties and even our own projects use our software in a different way
- sometimes pages are articles, sometimes they are definitions,
sometimes destinations etc etc.
However the word 'content page' and page is extremely ambiguous and can be confusing.
"Content page" sucks in general. It's technical to the point of being useless. Wikipedias change it locally for good reasons.
to a reader the word 'articles' is arguably more understandable than 'content pages'. I would actually like us to continue using 'articles' but explore ways other instances can customise this - e.g. switch the word 'articles' to other words based on what their project is about. It would be nice for wikibooks to use the word 'books' for instance, and wikitionary 'words' or 'definitions'. Is this feasible and worth exploring? I feel like using the word pages at the benefit of generalisation seriously damages the benefit of clear and easy to understand language.
The general idea is great, and would be good for MediaWiki core, too.
The problem is that many, many languages have morphologies which are more complicated than what English has - the word "article" may change in many different ways, and if you haven't guessed already, the words "page" and "definition" may change in many *other* different ways. Because of this turning such a thing into a parameter is quite challenging.
Though challenging, it's not impossible and it's worth trying carefully, on a small scale at first. And be prepared to requests from translators to add more flexibility to these parameters, to add grammar rules, etc. MediaWiki's i18n system can do such things a bit, but it has its limits.
In the worst case it may prove too complicated to be worth the effort, and then we can just revert to the generic "page".
Limiting word length in mobile #####################
In addition to this the patch in question brought up a second topic: word length on mobile. On the watchlist view we have several tabs as illustrated in this question which are optimised for single words (and potentially can be truncated using the ellipsis method if necessary) http://imgur.com/Jiv0XPJ
As you can see in the diagram - 2 words do not work very well in this kind of view. I suggested a qqq constraint to limit translations to single words - https://gerrit.wikimedia.org/r/#/c/97935/ - do we think these sorts of constraints are okay for mobile? Another approach to do a similar design would be to use icons, but icons in themselves have even greater problems for translation.
Of course, the ideal thing is to make screen elements work with any string length. By all means, please do strive to make it so.
That said, we don't live in such an ideal world. Even some of our own tools sometimes have "strings-that-should-be-short". If there's really no choice and a translation must be short, writing a suggestion about this in qqq that is the bare minimum. A nice thing to do would be to have an automatic test somewhere to check the string length of all the translations of strings that are marked as such.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore