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.
On Wed, Nov 27, 2013 at 1:53 PM, Jon Robson jrobson@wikimedia.org wrote:
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.
This is a thorny problem that isn't just relegated to mobile. We've run in to the same on desktop with GettingStarted and so on. See discussions such as https://bugzilla.wikimedia.org/show_bug.cgi?id=47841
I don't know what the solution is to be honest. This is one of those areas where developing primarily for Wikipedia runs in to use cases for non-encyclopedia wikis Wikimedia hosts, as well as third party instances.
<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
On Wed, Nov 27, 2013 at 3:21 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
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.
I think it would be nice to be able to enforce absolute string length limits.
For instance, on account creation and login, the design is made so that the field label and associated links are on the same line, opposite each other. You can see on German Wikipedia's signup form that they've willfully ignored this, and made the text overflow by putting an entire sentence in to what should be a two to three word label. This is not because German is verbose, but because they ignored the purpose of the message and previous succinct translation. This kind of thing happens pretty regularly on our wikis. Being able to set a max length on MediaWiki messages would prevent a lot of instruction creep and abuse of our l10n/i18n system to uglify the interface.
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 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
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@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 examplehttp://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 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
Yes - counting just on qqq for telling translators that a string must be short is not enough. That's why I said that it's "the bare minimum". Translators look at qqq when they don't know how to translate a string, which is not always the case.
And I hope that I'm not too repetitive when I say that telling to translate to keep strings short should be avoided at all costs.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2013/11/28 Pau Giner pginer@wikimedia.org
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@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 examplehttp://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 jrobson@wikimedia.orgwrote:
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
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I've summarised this discussion here: https://www.mediawiki.org/wiki/Design_best_practices which is now linked to from https://www.mediawiki.org/wiki/Design
On Thu, Nov 28, 2013 at 9:38 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Yes - counting just on qqq for telling translators that a string must be short is not enough. That's why I said that it's "the bare minimum". Translators look at qqq when they don't know how to translate a string, which is not always the case.
And I hope that I'm not too repetitive when I say that telling to translate to keep strings short should be avoided at all costs.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2013/11/28 Pau Giner pginer@wikimedia.org
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@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@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
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design