On our side: translating all the legal documents can be really tricky for languages that lack a legal writing standard. And it is extremely lenghty.

In T234846#5554690, @Theklan wrote:

On our side: translating all the legal documents can be really tricky for languages that lack a legal writing standard. And it is extremely lenghty.

Makes sense: we have the same standard issue in Breton. Would displaying the Legal information in Spanish (or French) be accepted?

1. There was a specific request during the community discussion, that we should not deploy a new feature where the interface is not yet translated.
2. "only ask for the "optional" translations after all the non-optional things are complete" sounds reasonable for me.

It was deterrent for me that several hundreds of sentences of the privacy policy are untranslated according to the translation tool, while the page is 100% translated. This is a "bug", which is misleading and can demotivate translators.

Or this page shows partly the English original text, while the translation is 100% ready. (Probably a kind of cache problem or similar, and rather a minor issue, but part of the preparation experience.)

Some work has been done about it during AllHands. Since I wasn't there, I let @marcella, @Catrope or @Tgr, who worked on it, provide details.

I think there was some planning but we ended up working on the mentor dashboard instead. There seemed to be an appetite for getting back to this later, though.

I worked on it for a separate request.

Overall, deploying Growth features may request the minimum work from communities: the process should be the same as any other product deployment, and every option should have a default option provided. Community motivation is really important since we rely on mentors.

Possible leads on it are:

• Eligibility
  • not all wikis are eligible. Only the ones with enough activity are eligible, and this threshold have to be defined. this doesn't exclude non-Wikipedias.
  • We need to avoid both newcomers’ frustration when they won’t get a reply and active users fatigue, if they have to handle too many newcomers.

• Translations
  • have everything that requests a translation - even page aliases - being stored on Translatewiki
• Links personnalisation
  • provide help links using Wikidata interwiki links, and provide a way for communities to change them through Mediawiki messages overrides or a JSon file editable by admins/interface admins.
  • have a list of default namespaces based on previous experiences, and provide a way to change them through a config file (no way to change default sensitive namespaces will be provided)

• Mentorship & Help desk
  • existing mentorship lists should be re-used since we assume that these users are ready to help. Don't break these tasks since they may be used by other processes.
  • if there is no mentors list, we fallback on the help desk and invite the community to create a list of mentors
  • define a few ways to have help desk archiving being handled, and encourage communities to use one of them (pending talk pages archiving improvements).
  • If there is no help desk, we fallback to the village pump
• Documentation
  • Everything must be clearly documented on one page, where people would have access to simple definitions of each tool, how to translate its interface and to customize it.

have everything that requests a translation - even page aliases - being stored on Translatewiki

I don't think it's possible for the page aliases to be on translatewiki, but for what it's worth, I don't think it's a problem to deploy GrowthExperiments without the page aliases defined. It just means users will see Special:Homepage in their URL rather than the localized name.

If we can provide communities an easy way to define an alias for Homepage, that's fine.

Translating page aliases on translatewiki is trivial. It won't automagically apply them like it does other translations, but it's still easier than other methods of translating. We could export the results once a quarter or something.
Of course if we decide to not make them translatable at all, that's even simpler.

In T234846#5912076, @Trizek-WMF wrote:

• not all wikis are eligible. Only the ones with enough activity are eligible, and this threshold have to be defined. this doesn't exclude non-Wikipedias.
• We need to avoid both newcomers’ frustration when they won’t get a reply and active users fatigue, if they have to handle too many newcomers.

This seems more relevant for some features than others. Specifically, mentorship and the question poster will tax the wiki community and work poorly if they are not responsive; for something like suggested edits or the impact module, it is unlikely to make much difference.

Concerning Help desks, we have 3 Wikidata items. I suggest to target the following ones by order of priority:

1. Teahouse-like places https://www.wikidata.org/wiki/Q11059110
2. Ask a question places https://www.wikidata.org/wiki/Q5621643
3. Village pumps https://www.wikidata.org/wiki/Q16503

Technical help desks are out of scope, since they are really about technical questions. https://www.wikidata.org/wiki/Q4026300

Here are Wikidata items for Templates used on SuggestedEdits (to be expanded).

Here are the Wikidata items for the "learn more" links for each task:

The experience we have so far (for instance with T249760) proves that the involvement of communities concerning translations is a challenge. We need to figure out how to address it.