Page MenuHomePhabricator

Newcomer tasks: Footer for suggested edits module
Open, Needs TriagePublic

Description

  • The bottom of the module should have a footer that reads, "Other users have noted these articles need work. Help make <Wiki project> better for its <#> readers each day.
  • <Wiki project> should contain the project name, like "Czech Wikipedia" or "French Wiktionary".
  • The number of readers each month day should come from unique devices, averaged over the days in the preceding month. It should be rounded in a reasonable way. Perhaps if under 1 million, it should be rounded to the nearest hundred thousand, and if over a million, rounded to the nearest million. Then displayed with an abbreviation like 400k or 4 million. This could be an average of months across the last year, the most recent month, or something along those lines. If we prefer to hardcode these numbers for the first version, the numbers are below. IF we do hardcode, we'll break out the automatic calculations into a separate task. The numbers below come from Wikistats 2, reading the "average" number of unique devices over the past year (line|1-year|~total|daily | like this):
    • Czech: ~900 thousand
    • Korean: ~1 million
    • Vietnamese: ~1 million
    • Arabic: ~3 million
    • Basque: ~35 thousand
    • Armenian: ~60 thousand
    • Hungarian: ~700 thousand
    • Ukrainian: ~700 thousand

Details

Related Gerrit Patches:
mediawiki/extensions/GrowthExperiments : masterSuggestedEdits: Allow languages to disable large number suffixes
mediawiki/extensions/GrowthExperiments : masterMake SuggestedEdits footer more human-readable
mediawiki/extensions/GrowthExperiments : masterFooter for suggested edits module

Event Timeline

kostajh removed kostajh as the assignee of this task.Oct 21 2019, 11:25 AM
kostajh created this task.

The number of readers each month should come from unique devices. It should be rounded in a reasonable way. Perhaps if under 1 million, it should be rounded to the nearest hundred thousand, and if over a million, rounded to the nearest million. Then displayed with an abbreviation like 400k or 4 million. This could be an average of months across the last year, the most recent month, or something along those lines.

Doesn't feel great, but we could consider hardcoding the number for this task and then creating a separate task to get the number dynamically, and that task could go farther down the list of priorities for NewcomerTasks 1.0 .

Tgr added a comment.Oct 22 2019, 7:08 AM

It should be possible to get the device count via MediaWikiServices::getInstance()->get( 'PageViewService' )->getSiteData( 30, PageViewService::METRIC_UNIQUE ). (If you want to be nice to non-Wikimedia reusers you can check for supports( PageViewService::METRIC_UNIQUE, PageViewService::SCOPE_SITE ) first and show some static fallback if it's false.)

Tgr added a comment.Oct 22 2019, 7:14 AM

<Wiki project> should contain the project name, like "Czech Wikipedia" or "French Wiktionary".

Some discussion on that in T235810#5586618. Maybe go with {{SITENAME}} initially, and then we can add a better magic word if it's deemed worth the effort.

It should be rounded in a reasonable way. Perhaps if under 1 million, it should be rounded to the nearest hundred thousand, and if over a million, rounded to the nearest million. Then displayed with an abbreviation like 400k or 4 million.

Sounds like something that might have all kinds of internationalization gotchas. We have similar funcionality in Language for time (Language::formatDuration, Language::getHumanTimestamp) but not for numbers AFAIK.

@kostajh and @Tgr -- I am fine with hardcoding it, especially if that will avoid internationalization gotchas around the rounding. I am adding the hardcoded numbers in the description.

RHo added a comment.Oct 22 2019, 5:20 PM

@kostajh and @Tgr -- I am fine with hardcoding it, especially if that will avoid internationalization gotchas around the rounding. I am adding the hardcoded numbers in the description.

OTOH - @Tgr @kostajh can the same i18n formatting on number of articles in the Impact module T230377#5428732 be applied here?

MMiller_WMF updated the task description. (Show Details)Oct 22 2019, 5:22 PM
Restricted Application added a subscriber: Base. · View Herald TranscriptOct 22 2019, 5:22 PM
Tgr added a comment.Oct 22 2019, 6:08 PM

OTOH - @Tgr @kostajh can the same i18n formatting on number of articles in the Impact module T230377#5428732 be applied here?

I don't think there's any rounding going on there. Number formatting in the strict sense (putting in commas and such) is handled well by MW core, that's not going to be a problem.

Tgr claimed this task.Mon, Oct 28, 3:51 AM

Filed T236641: Create Language method for human-readable numbers about having proper number formatting eventually.

Change 546411 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Footer for suggested edits module

https://gerrit.wikimedia.org/r/546411

Tgr added a comment.Mon, Oct 28, 8:39 AM

Then displayed with an abbreviation like 400k or 4 million. ... If we prefer to hardcode these numbers for the first version...

After thinking about this for a bit, hardcoding seems almost as much trouble than not hardcoding. The user language and project do not necessarily correspond, so we'd have to have those 8 numbers in all the languages, or have the words like "million" in all languages and piece the numbers together with that. Or we could use Language::formatComputingNumbers with K/M/B, not sure how widely that's understood though.

For now I'm just rounding the number (so something like 30,000,000 instead of 30 million), will revisit the number formatting part in a separate patch.

@Tgr -- I think it is fine to use the full number without the words for now. We can even break that off into a separate task for a different version. Could you make that task?

Also, with respect to hard coding, I am fine with the translations not existing for other languages. I think it will be exceedingly rare for our target users to be editing, say, Arabic Wikipedia with the interface in a language other than Arabic.

Tgr added a comment.Mon, Oct 28, 8:56 PM

@MMiller_WMF I filed T236738: Server-side rendered version of suggested edits module for the no-JS (or rather, server side rendering) discussion, and boldly put it in the future release bin - please move if needed.
Per the conversation on the patch, I don' think this task is blocked on that.

Change 546411 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Footer for suggested edits module

https://gerrit.wikimedia.org/r/546411

We decided in our Growth team meeting that we can use scientific abbreviation here.

Per @JTannerWMF, will do a hacky shortcut for T236641: Create Language method for human-readable numbers based on Language::formatComputingNumbers and SI-ish notation.

Change 547651 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Make SuggestedEdits footer more human-readable

https://gerrit.wikimedia.org/r/547651

Change 547651 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Make SuggestedEdits footer more human-readable

https://gerrit.wikimedia.org/r/547651

Etonkovidova added a comment.EditedFri, Nov 1, 11:29 PM

For PM review - the betalabs counter is unchanged for all betalabs wiki. I made a note to check after deployment (unless we specifically decide to have different numbers for different wikis in betalabs).

General notes

  • on the abbreviation usage - most likely ambassadors would have some insights on which abbreviations are commonly used in their languages
  • AFAIK, English usage of the abbreviations below is limited to financial/scientific context only.
"growthexperiments-homepage-suggestededits-footer-suffix": "$1",
	 "$1K",
	 "$1M",
	 "$1B",
	 "$1T",

It feels rather abrupt to see B instead of just billion:

In arwiki betalabs the following text "80M" is a bit confusing. If I'm an Arabic reader, the text should be: مليون or مج instead of M (see this Metric prefix table in ar wiki).

I agree that it "2B" or "80M" turn out to not look very good for the user. @Tgr -- seeing this, what do you think we should do? Should we go back to "80,000,000" and wait until we can work on T236641: Create Language method for human-readable numbers?

Choosing between 1T or 1,000,000,000 is like choosing between a rock and a hard place.

IMO, the only ideal solution is to push up the priority of T236641: Create Language method for human-readable numbers. It would be a very useful piece of code.

@Tgr -- I'm moving this back to Ready for Development so that we can solve the "2B" issue either by:

  • Writing out the number: 2,000,000,000
  • Hardcoding the phrase for each of our target languages, as written in the description: "2 billion".

Both of those would then be superseded by T236641 when we do that. What do you think is the better option?

RHo added a comment.Wed, Nov 6, 7:27 AM

@Tgr -- I'm moving this back to Ready for Development so that we can solve the "2B" issue either by:

  • Writing out the number: 2,000,000,000
  • Hardcoding the phrase for each of our target languages, as written in the description: "2 billion".

Both of those would then be superseded by T236641 when we do that. What do you think is the better option?

My vote is to hardcode until T236641 is done if effort is minimal. Otherwise I still prefer the notation over writing out the full number, but perhaps with 1 decimal point will make it render a bit more nicely once it hits the million and above size (850K, 1.2M, 2.0B)
Also, sorry if this will be covered in the T236642 but is there really no way to localise these short form numbers like mentioned at http://cldr.unicode.org/translation/number-patterns#TOC-Short-Numbers ?

Hardcode too for me. It is easier to cover all cases this way.

Tgr added a comment.Thu, Nov 7, 10:52 AM

I can replace B with billion etc, I'm sure that will be weird in some languages but still less bad than hardcoding.

is there really no way to localise these short form numbers like mentioned at http://cldr.unicode.org/translation/number-patterns#TOC-Short-Numbers ?

Isn't that what the current code does?

RHo added a comment.Thu, Nov 7, 11:14 AM

I can replace B with billion etc, I'm sure that will be weird in some languages but still less bad than hardcoding.

is there really no way to localise these short form numbers like mentioned at http://cldr.unicode.org/translation/number-patterns#TOC-Short-Numbers ?

Isn't that what the current code does?

Oh, my apologies. I thought it was not based on reading @Dyolf77_WMF's comment earlier that the Arabic short form for million wasn't used.

In arwiki betalabs the following text "80M" is a bit confusing. If I'm an Arabic reader, the text should be: مليون or مج instead of M (see this Metric prefix table in ar wiki).

Etonkovidova added a comment.EditedSat, Nov 9, 1:52 AM

Checked in production wmf5 with the hidden feature - the number of readersdisplayed are differenc from the task description.
euwiki (Basque wiki )- 900K
cswiki 20M
kowiki 30M
viwiki 30M
arwiki 80M

Are we using different numbers instead of those that are in the task description?

@Catrope discovered that the API for unique devices only supplies dailies, and what we wanted was one monthly number. So we will change the specification to be about dailies. This will also change the copy and translation.

Catrope added a comment.EditedWed, Nov 13, 2:17 AM

Specifically, this line in the PageViewInfo extension hard-codes 'daily' as the granularity, and declines to support 'hourly' or 'monthly' because it says it would be too complicated.

MMiller_WMF updated the task description. (Show Details)Wed, Nov 13, 2:21 AM

Change 550552 had a related patch set uploaded (by Kosta Harlan; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Allow languages to disable large number suffixes

https://gerrit.wikimedia.org/r/550552

Change 550552 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Allow languages to disable large number suffixes

https://gerrit.wikimedia.org/r/550552

Tgr added a comment.EditedWed, Nov 20, 3:30 AM

I didn't bother adding monthly metrics support to PageViewInfo because that's just daily data summed up in batches of 30 (or it can be aligned to calendar months if someone particularly cares; in any case, monthly data is contained in daily data). For hourly, I just doubted there'd be much need for it (and it's a lot of data to cache, especially if we then also allow hourly granularity for articles).

The current footer does display monthly (well, 30-daily) numbers.

Tgr added a comment.EditedWed, Nov 20, 3:45 AM

Ehhh right, that works for pageviews but not for uniques. I should probably recondsider not supporting monthlies.

Tgr added a comment.Wed, Nov 20, 9:50 PM

Ehhh right, that works for pageviews but not for uniques. I should probably recondsider not supporting monthlies.

Filed as T238800: Allow monthly granularity for PageViewService at least for uniques. It should be fairly easy to make a quick internal version of that (do not touch the interface and API, just expose granularity in WikimediaPageViewService and make sure it gets factored into the cache key) and pass that to SuggestedEdits instead of the default PageViewService, instead of rewriting everything to use dailies.