Clear up some ambiguities in terminology in formatting.md #723

macchiati · 2024-03-13T03:57:11Z

No description provided.

Clear up some ambiguities in terminology

eemeli · 2024-03-13T07:22:17Z

spec/formatting.md

@@ -216,7 +217,7 @@ the following steps are taken:

 4. Call the function implementation with the following arguments:

-   - The current _locale_.
+   - The current _formatting context_.


This is too much, and potentially allows for too much "magic" in a custom function. I agree that the current text is missing the following:

base direction

bidi strategy

locale matcher strategy (not referenced in our current spec, but relevant at least for JS)

The full function context also includes e.g. all of the raw input values, and those should definitely not be made all ä available to all functions.

The formatting context might contain implemetation-specific goo (at Amazon we squirreled which site the user was on into field(s) in the context).

I agree that a badly behaved function might do Bad Magick. But I think it's useful to give developers access to what they need and stay out of their way after that. You'll note that I made the exact same suggestion recently (but changed it at your request, because it was not a parsimonious change at that moment in time).

And Stas and others want to be able to have access, like :u:function gender-agreement=$var.

locale is certainly wrong.

@macchiati

locale isn't wrong: one definitely wants that! However, I agree with you that more is needed.

The example :u:function gender-agreement=$var doesn't make sense to me, unless you mean for the gender agreement part to be implied?

I forget the exact example that Stas had, but it was to have options have values that are other variables, so that we could change the case (for example) of an adjective to match that of a noun.

Ah, I see what you're saying.

It's not the same thing. The variable in an option is, itself, subject to having its value resolved by the MF processor before the function is itself invoked (we say so in the options section). So it doesn't apply to needing the formatting context. The function gets the resolved value, not a variable reference.

eemeli · 2024-03-13T07:27:03Z

spec/formatting.md

  with reference to the current _formatting context_.
  This can include multiple steps,
  such as looking up the value of a variable and calling formatting functions.
  The form of the resolved value is implementation defined and the
  value might not be evaluated or formatted yet.
-  However, it needs to be "formattable", i.e. it contains everything required
-  by the eventual formatting.
+  However, if it is the resolved value of an expression with a function


Why include the mention "with a function" here? Also, it's not really our functions that are "formatting" or "selection" functions, it's the resolved values that may or may not support either, or both.

I agree with @eemeli. What's more, this is overly specific to expression and forgets about markup. Perhaps instead of trying to list everything separately we could say:

Suggested change

However, if it is the resolved value of an expression with a function

However, it needs to be "formattable", that is, it contains everything required

during later steps in the formatting process (such as selection, formatting, or output

of the _expression_ or _markup_.

Note that I was tempted to add "... as a string" at the end of the above, but formatToParts behavior shouldn't be omitted.

Well, the current statement

"However, it needs to be "formattable", i.e. it contains everything required by the eventual formatting."

is absolutely wrong. The resolved value for a an expression does not have to be "formattable" if the expression uses a function that is not a formatting function.

BTW, after v45, this section needs to have some serious fixups to be much less vague about the terms "value" and "resolved value". Both are ambigously used, and it really matters for clarity.

I'd recommend changing almost all usages to the specific terms:

"resolved expression value"

"resolved variable value"

"resolved function value", and so on

I'd recommend changing almost all usages to the specific terms:

* "resolved expression value" * "resolved variable value" * "resolved function value", and so on

This is what #645 addresses, not using quite the same terms, but I encourage you to comment there (at some point) if you want to suggest changes.

Thanks for the pointer, I'll look that over.

We're aware of the post-45 work.

The resolved value for a an expression does not have to be "formattable" if the expression uses a function that is not a formatting function.

Although I somewhat agree with you, I have always read "formatting" and "formattable" in this section to mean the processing found in this section--which include resolution, selection, and actual formatting. Formatting a message does not just mean making the output string.

Since we strongly distinguish between formatting functions and selection functions, I think it very likely that people will misunderstand that "formatting" means "formatting and selection" in this paragraph.

That being said, this could wait for v46.

macchiati · 2024-03-14T03:13:58Z

I had intended some small fixes to what appear false statements. But those fixes are controversial, and I don't want to waste people's time at this late date. So I'll withdraw the suggestions, and wait for v46 discussions.

macchiati · 2024-03-14T16:11:19Z

Ok. I think we need to look carefully at the order of evaluation in Stas's example. {{$adjective gender-from=$noun} {$noun :function-that-may-modify-gender}...} If this is evaluated left to right, it could get the wrong answer. First, not an issue for now, but something to look at in v46 Second, we need to look at some more use cases; IMO it would be better to select among variant messages using the $noun's resolved gender, because the writer can't anticipate what parts of a sentence might need to change in different languages in translation.

…

On Thu, Mar 14, 2024 at 7:32 AM Addison Phillips ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In spec/formatting.md <#723 (comment)> : > @@ -216,7 +217,7 @@ the following steps are taken: 4. Call the function implementation with the following arguments: - - The current _locale_. + - The current _formatting context_. Ah, I see what you're saying. It's not the same thing. The variable in an option is, itself, subject to having its value resolved by the MF processor *before* the function is itself invoked (we say so in the options section). So it doesn't apply to needing the formatting context. The function gets the resolved value, not a variable reference. — Reply to this email directly, view it on GitHub <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMAPXWT6RM3ZCQT6UZDYYGYI5AVCNFSM6AAAAABETMS4I6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMZWHA4TENRZGE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

Update formatting.md

3e184bd

Clear up some ambiguities in terminology

eemeli requested changes Mar 13, 2024

View reviewed changes

aphillips added the formatting Issue pertains to the formatting section of the spec label Mar 13, 2024

macchiati closed this Mar 14, 2024

aphillips deleted the macchiati-patch-1 branch March 25, 2024 18:11

-  However, if it is the resolved value of an expression with a function
+However, it needs to be "formattable", that is, it contains everything required
+during later steps in the formatting process (such as selection, formatting, or output
+of the _expression_ or _markup_.

Uh oh!

Clear up some ambiguities in terminology in formatting.md #723

Clear up some ambiguities in terminology in formatting.md #723

Uh oh!

Conversation

macchiati commented Mar 13, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macchiati commented Mar 14, 2024

Uh oh!

macchiati commented Mar 14, 2024 via email

Uh oh!

Uh oh!