xliff-comment

Hi,

I'm replying on behalf of Mihai Niță, who wrote the Plural, Gender and Select module.

= = = = = 

> Simple example of ICU message: Anna has invited {g, plural, one {one guest} other {a lot of guests}} to her party.

Those kinds of messages are in general considered bad i18n.
Because in many languages the sections "outside the decision" must in fact change (to agree in gender / number / case).

So there is no intention to support ICU messages where the decision is inside the main flow.
In fact the MessageFormat v2 spec (very close to release) does not provide any way to do that anymore.

The translator would have to translate more, indeed, but they are free to change order, account for agreement, etc.
In general the l10n tools would use some kind of fuzzy match and aleviate a bit the burden of translating more.
With the advantage of less complexity and higher quality.

> I hope you can see the problem. The way how we overcame this problem is that we would create the following segments for a given example:
> Anna has invited {1} to her party.
> (one) one guest
> (other) a lot of guests

This might be very clunky of things must move around and it is in fact somewhat equivalend to concatentenation.

An example:

You deleted {count, plural, one {# file} other {# files}}, very big!`

The Romanian translation is

one    = Ați sters # fișier, foarte mare!
other  = Ați sters # fișiere, foarte mari!

Note the difference in "mare" / "mari" (singualr / plural).

If we create these segments:

You deleted {1}, very big!
(one) # file
(other) # files

then the translator would have to do this:

Ați sters {1}!
(one) # fișier, foarte mare
(other) # fișiere, foarte mari

So they would basically translate "# file" as "# fișier, foarte mare" ("one file, very big"). Worse, the translator would have to know that they can take "pieces" from the main message and move them in the one/other segments.

Worse, if there is another English message saying:

You deleted {1}, very small!
(one) # file
(other) # files

Now the TM leveraging will be wrong, as the "one file, very big" translation can be reused for "# file"

TLDR: decisions inside the message are intentionally not supported, as that is a bad i18n practice. The price is translating more, but with better quality and less complexity.

I understand all your points and they make sense. Unfortunately, they are all "just" recommendations and nothing stops users to put together an ICU message which is considered bad for translation. Hence we have to support both following formats to be translated:

1. Anna has invited {g, plural, one {one guest} other {a lot of guests}} to her party.
2. {g, plural, one {Anna has invited one guest to her party.} other {Anna has invited a lot of guests to her party.}}

The first one is break down to:

1. Anna has invited {1} to her party.
2. (one) one guest
3. (other) a lot of guests

The second one is break down to:

1. {1}
2. (one) Anna has invited one guest to her party.
3. (other) Anna has invited a lot of guests to her party.

We need to be able to merge all parts together to form the same ICU message for both formats. We also support to export any document into XLIFF 2.0 and then import it back but given it is not possible to use it for the 1st format in pgs module, we cannot use it for our case.