resource-summary cannot be translated

[exterkamp]

resource-summary - displayValue cannot be translated because it has text after an ICU plural. Which is not allowed.

displayValue: `{requestCount, plural, =1 {1 request} other {# requests}} • {byteCount, number, bytes} KB`,

It needs to contain all text within the plural content which we can't really do because it becomes nested ICU.

[patrickhulce]

Don't we just split the string in two and join with the dot? :)

[exterkamp]

RTL 😉
{byteCount, number, bytes}. • tseuqer 1

And we can't join multiple seperate ICU's in 1 string the join iirc?

[patrickhulce]

I doubt this is hardly the only case where we combine several strings given the other set of non-nesting requirements though :)

A RTL-aware join seems like that's all that's necessary to solve these cases right now compared to the "it's impossible" state we're currently in, no?

[brendankenny]

I think the main issue is that str_ (or references in general) would have to be taught how to handle concatenated strings since this is in a single displayValue. We could definitely do that (and should probably at least think about feasible ways of doing it for the future), but if it really is just this string, maybe we could just change the string for now?

Also,

it has text after an ICU plural. Which is not allowed.

is an annoying limitation. Surely this comes up a lot? I see

Recommendation: If possible, use complex arguments as the outermost structure of a message, and write full sentences in their sub-messages

in the official ICU docs. Is this a TC thing? It feels a lot like an incomplete implementation and they said "eh, they can always concat".

[patrickhulce]

I think the main issue is that str_ (or references in general) would have to be taught how to handle concatenated strings since this is in a single displayValue.

My way-too-quick-probably-naive thought was that the RTL aware join just returns a new string placeholder that contains a ref to the real i18n placeholder replacements to be made. Doesn't necessary need to be any difference on the structural side (displayValue is still just one string), it just handles chained replacement lookups.

[exterkamp]

@brendankenny and I just tested this and looked around the translation console docs. It seems like:

• string concat is bad in translatable strings
• any characters before or after a plural (or any select) is bad
• nesting is okay (but don't get crazy)

We also just tested using the string like:

displayValue: `{requestCount, plural,
  =1 {1 request • {byteCount, number, kilobytes} KB}
  other {# requests • {byteCount, number, kilobytes} KB}}`,

And it works kinda. The nested ICU replacement is possible, but our custom complex formatting is off, so it seems like this is the translation console preferred way of doing things and is possible for us with some modification.