Filing this task to track that plan downstream.
Prior noise at https://secure.phabricator.com/T5267.
In any event I can't really do this until Wikimedia Phabricator pulls in the next upstream.
I may end up writing a direct PhabricatorArrayFFS class in the Translate extension and ditching the custom janky wrapper code in this process. Or I may end up keeping it and telling it to produce different output.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Pppery | T412650 Update phabricator translations for upstream i18n changes | |||
| Open | Pppery | T411837 Support PLURAL in a more reasonable manner in Phabricator translations | |||
| Open | Pppery | T412421 Export source strings with PLURAL where appropriate | |||
| Open | Pppery | T412422 Support languages with nonstandard PLURAL rules | |||
| Stalled | Pppery | T412423 Write a validator to ensure that PLURAL on translatewiki.net is written in a way Phabricator can understand. |
I may end up writing a direct PhabricatorArrayFFS class in the Translate extension and ditching the custom janky wrapper code
There has to be some wrapper code, because the upstream native output format (i18n_strings.json + PhabricatorUSEnglishTranslation) isn't something that can reasonably be read by MediaWiki. The biggest problem with the wrapper code is how to handle PLURAL. Ideally I would use some FFS that already had non-inline PLURAL written out, so I don't have to steal the MediaWiki code that handles non-inline PLURAL.
Actually maybe JSON already supports that. I need to understand how that code works better.
Translatewiki.net's validator system may have made doing it right impossible - I haven't checked since I'm sure nobody tried.
It didn't. And it turns out that a few translators actually made use of the janky plural functionality. But most didn't and its existence is kind of extremely well-hidden.
I also discovered that a few translators used Russian plurals which has its own system which isn't properly supported. Another thing to understand and deal with. Probably I should just write it into the locale file in rPHTR, but pie-in-the-sky I would make Phabricator Translations depend on CLDRPluralRuleParser (or maybe Leximorph once T390289 happens). But then I'd have to deal with Phutil libraries not supporting external dependencies well.
Also Translate's built in CLDR array-plural support is not helpful at all here because, among other things, it only supports one thing to PLURAL off of and Phabricator has a few messages with multiple such things.
I have two options here - one is write my own inline PLURALer, the other is try to write out an array format and my own custom code in Translate to deal with. I think I'll go with the former.
[... and then there's the issue of explicit plural forms like {{PLURAL:$1|$1 foo|$2 foos|12=a dozen foos}} which MediaWiki plural (and the validator for it) supports but Phabricator array format can't really. I'll probably have to write my own PhabricatorPluralValidator class in MediaWiki to validate that the (existing) code in rPHTR to decode PLURALs gives a reasonable set of arrays ...]
... but Phabricator's existing code doesn't support nested PLURAL either.
I'm so close to perfection, but every time I think it's near I discover a new broken thing. I'll get there eventually, and be proud of this project, I promise ...
(Of course, it doesn't need to since you cal PLURAL separate disjoint segments. So to conclude all of this I definitely need a PhabricatorPluralValidator in the Translate extension but nothing else is fundamentally broken.)
(Splitting the three distinct concept I've been dealing with here into their own tasks)