Adding Phorge for translation?

Adding Phorge for translation?

Some users may known Phorge, a community maintained fork of Phabricator. I think should enable it as seen here.

Cigaryno (talk)19:48, 12 September 2022

I know that, and in fact several translation bug reports that were sent to Phabricator were rejected (since they come the earlier version inherited from Facebook (when it abandonned that project) and sent "upstream" (because they were not used by Wikimedia) but without a real upstream maintainer. Phorge has taken the hand on these unused modules, creating its own fork (more or less synchronized with Wikimedia Phabricator for some modules but not completely, so there are now differences).

I think that both Wikimedia and Phorge should cooperate to have a set of common modules maintained in a "Core Phabricator" part, even if there are Wikimedia Phabricator-specific modules and Phorge-specific modules: splitting PHabricator in three spearate groups would help and would void duplicate efforts from both Wikimedia and Phorge, and there should be a joint working group to see how they will reconverge their versions on the common modules that will be part of "Core Phabricator ".

Today Phabricator is very large, and difficult and long to translate, even if there has been efforts to modularize it (just like there were efforts for MediaWiki extensions, and joint working teams for other large wiki providers like Miraheze, or even Fandom, the new name of Wikia that is no longer supported here, but Fandom now operates with its own proprietary licences and does not want to cooperate; may be they should revize their decision, because I doubt they will even be able to track all issues alone, and their operational costs will increase and even their hosted communities have difficulties to work with their official support, that is very slow to react and solve problems, or cannot supprot as many languages than those supported in standard MediaWiki).

Creating joint efforts has a price: the main one is related to licencing issues, but modularizing projects would allow better convergence on the most core components that should be maintained in a single open project, without duplicating most efforts (notably for translations to "minority" languages: joining efforst would allow better reviewing with more contributors, not necessarily tech-savvy, so it would also improve the overall quality for everyone).

Consider how ICU evolved: from a project maintained by IBM alone, now maintained in a more open project at Unicode, it starts being more useful and now largely used in other I18n projects, but it is still slow and there are still considerable optimizations to implement so that its submission and vetting process works more reliably on smaller devices, but as well to have the serverside components work faster. This means going to "continuous integration" (at least in a "development branch", even if there are yearly major upgrades with stabilized branches and some backports). Due to the growing cost of maintenance of ICU, now Unicode has placed all its maintained code in Git (where multiple branches are possible and integrable. This should finally work like other large projects (like Linux kernels or LTS distributions running along with rolling releases)

Verdy p (talk)06:43, 13 September 2022