-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We should not require *
if the variant keys exhaust all possibilities
#603
Comments
We argued on this one to the death before. There are good reasons to have a default, and we had some kind of agreement on this for months (years?).
We know that not all tools will have access to the registry. And even if we do, there are the cases where that does not scale (because there are too many values). It also means that for everything that might have some kind of "catch all" option we will have to define that in the registry (think Then the selection algorithm needs access to the registry, at runtime. |
The actual proposal here is related to this line the syntax specification:
This is the only place where the the catch-all is required. The errors part of the specification defines the "Missing Fallback Variant" error, but it is not referenced anywhere else, which is probably an error. I do think that multiple selectors make this issue more complicated. The current requirement guarantees that all messages with a matcher will produce a pattern to format. Relaxing this requirement would make it possible to have syntactically valid messages that produce a runtime error (currently undefined!) in which the matcher does not match any of the variants. An argument can be made that the syntactical requirement for
Also, I note that there is nothing necessarily wrong with the following message, except it is inelegant and lacks some parsimony:
|
I have a real example where it was not possible to cover all options. It is about French plurals, which changed a few years ago to include So we had thousands of strings in many products that had only When CLDR added "many", things continued to work, because all of them had the mandatory "other" It took a while to fix things (and there might still be unfixed cases here and there :-) This also impacted outside:
If we assume that we can have a comprehensive validation and remove the mandatory fallback, If we thing about browsers, which get updated pretty often, we would suddenly break applications that did nothing wrong, they passed all validations (at the time when they were translated), and worked for years. Not updated as often as browsers, but CLDR is also used by Windows, macos / iOS, Android, others. I agree with Addison that "might hide other problems with the matcher" If people use proper lint (as this issue assumes), then the situation will not be hidden for long. |
So let's not fail selection then for plurals, if an
In other words, it is perfectly plausible for e.g. a French plural selector to be given a list of keys Expanding a list of required keys would need to count as a breaking change, which we probably cannot do, for the reasons @mihnita explains above. |
One of the previous arguments about this was: We would prefer not to have to call functions to find out if a message is valid. If we accept this proposal, the only way to know if a set of variants has sufficient closure is for the implementation to call functions or read the registry. Note that "implementation" here can mean tools or even people writing messages. Requiring the I think accepting this change ought to include removing the requirement for the "all fallback" variant from "validity" constraints (putting the onus on authors/tools to avoid "Missing Fallback Variant" errors). We document briefly why we didn't chose making I could accept making It occurs to me that this is something that could benefit from the beta period. Whichever route we choose now, we should explicitly ask for feedback about the consequences of the choice. If we allow non- |
In the 2024-01-29 call we decided:
|
Dropping the |
This seems much harder to do now that the registry is optional. E.g. in the example, without a registry, there's no way to check that |
I'd go further: it might be impossible because the spec has the matching algorithm adding the |
This is still just as possible as always:
Not requiring the But on the other hand it also allows for messages that have more semantically meaningful variant keys, like The validation problem we've left outside the scope of the MF2 spec, as we do not define a machine-readable registry, but this doesn't make it impossible, it just requires an implementation and a linter to define separately how they communicate about function interfaces. |
I see, yes -- I think what threw me off is the issue title. Without a way (within the scope of the spec) to check if the variant keys are exhaustive, the proposal becomes just "We should not require |
Do we want to re-open this for 46.1 or seek feedback (post 46.1) for 47? |
As with #602, this is an issue for which external input would be useful, and for which we could/should explicitly seek feedback. |
This was discussed in the 2024-10-14 teleconference. We rejected this proposal for the 46.1 timeframe. We are leaving intact the desire for feedback during the TechPreview period. |
As currently specified, we require at least one variant of each
.match
message to have only*
keys. Otherwise, we consider the message to have a Missing Fallback Variant data model error.This requirement ensures that no matter the case, selection on a valid message will always produce some explicitly defined pattern.
It is however possible to define selectors such as
:plural
or:boolean
for which the presence of some set of keys guarantees that selection will succeed, such as['other']
for the former and['true', 'false']
for the latter.If we were to make the current error a runtime Selection Error like "No Variant Selected" instead of a Data Model Error, it would allow for more natural messages, such as:
instead of our current
With access to a registry definition, it would still be possible to validate messages for completeness.
An outline of the changes required for this are available in #560 (comment).
I'm assigning this to @stasm, as he mentioned this topic near the end of today's call, and I just wanted to be sure we had an issue filed on this. Please feel free to take over here.
The text was updated successfully, but these errors were encountered: