Replies: 8 comments 15 replies
-
|
If I recall the previous discussion correctly, we observed that many of the use-cases which potentially suffer from the variant explosion can be simplified by using unit formatting, relative time formatting, or duration formatting. In the example that you share I can see two placeholders that could be handled by duration formatting: |
Beta Was this translation helpful? Give feedback.
-
|
Actually, yeah, unit formatting could indeed help here. That reduces the variant count here to 2^6 = 36, which is still quite a lot but at least somewhat bearable, compared to the starting point. |
Beta Was this translation helpful? Give feedback.
-
|
There is no perfect fix to this. Unit formatting can help. So can special glossary-based formatters. But messages are not always perfectable in this way. I would be really unhappy to recreate a string concatenation engine by using embedded patterns like: The thing I like about the exploded set is that it was easy to teach developers how to write a proper plural; the structure made it hard to do the wrong thing; and the exploded syntax required the developer to spend a long time typing variations (discouraging their use). Some friction here is good. I don't know about Pontoon's design, but I found it helpful to treat each target language option as a segment (translation unit). |
Beta Was this translation helpful? Give feedback.
-
|
Another way to approach this is to make use of custom functions to build localized glossaries of frequently occuring terms. I tried to demo this solution in my experiments/stasm/third branch. The glossary approach requires a localized collection of terms, complete with their grammatical forms corresponding to the natural language and the use-case; and a custom function which can access these terms. In my experiments I used JSON to store the terms (glossary_en.json, glossary_pl.json). I tend to think that such glossaries are good candidates for being localized via a spreadsheet. They don't require any advanced features; they're just tabular data of translations. Then, a custom I would use this approach only in extreme cases where variant explosion is actively hurting the translators' experience (i.e. hundreds of variants or more). The drawback of this approach is that it can make translations too computational (a glossary term for "people", a glossary term for "record", a glossary term for "day", etc.), which results in something hard to reason about. (The primary use-case of this approach was to enable parameterizable dynamic terms, i.e. use an runtime-supplied |
Beta Was this translation helpful? Give feedback.
-
|
I agree that in almost all cases we want to try to avoid concatenation, but I think in such extreme example we shouldn't flat out reject it. My position on "flattening" the selectors from the beginning is that we should be open to add non-flatten selectors later if we accumulate pathological cases that can't be handled by flattened approach. This is one of them. Stas idea of using some sort of glossary may work here, but my concern, based solely on how it worked at Mozilla, is that such scenario may introduce a significant bureaucratic overhead. Introducing terms that are often reused is reasonable (brand names etc.), but introducing words like "clip" and "person" may be less welcomed as it would grow into a dictionary of nouns that had to be pluralized at least once in any more complex sentence. Adding each such noun to a glossary shared in all contexts is likely unnecessary, and building multiple glossaries each for a group of messages that require a given noun seems like a small value over just adding them as messages referenced from the main message, but with its own selector. So, at the risk of strong reaction from this group, I suggest this should be solved with use of message references: If later the term |
Beta Was this translation helpful? Give feedback.
-
|
@zbraniecki Yes and that could be used to solve the closed-set problem. But it's also super common to need to build generic messages in which at least one thing being inserted is open-ended rather than a narrow controlled set of words known in advance. I recall working with a team that was building support for selling auto part installation services as an add-on. The things being installed could be nearly anything--radios, tires, wiper blades--and may or may not come in sets. There were messages much like @eemeli's example that needed parameterization (e.g. We can install your {$num_items} {$item} on your {$car_description} at {$time} on {$day}) We probably all have examples like this and CX designers aren't shy about specifying them in designs. "Better to translate" versions are materially less good/fluent. This is where an NLG solution starts to look appealing (@zbraniecki you will recall our conversations... 😉). At the same time, these are a really small subset of overall messages, I think. I agree with @stasm's comment:
The problem is that we either don't provide a solution or we do. If we do, we need to decide on its shape. Message references can work if languages never have grammatical requirements that break into the message reference. A glossary might be more flexible, but at a fair amount of preparatory cost. And I don't think either solves generic string placement (which I could be okay with???) |
Beta Was this translation helpful? Give feedback.
-
Precisely. it motivates me to encourage factoring out of such nouns as point of divergence where a less sophisticated system will rely on human translation of the components such as |
Beta Was this translation helpful? Give feedback.
-
|
@zbraniecki Assuming the following components exist:
is there anything in the current MessageFormat 2 spec that makes your example not possible? It feels to me that your approach sidesteps MessageFormat and attempts to solve variant explosion in another medium. That's OK, as long as people are also aware of the challenges and have a localization workflow that can handle them:
I did a presentation on Integrity of Message Refenerences back in November 2021 in which I talked about "very local" and "very global" kinds of references which have high integrity guarantees, and a spectrum of things in between that don't. I think it's still relevant here. The presentation then led me to suggesting "phrase aliases" in my original spec proposal, i.e. local patterns (sub-messages) defined and available only inside a single message. This idea was dropped after feedback from CLDR TC; I think it was the right call wrt. to the 2.0 scope. That said, perhaps it would be prudent to check if a similar solution could be added to MessageFormat in the future, taking into account the evolution of the spec since then? |
Beta Was this translation helpful? Give feedback.
-
|
I quite like message references as an answer. However, given our past conversations, I have trouble believing that we could agree to requiring or explicitly recommending them as a part of the 2.0 release. There's also a bug in the original message that's promulgated here as well; the "record" action ought to correspond with the number of people, which could be 1. Would this then perhaps be lifted up as a selector for the whole message? This highlights another challenge in properly translating a message like this: What if the accordance requirements don't match between the source and target languages? Here, for instance, we have at least "is achievable" and "record" as likely points of variance between languages wrt. their need to correspond to the hour & people counts. |
Beta Was this translation helpful? Give feedback.
-
That seems reasonable to me.
I think it's perfectly ok to allow localizations to diverge. I think it'll be challenging for CAT tools to catch up to allow for all of the flexibility, but it brings me back to the idea from the Fluent days of "local messages" which some locales may introduce, while others do not. The fundamental requirement for such system to work is that we would need to allow to mark such messages and ensure that tools are okay with not flagging those messages as obsolete/missing (if en-US has such local message, and french does not or reverse). |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
Within Google we dealt with the combinatorics by disallowing more than one
plural. I think we've only hit problem cases with 2 placeholders, never
more. And there are very few cases that would need even 2.
The downside of that is that it forces the developer to break apart
messages that would take more, and alert translators that (a) the 2
messages would be concatenated with a third pattern, and (b) to avoid
inflectible references from one sentence to another. It is somewhat
awkward, but because it arises so seldom, we didn't want to over-engineer a
solution.
So the problem cases were more like the following:
{ NUMBER($totalHours) ->
[one] { $totalHours } hour
*[other] { $totalHours } hours
} is achievable in just over { NUMBER($periodMonths) ->
[one] { $periodMonths } month
*[other] { $periodMonths } months
}
The developer would fix it by using two different messages concatenated,
and trying to avoid cross references. Example: Message 2
Message 1
The goal of { NUMBER($totalHours) ->
[one] { $totalHours } hour
*[other] { $totalHours } hours
} is achievable.
Message 2
That goal takes just over { NUMBER($periodMonths) ->
[one] { $periodMonths } month
*[other] { $periodMonths } months
}
Message 3 (a sentence concatenation). Typically a space, but
localizable for the language in question.
On Mon, Jan 16, 2023 at 3:46 PM Martin Dürst ***@***.***>
wrote:
… An extremely small correction below.
On 2023-01-16 19:15, Eemeli Aro wrote:
> tl;dr We ought to figure out how to do plurals when top-level selectors
don't work.
> The same message represented in MF2 requires 16 variants, which is
cumbersome, but perhaps at the limit of what's bearable:
> However, when translated to e.g. Welsh or another language that uses all
6 plural categories, this single message explodes to 4^6 = 1296 variants,
which breaks Pontoon.
This should be 6^4 = 1296. 4^6 is 4*4*4*4*4*4 = 4096.
Regards, Martin.
—
Reply to this email directly, view it on GitHub
<#323 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMBVICSJGAODOCV2SJTWSXMVFANCNFSM6AAAAAAT4RY2VU>
.
You are receiving this because you are subscribed to this thread.Message
ID: <unicode-org/message-format-wg/repo-discussions/323/comments/4702004@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
I know that this has been Google's internal policy (and one expressed in public interfaces, such as I agree that the prevalence of multiple replacements is low (IIRC, we measured two replacement strings as something far less than 1% of strings and 3+ were a fraction of a percentage of that). However, over a very large set of UI strings, that's still an appreciable number of uses. When I18N APIs don't provide, the localization team does not always win the conversation with the UI designers and that's when developers get "creative" (== bad). I think we should support (until we can't) arbitrary replacements/selectors or at least a reasonably large number (5 or 10) if we feel the need for a limit. It's not the runtime ability to do the selection that's really the problem. It's the size of the message pattern string's data. Using Eemeli's number (because it is smaller), 1296 * 65-ish characters in his message (not counting syntax) = 81K of data. For one string. In one locale. When faced with this kind of problem, although we allowed deeply nested plurals, we built other mechanisms at the resource level (resource key fallback and other mechanisms that could be used to break up the nestings into separate--but non-concatenating--format pattern blocks) to help address it in a manageable way. |
Beta Was this translation helpful? Give feedback.
-
|
There's a self-fulfilling prophecy embedded in the exercise to use historical data to evaluate future design. We design localization systems in large organizations. Since we do not provide good system nor good tooling to handle messages with multiple selectors, we de-facto enforce a limitation. |
Beta Was this translation helpful? Give feedback.
-
|
LOL. I think I said that:
The relative rarity of multi replacement strings is a bad argument because they are not so rare that developers won't need them. It's also the case that enabling richer messaging leads to more use of rich messaging features. The real kicker, I think, is that rich messages such as the one Eemeli quotes, tend to have high visibility--that's why they need all of the data. There are tons of boring error messages nobody sees that have zero or one replacement 😃 |
Beta Was this translation helpful? Give feedback.
-
100% agree. This observation is important for adjusting our sensitivity to importance of various features in MF2.0 - using share popularity is not a sufficient indicator of importance because the "visibility" and "significance" of complex messages is usually dis-proportionally high. |
Beta Was this translation helpful? Give feedback.
-
|
The purpose of my message is to not to say that we should limit MF2.0 to
only one plural. (And in that particular, Google was just imposing a
limitation on the use of plurals in messages its translation tooling would
take, not trying to impose a limitation on MF1.0). So I fully agree that "I
think we should support (until we can't) arbitrary replacements/selectors
or at least a reasonably large number (5 or 10) if we feel the need for a
limit."
The purpose of my message is to note that any big re-architecture is out of
scope for MF2.0, especially since there are known workarounds for the
(relatively rare) combinatorics problem. We should be refining the spec,
catching ambiguities, and so on — not expanding the scope.
For MF2.0, I want to caution people that we have to be very careful about
conceptual burdens placed on developers and translators. Those can be far
harder to detail with than simply more lines to translate. For example, I
anticipate that unless done very carefully, "submessages" are doomed to
failure. It is difficult enough to alert them to the fact that a message
like "Welcome", or "Insert the disk" — with no placeholders — needs gender
selection; we cannot expect developers to understand the intricacies of
inflection agreement among parts of a message across a hundred languages.
…On Tue, Jan 17, 2023 at 8:00 AM Zibi Braniecki ***@***.***> wrote:
The real kicker, I think, is that rich messages such as the one Eemeli
quotes, tend to have high visibility
100% agree. This observation is important for adjusting our sensitivity to
importance of various features in MF2.0 - using share popularity is not a
sufficient indicator of importance because the "visibility" and
"significance" of complex messages is usually dis-proportionally high.
—
Reply to this email directly, view it on GitHub
<#323 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMFWE3RKGVJZPYSSOETWS262XANCNFSM6AAAAAAT4RY2VU>
.
You are receiving this because you commented.Message ID:
<unicode-org/message-format-wg/repo-discussions/323/comments/4708375@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you Mark for this comment. I agree with your concerns and appreciate your support in keeping MF2.0 scope bound.
Are you implying that, if we enable some form of I agree that the latter is likely, but I am much more optimistic than you about the potential of the innovation we can enable if the MF2.0 system allows for While the route to mature large organization expanding their CAT and infra tooling to enable |
Beta Was this translation helpful? Give feedback.
-
Fully agree. This is actually what I'm trying to ask for here: Not an expansion of the spec, but determining what the recommended workaround is for a combinatorial problem like this, and what actions a) implementers and b) end users ought to take. Summarising what's been covered so far, we have at least:
While each of these can solve at least some of the problem space, they all require action by implementers or other library developers, and some from the message resource spec. It's not reasonable for us to expect all of these solutions to be provided by all implementations, so we ought to prioritise. Unit formatting at the very least is a pretty good partial solution, but which of the others do we recommend when looking for a more comprehensive solution? |
Beta Was this translation helpful? Give feedback.
-
|
Of these 5 approaches, local submessages are different because they’d require changes to the current syntax. Like Mark, I wouldn’t want to expand the 2.0 scope at this point. Instead, I would only like to validate that a potential syntax extension is possible in the future. |
Beta Was this translation helpful? Give feedback.
-
|
Added to the 2023-01-23 agenda per @stasm's request |
Beta Was this translation helpful? Give feedback.
-
|
What I said was "unless done very carefully".
My concern is the concatenation issue. Say developer X is looking at a
message that has number and gender. I'll just show one of those.
[one female] {number...} books can be delivered ...
X thinks, huh, I can pull out {number...} books} into a submessage (with
its different count forms). Effectively, that submessage will need to be
concatenated with the rest of that message. But it turns out that in
language X, the verb needs to be inflected for the number and gender of the
word "books". And even worse, it turns out that the ... part here has an
effect on the 'definiteness' inflection of book.
So when a submessage is extracted, one has to have pretty sophisticated
mechanisms for declaring inflection (and even wording) dependencies, and
resolving all of those dependencies. It will need a lot of work to make
that something that developers and translators and a translation pipeline
can handle.
…On Tue, Jan 17, 2023 at 11:46 AM Zibi Braniecki ***@***.***> wrote:
Thank you Mark for this comment. I agree with your concerns and appreciate
your support in keeping MF2.0 scope bound.
I do, however, disagree with your conclusion:
For example, I anticipate that unless done very carefully, "submessages"
are doomed to failure.
Are you implying that, if we enable some form of submessages they will
have no chance to become useful in the context we described? Or just that
you do not anticipate their use to be utilized by existing large systems
such as Google?
I agree that the latter is likely, but I am much more optimistic than you
about the potential of the innovation we can enable if the MF2.0 system
allows for submessages. I think there is an a massive untapped potential
of the JS ecosystem in building innovative, sophisticated tools and I have
hope that MF2.0, implemented in ECMA-402 will serve as an enabler for that
potential.
While the route to mature large organization expanding their CAT and infra
tooling to enable submessages is many years away, I wish to think of
MF2.0 as a foundational technology that serves that cohort *as well* as
the wild west of web community. I suspect that the latter will be much
quicker in exploring, experimenting and prototyping highly advanced
features that will utilize such features and I am concerned about capping
MF2.0 capabilities based on historical experience of who and how develops
L10n tools.
—
Reply to this email directly, view it on GitHub
<#323 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMC3CB45UWXBOWLQ5ZTWS3ZJJANCNFSM6AAAAAAT4RY2VU>
.
You are receiving this because you commented.Message ID:
<unicode-org/message-format-wg/repo-discussions/323/comments/4710469@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
tl;dr We ought to figure out how to do plurals when top-level selectors don't work.
As a step towards MF2 support, I've started work on migrating the internal data model used by Pontoon to match the MF2 shape, which has lead to this issue: mozilla/pontoon#2703.
One of the projects localized via Pontoon is Common Voice, which at one point includes this UI:
That message uses this Fluent source:
The same message represented in MF2 requires 16 variants, which is cumbersome, but perhaps at the limit of what's bearable:
However, when translated to e.g. Welsh or another language that uses all 6 plural categories, this single message explodes to 6^4 = 1296 variants, which breaks Pontoon.
I think we should have at least some idea how to deal with messages like this in MF2, where lifting the selectors to the top level is not practical. Perhaps implementations should be guided towards allowing a
:plural"formatter" in excessive cases like this? Something like:Beta Was this translation helpful? Give feedback.
All reactions