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 .

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.)

<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.

In T236050#5596063, @MMiller_WMF wrote:

@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?

In T236050#5596066, @RHo wrote:

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.

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

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.

@MMiller_WMF I filed T236738: Newcomer tasks: 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

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:

Waiting on https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/547830/ to be merged.

Re-checked after https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/547830/ is merged - arwiki betalabs shows the following:

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?

In T236050#5638618, @MMiller_WMF wrote:

@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.

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

In T236050#5639175, @RHo wrote:

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?

In T236050#5643703, @Tgr wrote:

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

In T236050#5639175, @RHo wrote:

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 T236050#5628412, @Dyolf77_WMF wrote:

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).

Checked in production wmf5 with the hidden feature - the number of readers displayed are different 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.

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.

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

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.

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

In T236050#5677284, @Tgr wrote:

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.

In T236050#5680047, @Tgr wrote:

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)

Actually not, WikimediaPageViewService does not really care about the granularity but CachedPageViewService does a bunch of date arithmetics which should be rewritten (or maybe gotten rid of, it's probably trying to be too clever). A task for another day.

I will just go with dailies for now.

Change 558730 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Use daily uniques in SuggestedEdits footer

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

Change 558730 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Use daily uniques in SuggestedEdits footer

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

The new message has not been translated yet - Growthexperiments-homepage-suggestededits-footer.

@Tgr - comparing kowiki betalabs and kowiki wmf.11 I see the difference in numbers and no difference in the labels. It's fine for now since this task will be deployed for wmf.14. Just thinking about possible implications in the future - I guess there is no way to ensure (except for the communities/users being attentive) that whoever would be changing the label, should be careful do not change "daily" wording?
If translations will not be done in time for wmf.14, the numbers for daily will be displayed with the "monthly" label, just as it is now in betalabs.

betalabs	wmf.11

I can add a new message if that's less confusing. I figured if translations are late, one that says month instead of day is less problematic than one that's in English.

Now translated for all the languages where suggested edits are enabled.