I mentioned this task in the talk page of the ptwiki:
https://pt.wikipedia.org/w/index.php?diff=40709919
I think sending an e-mail to e.g. wikitech-ambassadors, commons and wikisource lists too wouldn't hurt.

I think the scope of this task is currently excessively broad. I suggest that we try converting one of the former tracking bugs (e.g. those above, https://phabricator.wikimedia.org/T802#787600 ) into projects if the respective subscribers etc. agree; then assess if the model works and can be extended.

As for localisation, I had the crazy idea the other day that I could offer to watch a project #italiano where users can file reports in Italian and I translate them (as pilot language). A translation service doesn't require consensus, but the pilot would be easier to assess for a smaller language (where you can be sure most people know about it, etc.).

In T802#13333, @Aklapper wrote:

Also see https://bugzilla.wikimedia.org/show_bug.cgi?id=38994 which is very related.

Yes, thank you for cross-referencing this. (Now T40994.)

Personally, I'm happy to try experiments both for projects and for languages. As @Nemo_bis says, the requirement would be strong backing from the project / language community, and known maintainers committing to the task.

PS: ref language, I had the same wild idea and, in fact, I started suggesting it to Amical Wikimedia and other #Catalan speaking wikimedians at the recent Viquitrobada (annual meeting of the Catalan speaking community).

(Turns out some of the ca.wiki contributors are already registered here. Hola! See above.)

For what is worth, I found a related old task: T213: Create projects for tasks whose non-English initial descriptions need translation?

Note that we have Wikidata.org, which is about the website and not the software.

Moving a comment here because the discussion can be applied to any project, not just Wiktionary.

In T75872#795797, @GPHemsley wrote:

In T75872#784137, @Aklapper wrote:

Please elaborate how this tag would be used in Phabricator exactly.

I'm not really sure how to answer that. It will be used to track tasks related to Wiktionary (e.g. T986 and its dependencies). What other information are you looking for?

I might be against fulfilling this request without having a general plan for T802 in place first.

It's not intended to replace any existing wiki-based discussion mechanisms, necessarily. It's meant to be used as a bug/task tracker, as Bugzilla/Phabricator are intended to be used.

The two main risks we want to avoid are

• Tags of Wikimedia project families being created here without any involvement and awareness of the projects affected, probably leading to tags not being watched and maintained.
• Users reporting tasks under i.e. a "Wikipedia" project when they are not Wikipedia specific, only because they found the problem in Wikipedia. This problem aggravates when there are no active watchers cleaning up.

The first problem can be resolved acting upon tags being requested (like Wiktionary now, T75872), checking that there is community support. How that support is registered across different languages I don't know, but I'm sure there is enough people capable of assessing this.

The second problem can be partially resolved by using a more explicit tag, like for instance #Wiktionary-Specific, #Wwwwww-Specific.

Example for tracking bug for French && Wiktionary: T76447

As a contributor of the French Wiktionary, I want to be able to find and organize bugs/requests about both the French Wiktionary (e.g. Extension requests like T73330) and the Wiktionary projects in general, all languages included (e.g. category sorting T30397).

As such I created and T76447 (fr.wikt) and T78531 (All). There may be a better way to arrange things (projects?), but I see both tracking tasks as separate and necessary.

If we are talking here about tracking software bugs, the big majority of them are not tied to a single language. Also, while we have a dozen project families, there are hundreds of project-language combinations.

Since this task includes a possibility create tags for languages, users interested in watching i.e. Wiktionary-fr relevant tasks could still create saved queries for Wiktionary AND French, helping both the Wiktionary and French families by taking care of a specific corner.

Had drafted some comments for T78482, now pasting them here:

I'd be willing to give this a try if wanted by some communities as it's an idea to improve the communication/escalation of requests popular in certain communities towards developers and product mgmt/maintainers. I'd also be very interested in existing approaches I'm not aware of (Community Engagement?), this might not be engineering territory only but also editor and reader territory).

I'd want clear scope definitions for such tags. "happens on Wikisource" is not clear enough. Tagging every ticket in the Extension-FooBar project with a "Wikisource" tag just because Extension-FooBar is installed on Wikisource will only bring noise.

We'll face the usual problems of "measuring popularity" here, something that IMO already failed in Bugzilla with its busted "voting" functionality. Will "5 communities have this on their radar" suddenly influence decisions? I do not think so, hence it should be clearly communicated that if you want something badly you need to argument why instead of only adding a project to a task.

The difference in the UI to tokens or Bugzilla's voting would be that these "expressions of interest" won't be "anonymous" (requiring a click to see the voters or mouse-over to see token creators) but showing names of communities. That also allow interpretations/judgement (size of community? Organization level? Age?). Don't know if that's good or bad and not asking that, just pointing it out.

Naming scheme: Something like "wiktionary-fr" (must be a clear scheme, "site-lang") with its own "community interest" project color and icon?

I will respond with my Wikisource hat on.

To this point of time there has been a broad and shared approach to improvements to Wikisource in the cross-language community. We had one (joint) meetup at Wikimania, not per language. The communities are not excessive size, we have shared visions on numerous issues, be it improving participation, sources, tools, help pages, etc. We do have a couple of predominant communities developing Wikisource help content and having a space to specifically point to the project aspects would have an advantage to the smaller language wikis. In a means we have been undertaking some project coordination at mulWS, and via Wikisource-L, a project tool makes more sense for numbers of components. We have a history of a cooperative approach, and shared success, and sharing skills to new wikis in assisting their set-up. We have seen some language wikis act run pilots, with adaptation by wikis of tools and scripts, and again, this seems something that a project-based approach in Phabricator can nicely emphasise, record, and have an improved approach to proactively share.

We have tracked bugs successfully in bugzilla using the one ticket. I think that (with some guidance) we would look to wisely utilise and tag components, and see that your guidance is relevant across of all of phabricator, not just projects, and training and vigilance, and gentle prodding will make it work fine.

If it comes to subcommunities of WS, I would agree with your suggestion for nomenclature.

I also think that it is better to start creating projects for project families like All-and-every-Wikisource and All-and-every-Wiktionary, and see how it goes before jumping to specific project-language pairs.

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

In T802#784628, @Aklapper wrote:

For example, I've seen the pattern on Bugzilla that bug reporters set the "Browser" field to the browser they were using

In case that having projects for sister projects increases participation in Phabricator, this specific item would probably be less an issue as a second user quickly notes that it's obviously also affecting their browser. Generally it takes me too much of my spare time to reproduce issues on other browsers or under other conditions and I'd be happy if someone else who just experienced the same but with a different system, or under different conditions could add to the task by generalization of the task description (or just adding a comment).

For what is worth, I mentioned this discussion on https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Tracking_project_for_Commons_on_Phabricator

In T802#937886, @Rillke wrote:

For what is worth, I mentioned this discussion on https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Tracking_project_for_Commons_on_Phabricator

Wikidata have a own project, so i think it should be possible for commons too.

In T802#937818, @Qgil wrote:

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

Makes sense. Though still wondering about some suffix like "Wiktionary-community" or such as we already have some ambiguity like the Wikidata codebases/projects vs the wikidata.org website and such. And .org won't work as Commons.org does not exist...

Maybe Wikidata is the exception here, since development and community are so tightly integrated?

I would just try with All-and-every-Wiktionary, All-and-every-Wikisource, Commons, etc, and see what happens. Renaming is easy.

In T802#947035, @Aklapper wrote:

In T802#937818, @Qgil wrote:

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

Makes sense. Though still wondering about some suffix like "Wiktionary-community" or such as we already have some ambiguity like the Wikidata codebases/projects vs the wikidata.org website and such. And .org won't work as Commons.org does not exist...

Why not Wikimedia-Commons or commons.wikimedia.org? (- because " " is not allowed)

Is there any problem with "Commons" for starters?

In T802#950659, @Qgil wrote:

Is there any problem with "Commons" for starters?

I don't think so, for example [[:commons:]] is used onwiki for crosswiki linking to commons,

An aspect to NOT cover here but probably for a followup task once this one is sorted out: All WMF sites for a certain language, like T43348 for Hindi.

Proposed list of projects to start with:

• Commons (T86444, T39883)
• Wiktionary (T75872, T78531)
• Wikisource (T78498, T37925)

Further projects could be created on request and if interest is expressed to follow these projects.
Quoting again:

In T802#789577, @Qgil wrote:

the requirement would be strong backing from the project / language community, and known maintainers committing to the task.

For example I admit that I am very reluctant to create a "Wikipedia" project because everybody might just drop their stuff without reading the description.

Potential future step (just dropping it here): Language level. Existing tracking tasks I am aware of:

• Wiktionary-fr / French (T76447)
• *-ml / Malayalam (T58295)
• *-hi / Hindi (T43348)
• *-ta / Tamil (T34578)
• *-bn / Bengali (T42760)

Great Bikeshed potential!: Full language names with different spelling variants (e.g.: Oriya? Odia?); short versions language vs. country code (e.g. cs vs. cz); Norwegian's no vs. nb vs nn; language and script variants (zh-min-nan vs. zh-yue etc.; sr-latin vs. sr-cyrillic etc.); findability of each concept for task reporters; etc etc.! Not as trivial as it sounds. Just saying.

Initial batch sounds reasonable.

In T802#1062689, @Aklapper wrote:

Potential future step: Language level.

Split into T91286. Please follow up there.

Thank you!

In T802#1105245, @Aklapper wrote:

https://www.mediawiki.org/wiki/Phabricator/Project_management feels like the obvious place for it?

I would prefer not to touch that page with something as specific as this. You could send an email to wikitech-ambassadors sharing the news and inviting other projects to discuss whether they want to join as well. That, and the mention in Tech News that the use of User-notice should bring, are probably enough for now.

In T802#1105647, @Qgil wrote:

You could send an email to wikitech-ambassadors

...and finally done now: https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2015-March/001132.html

In hindsight I think this was a bad idea and should not have been done. See T196740: Rename Wikimedia project tags in Phab (#Wikisource; #Wiktionary) to clarify that they are not about language specific instances?.