Re: [Translation-i18n] xtensa message pluralization

[Bruno Haible <bruno at clisp dot org>]

Alan Modra wrote:
> > there isn't an "nngettext" to give you the correct message for the plural based on more than one value.
> 
> ... The translation project is going to be
> faced with sentences that really do need two or more pluralized nouns
> for the sense to be conveyed naturally in English.

The former gettext maintainer's usual answer to such a request is:
  - Such an nngettext function would be overkill for a rarely used case.
  - You can usually either split the sentence into two sentences (that
    can be translated separately), or even get rid of one of the plural
    forms entirely.

> Avoiding two
> plurals in one sentence will mean loss of information (eg. dropping
> "bytes" from a quantity) or stilted contrived sentences.
> 
> To recap, the sentence we are talking about here is:
> 	"format '%s' allows %d slots, but there are %d opcodes"

You can turn it to:
    "The format '%s' allows %d slots."
    "But there are %d opcodes."

Or omit one of the plurals or even both plurals:
    "Mismatch for format '%s': #slots = %d, #opcodes = %d."
Admittedly this is not so pretty, but in tabular displays this is how
numbers are often printed, so that plural forms don't appear at all.

> In both cases the
> "slots" phrase translation can't depend on the quantity in the
> "opcodes" phrase translation, and vice versa.

Correct, and this is acceptable. You don't have to care for hypothetical
dependencies that _may_ exist between hardly related entities.
Take as model some language like French or Latin (with more grammar
than English), where
  - the variant of the verb depends on the gender of the subject,
  - the variant of the verb depends on the number of objects,
  - but otherwise sentences are unrelated.
If you can split something into separate sentences in English, you
can assume that this will work in other languages as well.

> So, abbreviating F for format, S
> for slots, O for opcodes components, a translator could arrange to
> emit FSO, SFO, OFS, OSF, but not FOS or SOF.

Given the English sentence (where the statement about the opcodes is
separate), it sounds unlikely that a translator would want to use the
order FOS or SOF.

> There is also the issue of other messages that may share "%s but %s"
> construction in the future.

Yes, but this issue can be handled through contexts [1].

Bruno

[1] https://www.gnu.org/software/gettext/manual/html_node/Contexts.html