array(2) {
  ["key"]=>
  string(84) "wikipedia-android-strings-year_in_review_highlights_logged_out_en_most_popular_title"
  ["content"]=>
  bool(false)
}

https://github.com/wikimedia/apps-android-wikipedia/commit/d8cfed1a9fdfb414c64805d6660d8adb7a519257#diff-4f3107e8f8105946529b0e7fe586bfa8e09766632fda593f70f0b0867d422f9a

In https://github.com/wikimedia/apps-android-wikipedia/commit/d8cfed1a9fdfb414c64805d6660d8adb7a519257#r169251039, @Nikerabbit wrote:

Translatewiki.net parser does not handle plurals without item elements and this has broken translation updates.

Couldn’t it, at least in message documentation? I always find documentation of plural strings hard to read; splitting documentation by singular/plural just doesn’t make any sense. (Of course, implementing such support doesn’t belong to the UBN work, but in a follow-up.)

I was looking at updating the code to support parsing this and reading the Android developer documentation I don't think its valid to have plurals without items.

As per Android developer documentation: https://developer.android.com/guide/topics/resources/string-resource#Plurals

<plurals>
    A collection of strings, of which, one string is provided depending on the amount of something. Contains one or more <item> elements.

    attributes:

    name
        String. A name for the pair of strings. This name is used as the resource ID.

Change #1200026 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/Translate@master] AndroidXml: Add support for plurals without item XML element

https://gerrit.wikimedia.org/r/1200026

In T408778#11326683, @Tacsipacsi wrote:

Couldn’t it, at least in message documentation? I always find documentation of plural strings hard to read; splitting documentation by singular/plural just doesn’t make any sense. (Of course, implementing such support doesn’t belong to the UBN work, but in a follow-up.)

As far as Translate is concerned, it is possible ar far as I can see to just use <string> in message documentation.

dbrant opened https://github.com/wikimedia/apps-android-wikipedia/pull/6063

dbrant closed https://github.com/wikimedia/apps-android-wikipedia/pull/6063

In T408778#11326710, @abi_ wrote:

I was looking at updating the code to support parsing this and reading the Android developer documentation I don't think its valid to have plurals without items.

I thought if it’s used, it should be valid. If it’s invalid, we shouldn’t support it. I also realized in the meantime that it won’t roundtrip: since the export knows neither what was imported nor what’s the English original, it’ll turn messages that don’t contain {{PLURAL|…}} into <string>s rather than <plurals>es.

In T408778#11326920, @Nikerabbit wrote:

As far as Translate is concerned, it is possible ar far as I can see to just use <string> in message documentation.

If it works, that’d be a good solution. However, the Android documentation isn’t clear whether it’s supported, or whether it causes compile-time issues (probably not usable) or runtime issues (probably usable in message documentation, but not in translations).

In T408778#11327089, @Tacsipacsi wrote:

In T408778#11326920, @Nikerabbit wrote:

As far as Translate is concerned, it is possible ar far as I can see to just use <string> in message documentation.

If it works, that’d be a good solution. However, the Android documentation isn’t clear whether it’s supported, or whether it causes compile-time issues (probably not usable) or runtime issues (probably usable in message documentation, but not in translations).

Yeah, the compiler wouldn't like that. If it's a plurals in the default localization, it must be plurals everywhere.
A good solution will be for us to just write a few more unit tests to catch these kinds of conditions.

In T408778#11327094, @Dbrant wrote:

Yeah, the compiler wouldn't like that. If it's a plurals in the default localization, it must be plurals everywhere.

I feared that. ☹ And what if there is only one <item> (with quantity="other")? If it’s allowed (I guess it is, since there are languages with no plurals at all), you’d have to spell out the documentation only once, and translators wouldn’t have to guess what’s the difference between the two cases. And {{PLURAL}} could be changed not to use monospace formatting in case there is only an other case.

A good solution will be for us to just write a few more unit tests to catch these kinds of conditions.

By the way, why isn’t this caught by the compiler? Isn’t there at least a compiler option that would fail the build?

In T408778#11327156, @Tacsipacsi wrote:

In T408778#11327094, @Dbrant wrote:

Yeah, the compiler wouldn't like that. If it's a plurals in the default localization, it must be plurals everywhere.

By the way, why isn’t this caught by the compiler? Isn’t there at least a compiler option that would fail the build?

Apparently a plurals with no items becomes a lint warning (MissingQuantity), but not an "error" that stops compilation. We could explicitly promote that warning to be an error, but that would flag many other things as nuisance errors. For example, Android encourages certain languages to have one, few, and many in their pluralizations, but numerous strings are missing the few or many case in those languages (due to incomplete translations, or deemed unnecessary by the translators), which will cause the same lint error.

And what if there is only one <item> (with quantity="other")? If it’s allowed (I guess it is, since there are languages with no plurals at all), you’d have to spell out the documentation only once, and translators wouldn’t have to guess what’s the difference between the two cases. And {{PLURAL}} could be changed not to use monospace formatting in case there is only an other case.

That could be a sensible convention to adopt, and would enable a simpler unit test.

Change #1200026 abandoned by Abijeet Patro:

[mediawiki/extensions/Translate@master] AndroidXml: Add support for plurals without item XML element

Reason:

Fixed upstream

https://gerrit.wikimedia.org/r/1200026

From our side, I think sufficient next step for this issue for us would be to convert the fatal error to an exception that clearly identifies the project, language, file (if possible) to make it easier to find and report the issue. This is quite rare issue after all. A possible future step after that would be to gracefully handle this without blocking other projects (some kind of error state).

Change #1203431 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/Translate@master] ManageGroupsSpecialPage: Catch Errors as well

https://gerrit.wikimedia.org/r/1203431

Change #1203431 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] ManageGroupsSpecialPage: Catch Errors as well

https://gerrit.wikimedia.org/r/1203431