Page MenuHomePhabricator

Consider to have links used in Growth features as standalones being treated as local configuration more than translations
Open, Needs TriagePublic

Description

Context: T270250: [WelcomeSurvey] Links on the "Getting started" module are in English, hence creating redlinks. The fix was to update translations on translatewiki. It was not really natural.

Have one page where all the configuration for our features are listed would be a better way to ease communities' work on getting the features. We have this for Newcomers tasks: MediaWiki:NewcomerTasks.json.

Have such config file allows a quicker updating process: communities can immediately change something without waiting for the train to ship all translations and deliver them (which can take up to one week).

Of course, if the link is within a blob of text, this suggestion doesn't applies.

Event Timeline

Trizek-WMF renamed this task from Consider to have links used in our treated as local configuration more than translations to Consider to have links used in Growth features as standalones being treated as local configuration more than translations.Jan 5 2021, 6:50 PM
Trizek-WMF updated the task description. (Show Details)

I don't have much to say on this scaling tasks. Generally speaking, this sounds like a good idea. It would allow communities to change the links on the go rather than having to go to translatewiki (or us to do a server config change). However, while it indeed does make it easier for communities to self-manage, at the same time it probably makes Growth tools slightly harder to deploy en masse.

Right now, when we want to deploy our tools to wiki, we need to pre-populate MediaWiki:NewcomerTasks.json on-wiki, so the features work in some way. That requires fairly high global privileges (either global interface editor global group, or staff global group). Right now, this is something only @Tgr has. Even if this permission would be granted to multiple engineers on the team, it would still mean we would have to make an edit on each wiki we upload the wikis to. Right now deploying to a wiki is a lot of manual work anyway, but that's something we want to fix, not introduce new bottlenecks.

That means we have an open question: How are we going to pre-populate on-wiki configurations with dozens of wikis? It doesn't scale to make it by hand every time. I'll add it as a blocker, and fill it as a separate task.

Translatewiki is really bad for this since it means multiple wikis in the same language will have to share settings. Those configuration fields should be migrated to on-wiki JSON instead.

The longer-term solution will be to provide a custom user interface for the JSON file so it can be filled out in a web form with help text and whatnot. I thought we had a task for that but apparently not; it's discussed in T246939#5977311 though.

Translatewiki is really bad for this since it means multiple wikis in the same language will have to share settings. Those configuration fields should be migrated to on-wiki JSON instead.

Agreed.

The longer-term solution will be to provide a custom user interface for the JSON file so it can be filled out in a web form with help text and whatnot. I thought we had a task for that but apparently not; it's discussed in T246939#5977311 though.

That's even better than what I proposed at T274017: Link docs in an editnotice displayed when editing MediaWiki:NewcomerTasks.json. If we don't have a task for that, please create one!

@Urbanecm_WMF this can be resolved, right?

I don't think so. The tutorial/help desk links in welcome survey are still controlled by https://translatewiki.net/wiki/MediaWiki:Welcomesurvey-sidebar-editing-link1-title/cs and https://translatewiki.net/wiki/MediaWiki:Welcomesurvey-sidebar-editing-link2-title/cs, which looks like what @Trizek-WMF was complaining about.

It should be much easier to resolve it though -- we already have a proper config variable for help panel (although many wikis don't use it). We ditched the variable for tutorial though (T289109). Once we have a variable for both, it should be trivial to change welcomesurvey to source them from on-wiki config.