> > 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 <[email protected]> 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<http://i.imgur.com/GQLeMkq.png>. > 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 <[email protected]> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/design >> > > > > -- > Pau Giner > Interaction Designer > Wikimedia Foundation > -- Pau Giner Interaction Designer Wikimedia Foundation
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
