Limiting word length in mobile

 Regarding this issue, I can think of two strategies. There is not a 100% solution for all cases, but I think the number of problems of this kind will be reduced by:

Ask translators to make short translations

In message documentation, you can provide instructions to translators on how to deal with the translation if it is long. For example, in the translation for "other relevant articles" you could indicate:

Keep it short. If the translated text exceeds twice the length of the source string, it is preferred that you just provide a translation for "other pages" or just "other" instead of the full sentence.

Indicating what is "a long sentence" is complex since many languages do not have a notion of character or word. That's why I used the source text as a reference of length.

Sometimes this is just not possible. Below is an example of the menu words in english and Malayalam using in both cases just single words (and even then you need about an extra 25% room for Malayalam):
all - page - talk - other
എല്ലാം - താൾ - സംവാദം - മറ്റുള്ളവ


Prepare the design for growth

In addition to ask for strings to be short, we can also prepare our designs to accommodate longer text. Here are some ideas:
Pau



On Wed, Nov 27, 2013 at 8:53 PM, Jon Robson <jrobson@wikimedia.org> wrote:
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.

One good example is the watchlist view on mobile - it provides the
ability to filter feeds by namespace:

This i18n change changed the word 'article' to 'content pages'. In
this context it makes no sense. Programmatically what it actually
means is show me only pages from the 'Main namespace' but 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.

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.

_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design



--
Pau Giner
Interaction Designer
Wikimedia Foundation