You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A multi-select message often has one variable used for selection. But what if there are two or more? How do we structure and represent the message accordingly?
This issue is somewhat related to #103, and the example there is applicable here, too.
Several comments that are in favor of "flat" (non-nested) multi-select messages also represent the selection args (selectors) in a list, and likewise represent the selection function return values in a list to key each corresponding pattern in the multi-select message. Ex: #98 (comment) Ex: projectfluent/fluent#4
One alternate formulation of a flat multi-select message uses a map instead of the prevalent 2 lists formulation (selector names and selector values). A detailed discussion of the tradeoffs, which resulted in that formulation losing support from its proponent, can be read here.
If #103 results in allowing nested multi-select messages, then that might simplify how this question is understood. What would that look like, and what are the tradeoffs?
The text was updated successfully, but these errors were encountered:
echeran
changed the title
Ho do we support multiple selection args (selectors) in a multi-select message?
How do we support multiple selection args (selectors) in a multi-select message?
Aug 10, 2020
A multi-select message often has one variable used for selection. But what if there are two or more? How do we structure and represent the message accordingly?
This issue is somewhat related to #103, and the example there is applicable here, too.
Several comments that are in favor of "flat" (non-nested) multi-select messages also represent the selection args (selectors) in a list, and likewise represent the selection function return values in a list to key each corresponding pattern in the multi-select message. Ex: #98 (comment) Ex: projectfluent/fluent#4
One alternate formulation of a flat multi-select message uses a map instead of the prevalent 2 lists formulation (selector names and selector values). A detailed discussion of the tradeoffs, which resulted in that formulation losing support from its proponent, can be read here.
If #103 results in allowing nested multi-select messages, then that might simplify how this question is understood. What would that look like, and what are the tradeoffs?
The text was updated successfully, but these errors were encountered: