Discussed previously: T69959, T220802, T395283

To recap, the problem is that MediaWiki formats the durations passed as parameters always in the nominative case, which works for English as it doesn't really have grammatical cases, so a phrase like "1 hour" can be used directly in phrases like "1 hour ago" or "in the last 1 hour" – but it doesn't work for other languages, such as Polish, where "1 godzina" (nominative) becomes "1 godzinę temu" (accusative) or "w ciągu ostatniej 1 godziny" (genitive).

Separately, the durations must also be usable to modify forms of other words, depending on the plurality (e.g. in Polish it would be "w ciągu ostatniej 1 godziny" but "w ciągu ostatnich 2 godzin") and the unit's grammatical gender (e.g. for days it's "w ciągu ostatniego 1 dnia", "w ciągu ostatnich 2 dni").

The only way we currently have to support fully correct translation of these phrases is a "combinatorial explosion" of having a separate message for every context × every possible unit (the numbers can still be passed as parameters), which is a chore for developers and translators alike.

Also for other reasons in other languages; e.g. Hungarian doesn't have much in the way of grammatical cases, but it's an agglutinative language so prepositions are attached to the end of nouns, and can take different forms based on the noun's vowel harmony. This kind of problem comes up whenever you have a message parameter that is itself a word, and durations are one of several cases where you can't reasonably avoid that. I don't think the problem is solvable; and to the extent it is solvable, it seems to be seen as not worth the effort (I once proposed adding vowel harmony rules to the Hungarian i18n code, and that got rejected as being too much of a maintenance burden).

In any case, I don't think this issue is in any way specific to MediaWiki-Core-AuthManager or WikimediaMessages. Other examples include ago (and consequently calls to MWTimestamp::getRelativeTimestamp(), although apparently it's not used much), rcfilters-show-new-changes, translate-supportedlanguages-cached, growthexperiments-homepage-recent-questions-posted-on and no doubt many more.

As per T407246, for Wikimedia's use case $2 in this particular message is either "10 minutes" or "24 hours". Then maybe it wouldn't be too difficult to use and maintain two new Wikimedia specific messages for these particular durations?

These are the current messages:

acct_creation_throttle_hit

Visitors to this wiki using your IP address have created {{PLURAL:$1|1 account|$1 accounts}} in the last $2, which is the maximum allowed in this time period.
As a result, visitors using this IP address cannot create any more accounts at the moment.

wikimedia-acct_creation_throttle_hit

Visitors to this wiki using your IP address have created {{PLURAL:$1|1 account|$1 accounts}} in the last $2, which is the maximum allowed in this time period.
As a result, visitors using this IP address cannot create any more accounts at the moment.

If you are at an event where contributing to Wikimedia projects is the focus, please see [[m:Mass account creation#Requesting_temporary_lift_of_IP_cap|Requesting temporary lift of IP cap]] to help resolve this issue.

My proposal is to do away with both the count of accounts and duration. I don't think we need to provide the specifics of the rate limit being tripped:

acct_creation_throttle_hit

There have been too many account creation attempts from your IP address recently. Please try again later.

wikimedia-acct_creation_throttle_hit

There have been too many account creation attempts from your IP address recently. Please try again later.

If you are at an event where contributing to Wikimedia projects is the focus, please see [[m:Mass account creation#Requesting_temporary_lift_of_IP_cap|Requesting temporary lift of IP cap]] to help resolve this issue.

IMO it's unhelpful to not know how much you need to wait before retrying, especially since these kinds of throttles usually expire in minutes rather than days.

In T407653#11346273, @Tgr wrote:

IMO it's unhelpful to not know how much you need to wait before retrying, especially since these kinds of throttles usually expire in minutes rather than days.

+1

My proposal is to simplify the message language to avoid the "last" terminology -

Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later.
Kindly note that there is a limit of one account creation allowed every 10 minutes with a maximum of 6 account creations permitted every 24 hours.

This informs them about the limits but doesn't tell them which of the two limits have been tripped. I think it's OK to do this assuming good faith editors will likely try again later and vandals will just move on.

In T407653#11346273, @Tgr wrote:

IMO it's unhelpful to not know how much you need to wait before retrying, especially since these kinds of throttles usually expire in minutes rather than days.

OTOH we don't need to make it easier for casual vandals to understand how long they need to wait before editing again. The rate limit should in theory be tripped rarely in most good faith editing scenarios. For the scenarios where good faith editors are impacted, we should funnel users towards T357802: Design & Copy: Prompt user to create a regular account after temp account creation rate limit trip. Temp account rate limit trips dashboard, for reference.

In T407653#11352487, @Niharika wrote:

My proposal is to simplify the message language to avoid the "last" terminology -

Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later.
Kindly note that there is a limit of one account creation allowed every 10 minutes with a maximum of 6 account creations permitted every 24 hours.

This informs them about the limits but doesn't tell them which of the two limits have been tripped. I think it's OK to do this assuming good faith editors will likely try again later and vandals will just move on.

@Amire80 thoughts on this proposal?

In T407653#11391416, @Niharika wrote:

In T407653#11352487, @Niharika wrote:

My proposal is to simplify the message language to avoid the "last" terminology -

Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later.
Kindly note that there is a limit of one account creation allowed every 10 minutes with a maximum of 6 account creations permitted every 24 hours.

This informs them about the limits but doesn't tell them which of the two limits have been tripped. I think it's OK to do this assuming good faith editors will likely try again later and vandals will just move on.

@Amire80 thoughts on this proposal?

If the values are hardcoded in the messages, then it will probably work in terms of grammar, but I'm not sure that hardcoding is a good idea.

If the values are autofilled from configuration parameters, it will run into the same grammar problems.

It will be easier if it's more like a table:

Limits on account creation:

A table is a bit dry, but easy to read and doesn't require grammar work.

Or a list:

Limits on account creation:

• 1 account creation per 10 minutes
• 6 account creation per 24 hours

This will probably require a message for each time unit (seconds, minutes, hours, days, etc.), but it's doable, too.

@Amire80 okay! Let's do the bulleted list.

Change #1211649 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Update acct_creation_throttle_hit to display the limits

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

Change #1211657 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/WikimediaMessages@master] Update acct_creation_throttle_hit to display the limits

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