Blockly: We need support for plural forms

[gunchleoc]

I am a localizer for the Scratch project, which uses Blockly. There is a string "Delete %1 Blocks" to translate in there, and another "Delete all %1 blocks?". These strings need proper plural forms so that we won't be serving children with grammar errors, but the Scratch developers said that they are building on Blockly code here and can't change it.

[AnmAtAnm]

While this is an entirely valid request, I doubt we can provide an solution integrated into the message template strings for the Scratch timeline. I suggest using two messages and an if statement to select the correct template. I know this solution runs into problems in some languages with more complicated plural grammar than English.

[AnmAtAnm]

In the specific case of DELETE_X_BLOCKS ("Delete %1 Blocks") we already have a singular version DELETE_BLOCK. The dialog for DELETE_ALL_BLOCKS is skipped if there is only one block on the workspace. So for Blockly, in these cases, we never show incorrect grammar (for English). We may need to clarify the translation comments for these messages (the comments already note "an integer greater than 1").

I'm not sure why Scratch-Blocks doesn't behave the same way:

(Mildly related: Sometime the user's count of blocks differs from Blockly's:

I thought this would be the source of problems in light of Scratch's shadow block rendering, but it looks like the first screenshot's count is 1, as a user would expect.)

All that said, if you could identify any Blockly messages that have a plurals problem (ones that actually manifest in the UI), please report them to this issue.

[AnmAtAnm]

Reported https://github.com/LLK/scratch-blocks/issues/1585

[AnmAtAnm]

Marking this low priority given our existing solution does not show incorrect grammar.

[rachel-fenichel]

Our existing solution does not show incorrect grammar in English.

[AnmAtAnm]

It is correct in most languages we support. As noted in https://github.com/LLK/scratch-blocks/issues/1585#issuecomment-397014615, there is a problem in Scottish Gaelic due to multiple plural forms.

[AnmAtAnm]

Apparently Russian and Slavic languages have similar one, few, many pluralizations. See https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_and_Plurals#List_of_Plural_Rules

To be clear, the bigger issue is that getting it right (without introducing more bugs) involves bringing in a proper i18n templating library, and that has a high probability of conflicting with our existing %1, etc string interpolation for block arguments or %{BKY_...} sub-message references.

And then we have the blocks themselves, which may have quantities (and qualities) that change at runtime: "Delete %1 items of list %2".

[AnmAtAnm]

For future reference:
The WikiTranslate pages point to the MediaWiki localization docs for plurals and gendered parameter substitution. I'm guessing this would have to be our starting point, determining how we might pass in initial English messages and receive translations.
MediaWiki uses $ prefixed variables for their substitution functions parameters:

'Box has {{PLURAL:$1|one egg|$1 eggs|12=a dozen eggs}}.'

(Not that I think we can translate block messages and % arguments with such parameter substitution.)

[NeilFraser]

It's also worth mentioning that the language we are producing is stuff like: "if [wall ahead] do [move left]". It's not exactly Shakespeare/Goethe/Mao.

[gunchleoc]

For the blocks themselves, it is not an issue - the user can enter arbitrary number there, and that shouldn't change the name of the block. So, in English, we would still show the plural even if the user enters "1" - that is fine and expected, because it's an input form.

Using the various forms with parentheses does not always work - in this particular case, I can translate "block(s)" with "b(h)loca(ichean)", but it's not always possible to do it that way.

Scratch is being translated into 85 languages, so there will be more languages than Scottish Gaelic and Slavic languages that have a problem - there is also Irish, Welsh, Basque, Arabic... off the top of my head. There might be more that will have a problem.

[rachel-fenichel]

To be clear, our position on this as a team is that it is a real issue, but we are not going to work on it at this point.

We understand that this affects more than one language, but we are a small team and overhauling our translation framework is not realistic.

We're handling translation well for almost all messages for almost all of our languages, with a robust framework for translating the text on blocks themselves (reordering inputs and updating rendering for different language structures, etc).

[gunchleoc]

The input reordering has long been on my personal wish list, so thank you very much for that :)

The reason localizers can get grumpy about this sometimes is that we have to tilt against this particular windmill pretty often, because it tends to get overlooked when i18n systems are being designed. It's one of our most frequent i18n bugs, along with string truncation and hard-coded word order.