Page MenuHomePhabricator

Document deployment process for Growth features
Closed, ResolvedPublic

Description

We need to document the way that we deploy the Growth features to new wikis. @Tgr is going to draft this as he deploys to Bengali Wikipedia.

Event Timeline

wikitech:GrowthExperiments setup (findable via How-To#Wikifarm and Category:How-To).
(Not sure if mediawiki.org would be a better place - wikitech is usually more devops-oriented but but that's where we tend to store information related to Wikimedia config.)

Two parts are missing:

  • Identifying / backporting missing l10n. There is some script for this but I couldn't remember the details.
  • Checking if there are 500 articles per task type. Not sure if this is done for all deployments; I remember Roan doing it a couple times. This can be done manually via Special:Search but maybe Roan has a script for it already? Otherwise, I can write one.

@Tgr Let's not backport i18n strings (_including_ .aliases.php) unless it's really really urgent, as it requires scap sync-world, which can take over an hour easily.

For identifying missing strings, there's https://watch-translations.toolforge.org/, which can be used by a bn speaker/managers to watch over completeness of the translation of the extension. It processes only TWN-managed translations, and it ignores stuff like aliases file completely.

@Tgr Let's not backport i18n strings (_including_ .aliases.php) unless it's really really urgent, as it requires scap sync-world, which can take over an hour easily.

I think the current text says that already.

For identifying missing strings, there's https://watch-translations.toolforge.org/, which can be used by a bn speaker/managers to watch over completeness of the translation of the extension.

That's great for translators / ambassadors, not that useful for developers, who need to know how much of the translated strings will actually work after a deployment (ie. how much of the TWN content has been already exported to core).

@Tgr Let's not backport i18n strings (_including_ .aliases.php) unless it's really really urgent, as it requires scap sync-world, which can take over an hour easily.

I think the current text says that already.

I was referring to "Identifying / backporting missing l10n" from your original comment -- sorry for not making it clear.

For identifying missing strings, there's https://watch-translations.toolforge.org/, which can be used by a bn speaker/managers to watch over completeness of the translation of the extension.

That's great for translators / ambassadors, not that useful for developers, who need to know how much of the translated strings will actually work after a deployment (ie. how much of the TWN content has been already exported to core).

I see. https://github.com/urbanecm/growth-verify-translations/blob/2199fa9f6e2d7ebe6b05c96d14b10eb86f7e0ba3/verifyTranslations.py can be easily modified to work for wmf-deployed branches.

(no code to review, moving to In progress)

The documentation should be reviewed though.

What does (Placeholder for adding tables. This is not needed today, but by the time this page is next used, it probably will be.) mean in the documentation?

Link recommendations will involve some database tables, which will have to be created for new wikis once that feature is live.

Ah, that makes sense. Given the bulletpoint is a sub-point for "Deploy the config change in a backport window.", I somehow thought that refers to the deployment procedure (or the Deployments page), which is what confused me.

  • Identifying / backporting missing l10n. There is some script for this but I couldn't remember the details.

The way I recommend doing this is:

  • Add the language code of the new target wiki to the requireCompleteTranslationLanguages array in Gruntfile.js
  • Run grunt banana:translations (in master or in the currently-deployed wmf branch, depending on how soon you plan to deploy)

The output of this script is not ideal, but it's workable. Languages are listed multiple times, once for each i18n subdirectory, and they're not grouped together (the grouping is by subdir then language). It also complains about missing translations for messages that are optional and don't have to be translated, but there aren't very many of them.

I'll add this to the documentation page.

@Catrope -- is the above your only/final feedback on the documentation?

@Catrope -- is the above your only/final feedback on the documentation?

I also made a number of edits and additions to the wiki page. As far as I'm concerned, it's now done. @Tgr may want to review my additions.

Thanks @Catrope!
I don't think QA/PM review makes sense here so let's just resolve it.