In T362203#9705899, @Urbanecm_WMF wrote:
Would it be okay if the "View History" link lead directly to eg. https://es.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:GrowthExperimentsMentorship.json&action=history (where there would >be no obvious way to get back)? Or do we want to do something to make this more clear?

I think that's OK for the initial pilot release, but I think we should follow up with adding a link back to the form that follows the standard wiki UX.

@JFernandez-WMF - any thoughts on this?

One note on the design, the current mock-up shows a "Read" button but we don't have a reading mode yet. Should we change that to "Edit" for now? cc @KStoller-WMF @JFernandez-WMF

Relevant discussion from the other task:

In T362203#9739550, @Cyndymediawiksim wrote:

In T362203#9707924, @Tacsipacsi wrote:

Couldn’t the action=history page be made linking back to Special:CommunityConfiguration? Similarly to VisualEditor’s Edit link, Community Configuration provides an alternate edit view of the same page, so putting its link among the content actions would make sense. (And even vice versa: simply call Skin::setRelevantTitle() on Special:CommunityConfiguration, which gives a history link, a talk page link etc. for free.)

@Tacsipacsi, The suggestion to use Skin::setRelevantTitle() on Special:CommunityConfiguration is a great idea as it would directly link to the history page of the relevant configuration file. However, this approach could lead to a situation where there is no obvious way for users to navigate back to the Special:CommunityConfiguration page from the history page as @Urbanecm_WMF highlighted above.

To address this we could consider implementing a solution, where a return link is prominently displayed, allowing users to easily switch back to the Special:CommunityConfiguration page.

For example, we could add a “Return to Community Configuration” link at the top of the history page. This would ensure that users have a clear and convenient way to navigate back to the main configuration page after reviewing the history.

In T362203#9739996, @Cyndymediawiksim wrote:

In T362203#9739672, @Tacsipacsi wrote:

In T362203#9739550, @Cyndymediawiksim wrote:

However, this approach could lead to a situation where there is no obvious way for users to navigate back to the Special:CommunityConfiguration page from the history page as @Urbanecm_WMF highlighted above.

This is what the link among the content actions aims to solve.

@Tacsipacsi,for my clarification, what you are suggesting is adding a link to Special:CommunityConfigurations among these content actions, meaning that when a user is viewing the history page of a configuration file, there would be a tab that links directly to the Special:CommunityConfiguration page?

In T362203#9740703, @Tacsipacsi wrote:

Yes, except that the link (tab) could appear on every page action (including view, source code editing etc.) rather than only on the history action; and that I used wrong terminology: it’s a view, not a content action. You can use SkinTemplateNavigation::Universal.

In T363788#9756227, @KStoller-WMF wrote:

In T362203#9705899, @Urbanecm_WMF wrote:
Would it be okay if the "View History" link lead directly to eg. https://es.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:GrowthExperimentsMentorship.json&action=history (where there would >be no obvious way to get back)? Or do we want to do something to make this more clear?

I think that's OK for the initial pilot release, but I think we should follow up with adding a link back to the form that follows the standard wiki UX.

@JFernandez-WMF - any thoughts on this?

Agreed, thanks!

In T363788#9756631, @Sgs wrote:

One note on the design, the current mock-up shows a "Read" button but we don't have a reading mode yet. Should we change that to "Edit" for now? cc @KStoller-WMF @JFernandez-WMF

Yep good catch, let's change it to "Edit". I believe we won't be able to (for now) have a read-only mode since most form components do not support read-only states.

In the case of read-only mode, the "Edit" tab should be "Show source", per editor consistency.

In T363788#9758716, @Trizek-WMF wrote:

In the case of read-only mode, the "Edit" tab should be "Show source", per editor consistency.

Wouldn't that be confusing? I would expect "Show source" to navigate to the relevant mediawiki json page not the community configuration editor.

Change #1026406 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Add 'history' and 'edit' tabs via SkinTemplateNavigation__UniversalHook

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

In T363788#9759009, @Sgs wrote:

In T363788#9758716, @Trizek-WMF wrote:

In the case of read-only mode, the "Edit" tab should be "Show source", per editor consistency.

Wouldn't that be confusing? I would expect "Show source" to navigate to the relevant mediawiki json page not the community configuration editor.

Read stands for content you consult. Then come editing actions, which are either possible ("Edit") or not ("Read source").
Here, we have a hybrid status, where anyone can read the page, with closed fields if they aren't allowed to edit them.

I would go with "view form" and "view history" instead (ping @JFernandez-WMF), to switch between the two states.

I checked on several Special pages, and this notion of "read" is not used. If a page is editable with fields and needs extra tabs, like Special:Watchlist, a solution exists:

In https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1026406/comments/d9c9a462_9f76b034, @Cyndymediawiksim wrote:

Using Skin::setRelevantTitle() like this : $this->getSkin()->setRelevantTitle($titleObjectForTheJsonPage) mirrors navigation elements of MediaWiki:GrowthExperimentsConfig.json. The figma only has 2 tabs View History and Edit

Could the Figma design be changed? Is there any reason not to display the namespace, View source etc. tabs?

In T363788#9766926, @Tacsipacsi wrote:

In https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1026406/comments/d9c9a462_9f76b034, @Cyndymediawiksim wrote:

Using Skin::setRelevantTitle() like this : $this->getSkin()->setRelevantTitle($titleObjectForTheJsonPage) mirrors navigation elements of MediaWiki:GrowthExperimentsConfig.json. The figma only has 2 tabs View History and Edit

Could the Figma design be changed? Is there any reason not to display the namespace, View source etc. tabs?

I think an exact mirroring (Message, Discussion, English > ..., Read, Edit source, View history) would be somehow close to what we need in terms of wording but there are several link "metaphors" that do not work well.

• Message is confusing and a leak from the technical restriction of using the MediaWiki namespaces for json config pages.
• Discussion seems ok.
• The language drop down does not make sense since the user is not viewing a content translate-able page. Also the underlying content, a JSON config, is not translated.
• Read, this will make sense once we implement T363525: Community Configuration edit form: protected / read only view
• Edit source is confusing if then the user gets an HTML form instead of a JSON editor. We could use it to link to the underlying config page, although we want to promote the usage of the editor form over the JSON editor in the config page. I would advocate for "View source" instead and a link without action=edit
• View history is on point and the only link in the scope of this task.

Based on this, the current design needs to rather A) change the text from "Read" to "Edit" in the current selected tab (black font color) or B) Have three tabs "Read", "Edit", "View history" with the current tab selected being "Edit". cc @JFernandez-WMF

In T363788#9775095, @Sgs wrote:

• The language drop down does not make sense since the user is not viewing a content translate-able page. Also the underlying content, a JSON config, is not translated.

Where do you see this? I don’t see a language selector in the tab bar of https://sr.wikipedia.org/wiki/MediaWiki:GrowthExperimentsConfig.json?useskin=vector-2022.

• Read, this will make sense once we implement T363525: Community Configuration edit form: protected / read only view

This links to the read view of the MediaWiki message, which is a JSON representation (see above link). While not very user-friendly, I think it still makes sense to have, and to keep as-is even after T363525.

• Edit source is confusing if then the user gets an HTML form instead of a JSON editor. We could use it to link to the underlying config page, although we want to promote the usage of the editor form over the JSON editor in the config page. I would advocate for "View source" instead and a link without action=edit

While it should be rarely needed, it could come handy if something went wrong or someone wants to quickly copy configuration from another wiki. I’d keep it as-is, but add a new tab called Edit with form or Edit with wizard or something like that, which links to Special:CommunityConfiguration.

The label of the Message tab could be changed and the Edit with form tab could be added in a SkinTemplateNavigation::Universal hook handler – but based on whether $skin->getRelevantTitle() returns a Community Configuration page, not whether $skin->getTitle() returns Special:CommunityConfiguration: that is, consistently on Special:CommunityConfiguration and on the actual MediaWiki message page.

Sorry @Cyndymediawiksim that you ended up assigned to yet another task that is clearly missing some details and decisions. (😇 It's me, hi, I'm the problem)

And thanks for the feedback, @Tacsipacsi. I'll discuss the Figma designs and potential copy with @JFernandez-WMF tomorrow, and then I'll create follow-up tasks. But in an effort to not totally change the scope or requirements of this task mid-sprint, and to get this unblocked, I'm hoping we can move this task forward with @Trizek-WMF's suggestion for now:
View form and View history.

I'll create separate tasks for any other copy changes and the tab/navigation additions once a decision is made.

In T363788#9775382, @Tacsipacsi wrote:

In T363788#9775095, @Sgs wrote:

• The language drop down does not make sense since the user is not viewing a content translate-able page. Also the underlying content, a JSON config, is not translated.

Where do you see this? I don’t see a language selector in the tab bar of https://sr.wikipedia.org/wiki/MediaWiki:GrowthExperimentsConfig.json?useskin=vector-2022.

I'm getting it in my local setup, see screenshot below, not sure why though 😅 . I suggested @Cyndymediawiksim to overwrite it from SkinTemplateNavigation::Universal, eg: $links['variants'] = [];.

In T363788#9782216, @KStoller-WMF wrote:

I'll create separate tasks for any other copy changes and the tab/navigation additions once a decision is made.

Thank you! I think to just scope this task to the two links mentioned in T363788#9782216 and a link back to the form from the config page is the most appropriate at the moment. I find the rest of @Tacsipacsi 's suggestions fair, but better to handle them as separate to keep the scope small in this task so we can finalize it in the current Sprint 13, we have a couple more days.

In T363788#9782729, @Sgs wrote:

I'm getting it in my local setup, see screenshot below, not sure why though 😅 . I suggested @Cyndymediawiksim to overwrite it from SkinTemplateNavigation::Universal, eg: $links['variants'] = [];.

I see, thanks for the screenshot! You don’t have to overwrite it: the variant selector appears only when the page language of the “relevant page” (as set using Skin::setRelevantTitle()) has variants. JSON pages’ page language is always English, and English has no variants unless $wgUsePigLatinVariant is enabled (which should only happen in dev setups). By the way, https://sr.wikipedia.org/wiki/Посебно:Шта_води_овамо/Главна_страна also shows the (there-useless) language selector, because the main page has a page language of Serbian, but https://sr.wikipedia.org/wiki/Посебно:Шта_води_овамо/Медијавики:GrowthExperimentsConfig.json doesn’t show it due to it technically being in English.

In T363788#9783852, @Tacsipacsi wrote:

I see, thanks for the screenshot! You don’t have to overwrite it: the variant selector appears only when the page language of the “relevant page” (as set using Skin::setRelevantTitle()) has variants. JSON pages’ page language is always English, and English has no variants unless $wgUsePigLatinVariant is enabled (which should only happen in dev setups). By the way, https://sr.wikipedia.org/wiki/Посебно:Шта_води_овамо/Главна_страна also shows the (there-useless) language selector, because the main page has a page language of Serbian, but https://sr.wikipedia.org/wiki/Посебно:Шта_води_овамо/Медијавики:GrowthExperimentsConfig.json doesn’t show it due to it technically being in English.

Oh, I see now, thanks for the valuable insight, I just learned about the purpose of the pig Latin variant :). Overwriting is indeed not necessary. cc @Cyndymediawiksim

Change #1026406 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor navigation: add history and edit tab links

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

FYI: Filled T364938: CommunityConfiguration edit links appear at unrelated pages as a regression coming from this task.

Carrying over Elena's comment:

In T365142#9806897, @Etonkovidova wrote:

(3) Special:CommunityConfiguration and MediaWiki:GrowthExperimentsSuggestedEdits.json can be moved/deleted (in the Tools menu). To have Special pages to options to be moved/deleted is somewhat unusual. For example, Special:Recentchanges, Special:Watchlist, Special:Contribute do not have these options. Should we disable Move/Delete options for Special:CommunityConfiguration(and submodules) also?

There is no code to review attached to this task, and there are action items to take a look at, such as Elena's comment.

In T363788#9808321, @Urbanecm_WMF wrote:

Carrying over Elena's comment:

In T365142#9806897, @Etonkovidova wrote:

(3) Special:CommunityConfiguration and MediaWiki:GrowthExperimentsSuggestedEdits.json can be moved/deleted (in the Tools menu). To have Special pages to options to be moved/deleted is somewhat unusual. For example, Special:Recentchanges, Special:Watchlist, Special:Contribute do not have these options. Should we disable Move/Delete options for Special:CommunityConfiguration(and submodules) also?

Creating a new task for this, see https://phabricator.wikimedia.org/T365504 for tracking.