<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(a)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
