Skip to content

Address #619: add a note about * variant #666

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Feb 20, 2024
Merged

Address #619: add a note about * variant #666

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
89e43f0
Address #619: add a note about `*` variant
aphillips Feb 18, 2024
6b7edd4
Address @stasm's comment
aphillips Feb 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -372,6 +372,30 @@ to provide the _pattern_ for the formatting operation.
This is done by ordering and filtering the available _variant_ statements
according to their _key_ values and selecting the first one.

> [!NOTE]
> At least one _variant_ is required to have all of its _keys_ consist of
> the fallback value `*`.
Copy link
Collaborator

@catamorphism catamorphism Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is a little awkward, but I can't think of a good way to rephrase it.

Unless you do something like:

"An exhaustive variant is required. In an exhaustive variant, every key must be the fallback value *."

Not a big deal, though.

Copy link
Member Author

@aphillips aphillips Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. The phrasing is a bit chewy. I didn't want to create a new term like "exhaustive variant" just for the note.

> Some _selectors_ might be implemented in a way that the key value `*`
> cannot be selected in a _valid_ _message_.
Comment on lines +378 to +379
Copy link
Collaborator

@stasm stasm Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we give an example of such a selector?

Suggested change
> Some _selectors_ might be implemented in a way that the key value `*`
> cannot be selected in a _valid_ _message_.
> Some _selectors_ might be implemented in a way that the key value `*`
> cannot be selected in a _valid_ _message_.
>
> ```
> .match {$result :boolean}
> true {{Result is true}}
> false {{Result is false}}
> * {{Unreachable}}
> ```

I think this would make it easier to understand why the next sentence starts with "in other cases... only in certain locales".

Copy link
Member Author

@aphillips aphillips Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to avoid using functions that don't exist 😉

.match {$boolean :string}
true  {{Result is true}}
false {{Result is false}}
*     {{Unreachable?}}

> In other cases, this key value might be unreachable only in certain locales.
> This could result in the need in some locales to create
> one or more _variants_ that do not make sense grammatically for that language.
> > For example, in the `pl` (Polish) locale, this _message_ cannot reach
> > the `*` _variant_:
> > ```
> > .match {$num :integer}
> > 0 {{ }}
> > one {{ }}
> > few {{ }}
> > many {{ }}
> > * {{Only used by fractions in Polish.}}
> > ```
Comment on lines +383 to +392
Copy link
Collaborator

@eemeli eemeli Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be a simpler example for what's being demostrated here?

Suggested change
> > For example, in the `pl` (Polish) locale, this _message_ cannot reach
> > the `*` _variant_:
> > ```
> > .match {$num :integer}
> > 0 {{ }}
> > one {{ }}
> > few {{ }}
> > many {{ }}
> > * {{Only used by fractions in Polish.}}
> > ```
> > For example, in the `en` (English) locale, this _message_ cannot reach
> > the `*` _variant_ unless `$num` is not a valid number:
> > ```
> > .match {$num :number}
> > one {{ }}
> > other {{ }}
> > * {{ }}
> > ```

Copy link
Member Author

@aphillips aphillips Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really want to promote the use of other with the number functions? In English? I thought the Polish example was clever because it naturally exposes the issue at hand (and begs the question "what does that message say?"). But happy to accept this too...

Copy link
Collaborator

@eemeli eemeli Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I've understood, in Polish many is the fallback category, so explicitly including it (as in your example) is not really any different from my proposal.

Copy link
Member Author

@aphillips aphillips Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

many is the fallback for integers (I used the function :integer on purpose), but IIUC other is used for fractions. Maybe my example was too subtle... (see here in the charts)

>
> In the Tech Preview, feedback from users and implementers is desired about
> whether to relax the requirement that such a "fallback _variant_" appear in
> every message, versus the potential for a _message_ to fail at runtime
> because no matching _variant_ is available.

The number of _keys_ in each _variant_ MUST equal the number of _selectors_.

Each _key_ corresponds to a _selector_ by its position in the _variant_.
Expand Down