Page MenuHomePhabricator

Consider creating Phabricator projects for Wikimedia sites in specific languages
Closed, ResolvedPublic

Description

Split from T802 (and not sure it's a good idea, read that entire ticket first please):

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.

On language levels, existing tracking tasks I am aware of:

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.

See also: T213: Create projects for tasks whose non-English initial descriptions need translation?

Related Objects

Event Timeline

Aklapper raised the priority of this task from to Lowest.
Aklapper updated the task description. (Show Details)
Aklapper added a project: Project-Admins.
Aklapper added subscribers: Aklapper, Qgil.

For now I added the fr.wiktionary task T76447 in a column "Language specific bug tracking" in the new project All-and-every-Wiktionary.

I think before considering "Phabricator projects for Wikimedia sites in specific languages" we should consider Phabricator projects for languages. Let me compile here the relevant quotes from T802:

From the description:

  • Localization step 1. As of today, Bugzilla and etc are English-only tools, but only the simple fact of having editable descriptions provides an opportunity to be more flexible. What if a user would be able to file a task in French for #fr.wikisource.org (and/or #French All-and-every-Wikisource, another detail to be defined)? Then the contributors watching these projects could help triaging the task in French for that user, and translate to English if there is a valid new bug.

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.).

And there is the related T213: Create projects for tasks whose non-English initial descriptions need translation?

Qgil set Security to None.

Anybody opposing to the idea, or are we just waiting for the first candidates?

Is the interface of Phabricator only available in English? Because as long as it is, I don't see any non-English speakers writing tasks anytime soon, even in their own language.

Even so, I think that non-English speakers (or any non-tech people) who want to report bugs will first report it in the dedicated tech page in their wiki (I believe most wikis have such a page, e.g. Questions techniques on frwiki). The tech people on those sites would then likely create tasks in English for the reported bugs.

Phabricator can be localized in theory, but in practice I believe a multilingual Phabricator is mostly uncharted territory. For some background, see T225: Use translatewiki.net to localize Phabricator.

I think there is a reasonable difference between users that have no clue about English and users that could understand the English UI and help docs, but won't feel confident writing a task or a comment in English.

On the other hand, I can image e.g. existing projects handled else where in languages other than English, run by wikimedians having no problem understanding the English UI, but preferring to keep discussing in the natural language of their projects.

... Anyway, I think we have a good representation of opinions about why this should not be actively pursued. I'm fine considering this task Open, Stalled, Lowest until someone comes with a specific project proposal relying on another language.

I'd appreciate input on the bikeshed section in comment 0 here before creating projects on request, basically. Renaming projects is cheap but a bit more of a basic plan would make me feel better.
For example, "Is fr.wiktionary as findable via project typeahead/obvious as wiktionary-fr" etc.

Since Wikimedia projects are already organized in languages, I don't think we would need to repeat whatever bikeshedding they faced when creating those projects... Or am I missing something?

But I insist that I don't think we should approve Wiktionary-fr before having a clear idea about a generic #French project.

I think that both styles would be useful. Some tasks affect all Wiktionaries; some tasks affect all French projects; some tasks affect only the French Wiktionary (e.g., config requests). A comprehensive set of tags will cover all of those cases.

About the naming: I just proposed to create "Wiktionary-fr" (T101948). This naming schema seems the most logical to me:

  • it shows its hierarchy (subproject of All-and-every-Wiktionary), like other projects, e.g. Toolforge / #Tool-labs-tools-anagrimes
  • it is the easiest to find with autocomplete: everyone searching for specific fr.wiktionary bugs will try to write "Wikt" first, which will offer All-and-every-Wiktionary and the other "subprojects".

So the naming schema would be (based on the url of the website) :

#ProjectName-LanguageCode
Wiktionary-fr
#Wikipedia-de

I'm not sure there is a demand for language projects like #French, but in that case I would recommend a name like :

#Wikimedia-Projects-LanguageCode
#Wikimedia-Projects-fr
#Wikimedia-Projects-de

In the lines of T97273: Simpler process for Phabricator project creation, if Wiktionary-fr is the first community requesting a project/language pair, I would allow for some experimentation and create it. Then, if/when a second request comes, we can check how wiktionary-fr is doing, and based on results we could just accept a second or give them a bit of a harder time with questions if the first case didn't work well.

I still think we would need to have some basic requirements, like for instance a link to a thread in the related community forum where the proposal is discussed and accepted. This is pretty much standard for similar tech processes.

Now that T213: Create projects for tasks whose non-English initial descriptions need translation? has been decided, what about trying to decide on this task as well during this quarter (by the end of September)?

Now that T213: Create projects for tasks whose non-English initial descriptions need translation? has been decided, what about trying to decide on this task as well during this quarter (by the end of September)?

Yes. But before I would welcome evaluating T802: Phabricator projects for Wikimedia sister projects: Are the requesters of those 3 Phab projects content how the projects are used; does it help them to organize work / keep an overview? Or what to change?

As far as I understand two distinct topics are mentioned here:

  • having languages subprojects for community project (such as wiktionary-fr);
  • having specific language projects.

The first one seem already resolved. For the second, there even more shade to focus on:

  • tagging thread were users are speaking in a given language (possibly except for English, if no one mind the phabricator instance to be an English-speakers centric tool);
  • having a way to follow any project/task/etc. related to a specific language whithin Wikimedia, wherever the community it emerged from/for.

That was the last one I had in mind when suggesting T106974. But now Esperanto woud looks a better name for the former. Of course a more accurate choice would be 'Esperantskribita' (written in Esperanto). But that would lead to other questions, like

  • do we want English name only for projects names?
  • can we make alias to translate project names?
  • do we want to enable users to have a whole "thread" written in something else than English?

That last point would certainly be relevant as long as it doesn't require any intervention of someone who don't speak the thread language. Moreover, in case the thread lead to such a case, a new task can be filled with reference to the previous one. If needed, a task could be opened to translate messages of the previous task.

Now let's go back to having a way to follow any project/task/etc. related to a specific language whithin Wikimedia, wherever the community it emerged from/for. Here is a concrete example: I'm interested in making contribution in Esperanto within all Wikimedia projects. Currently I plane to focus on enriching Wikiversity, so the esperanto version could move from beta to eo.wikiversity.org. (So far I had positives feed back from existing university contacts which are using Esperanto as working language.) But I'm also interested in helping improve other projects. For example, through the recent campaign targeting French speakers as part of the Research:Increasing article coverage. While I surely can (and do) help with the French Wikipedia, helping the Esperanto version is currently more appealing to me: I improve my level in the target language, there's far much more to do, there's a working Machine Translation which is working pretty well to help in the task (while there's nothing at all for French). So having a list of translation task for eo.wikipedia within phabricator, with priority and so on, could be fine. Now I happen to also be interested in philosophy, and I think that esperantophones should have opportunity to read classic works in the field. So I would be happy to learn that there is an ongoing translation of
De rerum natura to Esperanto on Wikisource, and I could help.

Of course, I could also follow the miscellaneous Project-eo that may be otherwise created, if done this way.

Now there is an other case which wasn't yet raised: when someone want to stay informed of studies performed on a given language within Wikimedia. For example I have a research project on Wikversity were I study French language lexemes, while improving the wiktionary at the same time. You may say that it's a cross project. Surely some people interested in the French language may be interested in such a project, while this same people won't be interested to follow every Wikimedia community of this language.

And last but not least, that kind of project could help to federate teams around specific languages, as well as ease to find people skilled and interested with them.

Any feed back, regarding my previous comment?

If the volume of activity for a language i.e. Esperanto is going to be low, then a tracking task like the ones described in the description above can keep you going while this task is resolved. I don't see a big difference between a tracking task for "wikipedia-eo" or "Esperanto", whatever works for you.

  • do we want to enable users to have a whole "thread" written in something else than English?

This is a completely different topic that requires its own task (is there one already?) because it has deep and wide implications on the future of this instance.

But before I would welcome evaluating T802: Phabricator projects for Wikimedia sister projects: Are the requesters of those 3 Phab projects content how the projects are used; does it help them to organize work / keep an overview? Or what to change?

I have no good concept how to approach such an evaluation - probably creating a dedicated task (to block this task here), CC everybody who is a member of the 3 Phab projects, and ask them for their experience so far whether these Phab projects are helpful, and which aspects / behavior they consider problematic for organizing work in these Phab projects?

As far as I understand two distinct topics are mentioned here:

  • having languages subprojects for community project (such as wiktionary-fr);
  • having specific language projects.

The first one seem already resolved.

I don't think so: The first one is what this very task is about.

  • tagging thread were users are speaking in a given language

If I get you right, we decided in T213: Create projects for tasks whose non-English initial descriptions need translation? that this is not needed currently.

  • can we make alias to translate project names?

Projects in Phabricator allows secondary hashtags which are for example supported by Phabricator's Search. For example if I write "ECT" in a "Project" field it will also offer "Engineering-Community" as ECT is a secondary hashtag of "Engineering-Community". But really depends on how you want to use such aliases and what your expectations on displaying them are.

So having a list of translation task for eo.wikipedia within phabricator, with priority and so on, could be fine.

If I understand it right, I must express I'm afraid of creating a potential divide between organizing such on-wiki content work also on-wiki where the people are, instead of in another tool. And I'd love to be proven wrong.

Now there is an other case which wasn't yet raised: when someone want to stay informed of studies performed on a given language within Wikimedia.

I'm missing how this item is related to a potential future Phabricator project.

If I understand it right, I must express I'm afraid of creating a potential divide between organizing such on-wiki content work also on-wiki where the people are, instead of in another tool.

...and some of the points brought up in T31923#1574767 (fragmentation of content, duplication of effort) might also apply here.

Aklapper raised the priority of this task from Lowest to Medium.Dec 20 2015, 8:24 PM

I closed T111046 with the result that T115017, T234 and T89865 would potentially make maintenance (reducing the number of incorrectly filed tasks) of such projects easier.

I don't see a strong need to express hierarchy because the dash is recognized by the tokenizer in the Projects typeahead. But as Phabricator has a flat project namespace, I still propose a naming scheme:

  • "Language-WikimediaSite" (like "French-Wiktionary") for specific sites in a specific language
  • "Language-Sites" (like "Oriya-Sites") for any Wikimedia sites in a specific language. (Was tempted to propose "*-Wikimedia-Sites" but Phab is about Wikimedia hence hopefully unneeded.)

We could always add project name aliases like "Odia-Sites" for "Oriya-Sites" if really wanted.

Such a scheme would also not collide with chapter projects like Swedish WMSE-Communication or Ukrainian WMUA-WLM-2015.

I'd prefer to document this by one sentence on https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects under "Come up with a good name", like: "Projects of Wikimedia chapters and projects of certain language communities should follow the naming scheme described in T91286".

I looked around but didn't find any decision about the language of tasks created for such projects. Was there any consensus about allowing/disallowing non-English tasks?

In T91286#2075012, @Tgr wrote:

Was there any consensus about allowing/disallowing non-English tasks?

No. :)

Restricted Application added a subscriber: jhsoby. · View Herald TranscriptAug 13 2022, 1:54 PM