Page MenuHomePhabricator

Portal: Showing smaller wikis in top 10 - what about missing labels?
Closed, ResolvedPublic

Description

The spike realized T120866 showed interesting results.
Finding the smaller wikis amongst the hundreds of links of the bottom of the page is too painful. Giving more visibility to the wikis that match user's (navigator) preferred languages seem to make sense as a user standpoint.

Screen Shot 2015-12-18 at 9.13.38 AM.png (846×1 px, 284 KB)
Screen Shot 2015-12-18 at 9.13.54 AM.png (836×1 px, 284 KB)

While we have the stats for these smaller wikis (page views and articles), we are missing some labels that should be displayed along the wiki link in the top 10:

  • Slogan (enwiki="The Free Encyclopedia")
  • Label for the word "articles"

A presumptive decision was to fallback to English labels when these were missing:

  • slogan falls back to site name, and then falls back to enwiki site name(=Wikipedia).
  • articles label falls back to enwiki articles label.

I think there are 4 options:

  1. Do not make any fall back. Show label if exists. Show nothing instead.
  2. Do not make any fall back. Show label if exists. Show a link instead to ask contribution to this missing label.
  3. Fall back to english, assuming a large number of people can read it.
  4. Fall back to another "preferred language" before falling back to "english", assuming people always prefer to read in one of their preferred language rather than english.

We need your opinions/concerns. Please feel free to chime in, suggest another option.

Ideally we would like a decision before end of year (to be able to run an A/B test early next year).

Event Timeline

JGirault raised the priority of this task from to Needs Triage.
JGirault updated the task description. (Show Details)
JGirault subscribed.

Would it look too weird to omit the slogan from minor languages that get selected? It might make sense to style these languages differently anyways. For example, see how Facebook highlights likely languages in yellow in its language selector.

If we could gather slogans for more languages and stuff them in data-slogan attributes, would that weigh down the portal too much? Most Wikipedia slogans (particularly for older Wikipedias, regardless of size) are already available on various Meta pages, from sister project boxes on sister projects, or from the MediaWiki:Fromwikipedia message on the wiki itself.

Not to mention localized logos. :-) So the primary consideration would be size.

@mxn,
I like the idea to style these languages differently. To illustrate what Facebook does, here's a screenshot:

Screen Shot 2015-12-21 at 4.00.18 PM.png (1×1 px, 289 KB)

For the slogan, I think it is fine to omit it. I agree with you, size is the primary concern. It wouldn't look too weird without the slogan, especially with a different styling that will make it interestingly different.

For the articles word, would you omit it too?

With the Wiktionary portal, I wound up including data about the preferred logo of every wiki listed in the search menu. That compromise worked because most of the smaller wikis used the default logo anyways. A few more slogans might not hurt so much.

Translations of "articles" are more difficult to come by than translated slogans, especially when you consider inflection. But without that word, is the number alone intuitive?

It might be a terrible idea, but how about sandwiching the number between a mini, gray version of the blue book stacks we use in the section headers?

If that doesn't work, I think it would be fine to show the English word. We try to avoid anglocentrism in the portals, but there's only so much we can do (cf. "Find a language").

I updated the page: https://people.wikimedia.org/~jgirault/

To show:

  • large highlight: the entire box is highlighted
  • small highlight: only the link is highlighted

For these two examples, I have removed the slogan when we don't have it, and I have also removed the articles word.

Please try :)

Thanks for the mockups. For both of them, I would move the language name and article count closer to each other.

I think the large highlight is a bit too pronounced; with more than one detected language, the sharp edges make it more difficult to perceive the languages as forming a complete ring around the puzzle ball. The small highlight mockup better preserves the ring effect, but on the other hand it may be too subtle on low-contrast screens. Applying a small padding to the highlighted names may help, but I think rectangles just don’t fit well with the circular layout in this section.

If we stick to this tint of yellow, we could use box-shadow and border-radius to achieve a glowing effect that doesn’t clash with the ring layout. Would this look too tacky?

background-color: rgb(255, 251, 223); /* without a background? */
border-radius: 3em;
box-shadow: 0 0 1em 1em rgb(255, 251, 223);
transition: background-color 1s ease, box-shadow 1s ease;

Another possibility would be to permanently underline the names of the auto-detected languages, instead of underlining only on hover. border-bottom could be used instead of text-decoration: underline to make Arabic-script text more legible. The border could be 3–4px thick to make it stand out more.

Deskana moved this task from Needs triage to On Sprint Board on the Discovery-ARCHIVED board.

Deb to look at this to define next steps.

Hi,

What if we do something like this - where we have the slogan underneath the logo and not under each of the respective languages/number of articles. The slogan can be in whatever language the user has as a preference in their browser and if no pref is set, we can display the slogan in English.

I do like the idea of taking the top 9 languages around the globe and then if the user's preference isn't in those top 9, we add it (if it exists) in the first position. That gives the user easy access to a wiki in their preferred language, but also displaying the most popular languages.

portal-one_label.png (753×1 px, 158 KB)

That's not a bad idea! Perhaps the markup would contain the English slogan for the benefit of users without JavaScript enabled, then localize the slogan as soon as possible. What if the user's language isn't one we have a slogan for, though? Should we leave a blank space so as not to appear anglocentric?

That's not a bad idea! Perhaps the markup would contain the English slogan for the benefit of users without JavaScript enabled, then localize the slogan as soon as possible. What if the user's language isn't one we have a slogan for, though? Should we leave a blank space so as not to appear anglocentric?

Hi! If we don't have a slogan for the user's language, yes, we can leave it blank. :)

@debt This mockup is interesting. I like showing the localized slogan under the WikipediA logo.

I also think we should leave it blank in case language is missing. I think ideally the language of the page should match the selected language of the search box.
I suggested here https://phabricator.wikimedia.org/T124427#1956582 something about engaging people to translate missing labels.

I've put my suggestion in this card: https://phabricator.wikimedia.org/T124486 to be sure that we don't hijack the original intent of this existing card to add in the user's localized language link as the 10th position (if their preferred lang is not in the top 10).

@JGirault I'd like to discuss a technical detail of this feature a bit. (not sure if this ticket is the right place)

We have translations for the sitenames, and I noticed on your demo that your loading the API response on the page to get all the translations.

I'm a little concerned that this API response is slightly heavy. Uncompressed, it weighs in at 10kb.
Now since the page is gzipped, this might be a non-issue (gzipped the response is 3kb) but I'm wondering if there's a better way to store these translations.

@mxn suggested stuffing these translations in data attributes, I think we could modify our stats script to accomplish this.
This approach would be slightly lighter than the API response.

We could also ajax in a single (or several) translations based on the users navigator.languages but this might produce a FOUC, as it would be done on document.ready.

Or, we could reformat and slim down the API response to just include the properties we need (sitename and url).

The reason I bring this up is that if we add more translations to the page with this approach, like T124427 that too would add weight to the page.

@Jdrewniak I do agree.
Right now there does not seem to be a best solution. We either have to embed these labels into the page (thus making the page heavier and heavier), load them as an external script, or make an API call.

I think the server should deliver a different page based on a specific cookie (we already have searchLang cookie). In this case we can deliver a lighter page in the right language and it allows us even more server side rendering. But it also involves lots of changes - involving security and operations - and this may be out of our capable scope for now. (/cc @MaxSem FYI)

Closing this ticket - it was "fixed" by the work done in https://phabricator.wikimedia.org/T121843