I think it would be nice to be able to enforce absolute string length
limits.
It could be an interesting feature for translation tools to provide length
guidelines to translators in a more prominent way (e.g., indicate than the
translation is longer than expected as a warning, and provide shorter
alternatives to translate in such cases), but enforcing strict limits will
lead to some messages not translated at all (e.g., I cannot translate "lift"
to Spanish in less characters than those required for "ascensor" no matter
how hard I try).
On Thu, Nov 28, 2013 at 10:35 AM, Pau Giner <pginer(a)wikimedia.org> wrote:
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:
Make lists expandable if all elements do not fit where expected, add
dynamically an option to access the rest. I made a quick modification of the
mockup as an example. Note that this (a) keeps the design the same as the
original when there is room for it, and (b) also allows for other kinds of
growth such as more items being added later to the menu.
Make font size smaller if text exceeds a certain length. You should make
sure that the smaller font size is legible, and that similar elements do not
appear next to each other with different font sizes (e.g., in the case of
the list you should apply the font size reduction to all the elements of the
list or none based on total length). Similarly, other layout parameters
(margin/padding...) can be adjusted.
Crop long texts. Showing part of the text with an ellipsis at the end may
be enough in some cases. This is the most risky approach since you are never
sure on how much of the words you are missing and, although sporadically
acceptable, nobody likes to see ellipsis everywhere. So that should probably
be the last attempt once you tried to make the most room for text to grow.
Pau
On Wed, Nov 27, 2013 at 8:53 PM, Jon Robson <jrobson(a)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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/design
--
Pau Giner
Interaction Designer
Wikimedia Foundation
--
Pau Giner
Interaction Designer
Wikimedia Foundation
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org