Skip to content

Support conditional spans of text #37

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

Jump to bottom
Closed
grhoten opened this issue Feb 10, 2020 · 6 comments
Closed

Support conditional spans of text #37

grhoten opened this issue Feb 10, 2020 · 6 comments
Labels
functions Issue pertains to the default function set requirements Issues related with MF requirements list

Comments

@grhoten
Copy link
Member

grhoten commented Feb 10, 2020

Is your feature request related to a problem? Please describe.
There should be a generic way to handle conditionals. When getting words into grammatical agreement, word choice can depend on the grammatical properties and values of other words.

Issue #21 goes into a discussion about ranges that is similar to ICU ChoiceFormat. It seems like shorthand to needing a more complete conditional handling. Issue #31 goes into detecting grammatical category values (grammemes), but you need to act upon a given value. A translator may need to choose a different verb or adjective depending on the noun inserted into a message.

Describe the solution you'd like
I'll try to avoid using the XML or UEL syntax that I'm used to using in the solution description. I'll just state what should be considered.

  • "if then {show span}". An alternative is to have a span of text just have a condition for being shown.
  • "if then {show span} else {show other span}". An alternative is to have a list of text spans, and each span that has a condition on it. The first span that has a conditional that evaluates to true is chosen, and there must be a default span at the end. The alternative would be easier for else-if statements.
  • The <, >, <=, >=, == (not assignment), !=, && (and), || (or) should be supported
  • Comparisons should be against numbers and strings. Though perhaps it's best to just do equals for strings so that you can compare against the gender, grammatical number or other grammatical category values of the string.
  • Switch statements so that you can compare against masculine, feminine, neuter, and unknown. ICU gender format isn't generic enough.
  • If a variable is null or invalid, a span of text is omitted.
  • If a span of text is chosen to be shown, allow it to be detected as being selected to allow for grammatical agreement later in a sentence. This is helpful for split verbs, which have been known to be used for German and Cantonese.

Describe why your solution should shape the standard
This is a way to get words to agree with each other. The several message formatting options from ICU don't have the same syntax. It would be better if it were consistent for handling conditionals to ease the learning curve.

Additional context or examples
#21
ICU ChoiceFormat
ICU PluralFormat
ICU GenderFormat
@Fleker
Copy link

Fleker commented Feb 10, 2020

I recently learned about Google's Common Expression Language spec which has a number of comparison behaviors based around the input being an expression as a string.

Would it make sense to design this syntax to provide a list of potential messages and their conditions, and then pick the first one that meets the criteria?

{{ conditional <-
  {{ "gender == masculine" <- "Masculine" }}
  {{ "gender == feminine" <- "Feminine" }}
  {{ "Unknown" }}  ( No conditional makes this the default )
}}

I would also want to make sure the input types for these conditionals can be dynamically defined by the application, ie.

{{ conditional <-
  {{ "weather.temp < 0" <- "Brr it is cold" }}
  {{ "It is not cold" }}
}}

@grhoten
Copy link
Member Author

grhoten commented Feb 10, 2020

@Fleker yeah that's the basic concept. Though I'm more familiar with UEL syntax or just XML syntax.

@Fleker
Copy link

Fleker commented Feb 10, 2020

I just made up the syntax, mainly to capture the spirit of the idea and certain requirements like handling application-specific structured data.

@mihnita
Copy link
Collaborator

mihnita commented Feb 14, 2020

I really don't think that we should try to stay away from converting this into a "Turing complete language"

Yes, it's powerful, and (as developers) was all like that.
But I can promise you that no translation tool will support this properly, and no translator will be able to use it :-)

If XLIFF is not well supported, the chances for this being supported are slim to none...

@mihnita mihnita added the requirements Issues related with MF requirements list label Sep 24, 2020
@aphillips aphillips added the functions Issue pertains to the default function set label Jul 19, 2023
@aphillips
Copy link
Member

Translating this issue into the current state of MFv2 (and asking for @grhoten to correct me if I'm wrong), I think this is a request to add some selector functions to the registry beyond simple string equality, for example:

:lt for "less-than", :gt for "greater-than", etc.

Most of this issue appears to be have been addressed by the creation of the match statement, but the functions provided by the default registry is a current topic.

@aphillips
Copy link
Member

As mentioned in today's telecon (2023-09-18), closing old requirements issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
functions Issue pertains to the default function set requirements Issues related with MF requirements list
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@aphillips @mihnita @Fleker @grhoten