Checked in beta - works as expected.

Checked on cswiki beta - Special:Tags page has mentor list change tag which can be defined by users. Changes to Special:ManageMentor list will have CommunityConfiguration tag.

Testing note to check after the fix deployment currently (wikifunctions wmf.14`) running https://www.wikifunctions.org/wiki/Z13612 with 100 (as the first input number and 300 as the second input number, would display the correct result (the chosen implementation is Z13642).

wikifunctions beta - the fix is in place including Loading data for Try this function

In T369603#9997550, @KStoller-WMF wrote:

any plans to deploy CommunityConfiguration on frwiktionary?

Thanks for the reminder and thorough testing. The hope is to work on that soon, possibly next sprint: T369711: Release CommunityConfiguration to French Wiktionary.

The frwiktionary release is included in the T360571: CommunityConfiguration Extension Release Plan.

Checked in commons beta and in commons wmf.14(without publishing) - seems to be working as expected. For testing the following was used:

• the url from the task description - https://commons.wikimedia.org/wiki/special:uploadWizard?campaign=wlm-at&fields%5B%5D=32171&fields%5B%5D=47.70159/15.79294&captionlang=de&caption=Sog.+Huthaus%2C+Glockenhaus+am+Knappenberg+%28BDA-HERIS-ID%3A+34175%29%2C+Kleinau+23%2C+Reichenau+an+der+Rax&descriptionlang=de&description=Sog.+Huthaus%2C+Glockenhaus+am+Knappenberg&categories=Huthaus%2C+Glockenhaus+am+Knappenberg%2C+Reichenau+an+der+Rax
• the parameters from https://commons.wikimedia.org/wiki/Commons:Upload_Wizard/Fields_prefilling

Checked on commons beta - the issue is fixed:

Checked in beta - the screenshot below shows error handling (no issues):

In T367223#9972723, @Sgs wrote:

In T367223#9971493, @KStoller-WMF wrote:

(1) the link Community Updates redirects to https://www.mediawiki.org/wiki/Growth/Community_Updates not to the Spanish translation of the page - https://www.mediawiki.org/wiki/Growth/Community_Updates/es. Is it a normal behavior?

@Sgs is this a fairly easy improvement? Ideally we are linking to the translation if it's available, but most languages won't have translated versions of the mediawiki page, so the English version should be the default if there isn't a translation available. (I don't think we need to fix this if it's a complex change, but I assume it's a minor fix).

I'm unfamiliar with the Special:MyLanguage code, but from what I hear this sounds like a bug in the upstream. For instance, if I test against the "Growth" link from This page allows you to edit configuration of...in Special:EditGrowthConfig, dawiki, I also get redirected to the English page rather than the dansk, which exists. @Etonkovidova, could you help confirming this issue is present broadly for any Special:MyLanguage? I haven't found any open phab neither docs around the expected behavior of Special:MyLanguage. That is because I'd like to know which language should be picked up for a user that navigates to https://www.mediawiki.org/wiki/Special:MyLanguage/Growth/Community_Updates from another wiki. Should the wiki source language be used instead of the mediawiki.org user preference?

@Urbanecm_WMF - any plans to deploy CommunityConfiguration on frwiktionary? Currently Special:EditGrowthconfig page does list Suggested edits, disabled, of course.

Checked for Special:CommunityConfiguration - it seems like it's another case of dirty diffs.

Thank you, @Ppery for filing an issue! The issue is confirmed - it's not possible to remove Destination page. The destination title can be removed only in MediaWiki:GrowthExperimentsSuggestedEdits.json, not on Special:CommunityConfiguration/GrowthSuggestedEdits form. I added the steps to reproduce the issue to the task description.

Checked in testwiki wmf.14. An additional task to improve the error message wording filed as a follow-up task: T370239: [wmf.14] CommunityConfiguration/HelpPanel validation error incorrectly asks to enter integer value

@JFernandez-WMF - the figma design displays a two-column layout for Special:Homepage.Such layout will be displayed on desktop with <1465px width. Is it ok to have have the Community updates to be less prominent (and have much smaller area to display image/text) than it's in the design?

In T314149#9976442, @Urbanecm_WMF wrote:

This kind of happened – we proxy beta to production GrowthExperiments API AFAIK.

In T369451#9978140, @KStoller-WMF wrote:

Thanks for reporting and looking into this, @Novem_Linguae!
@Etonkovidova do you think this is the same underlying issue as T368643: Not possible to mark cross-wiki notifications as marked in bulk?

In T367936#9945374, @Michael wrote:

(2) Blanking a numerical field is saved and the field is not listed anymore.

As I understand it, that is working as designed. What behavior would you have expected?

I wasn't sure what values are are actually saved when numerical fields are blanked. For example,

• on Special:CommunityConfiguration/GrowthHomepage I delete values from Try Suggested edits notification and Keep going notification , and click "Save changes"
• the success message is displayed and the form showed those two fields without any values in them

However,

• View history doesn't record this edit
• MediaWiki:GrowthExperimentsHomepage.json doesn't show the fields that I just blanked.
• clicking on View form shows the form with the fields and with the previous values (that I tried to remove) displayed.

In T365406#9977430, @Sneha wrote:

Thanks @Etonkovidova I followed your instructions and everything seems to be working fine. Except for when it scrolls up to caption error, the page stops at the error message so the caption field itself is above the fold. In other cases the fields/input boxes for which the error is triggered is also visible upon scrolling. Same should happen for caption field.

@Sneha - I checked again in commons wmf.13 and all seems to be working as expected. Maybe I did miss some test scenarios that produce the incorrect scrolling, so please review the steps below:

1. Upload three files as own work
2. The Title field in the Describe step will display "Please write a more informative title" error message.
3. Change the title of the first file to some title, so the error message will be gone.
4. Scroll down and click on Publish files button.

In T369603#9966171, @JFernandez-WMF wrote:

I've been asked about something similar happening in the Mentorship form. If the admin has turned off Mentorship features, shouldn't the other Mentorship-related settings be in a disabled state? cc @KStoller-WMF

Do you have any specific Mentorship-related settings in mind? I can only think Help panel setting "Where should questions from the help panel be directed?". When the Mentorship disabled, it's automatically switches to Help desk option. Anything else?

@Trizek-WMF - when Mentorship has never been enabled on a wiki, Special:ManageMentors won't display a banner. As an example, cawikihas Special:ManageMentors and Special:EnrollAsMentor - and those pages do not inform users that the mentorship is not enabled.

My question got answered - cawiki wmf.13 displays the banner on empty Special:ManageMentors page:

In T369591#9972441, @Michael wrote:

I don't seem to be able to reproduce any of the issues mentioned in the descriptions on enwiki's Special:Notifications (already on .wmf13). @Etonkovidova can you confirm?

I'm not able to reproduce the issue mentioned here in the comments either, but maybe I'm not understanding it well enough.

Thanks, @Izno - yes, since "mw-echo-ui-notificationItemWidget-content-message-body" is the same element as in the Echo overlay, this issue can be added to .

@Urbanecm_WMF - could you provide some specific examples how to disable Suggested edits and Help panel in the config files?

Thank you, @Sjoerddebruin for reporting it! That change in color when a notifications changes from unseed state to the seen state, seems to be consistent with instances where such colors appear. For example, a success message (for a saved edit) displays the same color:

The found issues (reported in the task) were separated into phab tasks (see the tasks in the Task Graph for this task). Closing as Resolved since the scope of this task is done.

Checked on commons wmf.13 - all specs seem to be in place. The additional refinements will be addressed in T369746.

In T369053#9964550, @matthiasmullie wrote:

@Etonkovidova I misunderstood the ask and thought we wanted to convert all warnings to notice style.
Above patch should change warnings back to their original style, and re-introduce "notices" for "we recommend providing a full date if it is known" (date) and "we recommend keeping the number of items to a maximum of x" (depicts/statements)

As for depicts: the only thing we have there is a notice when more than 3 statements have been selected (from the autocomplete field)
Looks like you had ,,,,, input there (which, I suspect isn't triggering any autocomplete suggestions), which is simply ignored; only things ("chips") selected from the autocomplete matter.
(Nit: we could revise how that input field works and how/when it triggers warnings, but that's a separate thing)

@JFernandez-WMF @KStoller-WMF - the both links in the task description don't seem to be working - displays "couldn't find file" message.
I found the following figma references to Community updates banner -this figma link; not sure if the design there is up-to-date.

To summarize

• on commons beta the Date field doesn't display a warning - it's either an error message or a notice
• I was not able to trigger any message for the depicts field

Checked in beta: -description have been added.

Checked on eswiki beta - works as expected; Special:ManageMentors displays the banner if the mentorship is disabled:

Thx, @Urbanecm_WMF for a suggestion to test frwiktionary beta!

In T366672#9950423, @Sgs wrote:

I agree it does not seem a high priority issue. I we should be able to replace the OOUI widget by T363375: Popover: Add Popover component to Codex in the mid-term, for the Echo menu at least. If @Etonkovidova agrees I think we can resolve this issue.

In T367986#9945425, @Michael wrote:

I'm not sure if anything here still needs doing? We've seem to have fixed the immediate issue, but should we still look into transitioning away from growth-specific tokens to more generic ones?

I'm adding the Technical-Debt tag here because it mainly seems like a refactoring that we may or may not want to do.

@matthiasmullie - I think I need some clarification on the following from https://gerrit.wikimedia.org/r/1051758

• the style of warnings has been updated to look like notices

Checked all three scenarios on commons beta - work as expected.