Handling correspondence with related messages

[747]

Hi, I recently discovered this project and find it quite promising. As it focuses on natural-sounding translation, I'm curious whether it can handle the case that a message has different translations according to another message used together, on the translator's side.

A possible use case is such a dialog below:

Are you sure to close the window?  [ Yes ] [ No ]

where some languages don't have exact words for "Yes" and "No", so that they should be most naturally stated as if in English:

Are you sure to close the window?  [ Close ] [ Don't Close ]

and the verb obviously needs to be changed along with the question.

So far I haven't found a way to achieve it without coder's intervention. Is it currently possible? If not, is it implementable? Of course, the source string should be WET, but in such a case I suppose devs won't even likely imagine that it could break down to multiple notions in another language.

Another possible use case:
Japanese has (and only has) one general word for creatures making their characteristic sound, thus the developer gives a single source string:

action = { $animal }がなきます。

where $animal takes finite options, say [cat, mouse, dog, duck, human]. But in English you have to translate each differently as:

A cat meows.
A mouse squeaks.
A dog barks.
A duck quacks.
A human cries.

[macabeus]

I think that you can resolve both cases using selectors.

For instance:

# jp
action = { $animal }がなきます。

# en
action = A { $animal ->
  [cat] cat meows.
  [mouse] mouse squeaks.
  [dog] barks.
}

[Pike]

So, for the first issue, you could have a term for -dialog-button-yes, and use a term reference in each dialog instance. Then a localization could do

-dialog-button-yes = Yes
  .close = Close

There are caveats about this detailed in https://discourse.mozilla.org/t/on-message-and-termreferences/53217.

For the solution for the second case probably falls more in the realm of dynamic term references. The proposal @macabeus made has challenges that dynamic term references face as well, the interface of the message isn't language-dependent, but intended to span localizations. Which SelectExpressions aren't intended to be.