From 2267a3de2807489d2518e87c7e1ffcc3229d14ed Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 23 Feb 2021 00:04:34 +0200 Subject: [PATCH 1/9] Add consensus decisions --- docs/consensus_decisions.md | 51 +++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 docs/consensus_decisions.md diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md new file mode 100644 index 0000000000..b33e8e1877 --- /dev/null +++ b/docs/consensus_decisions.md @@ -0,0 +1,51 @@ +# Consensus Decisions + +During its proceedings, the working group has reached internal consensus on a number of issues. +This document enumerates those, and provides a reference for later actions. + +## 1: Include message references in the data model. + +**Discussion:** +The implementers would find a way to include references anyways, but including it in the data model (standard) can make it subject to best practices. +It’s still possible for users to do “the wrong thing” (ex: concatenation of strings/messages), but then you would find it more difficult to achieve. + +One of the drawbacks of message references is that referenced messages effectively have a public API (names of parameters, variables, variants, etc.) which must be consistent across all callsites. +This leads us to consensus 2. + +## 2: Allow parameters passed with message references to the message being referenced and validate it. + +**Discussion:** +The variables/fields passed should not be completely untyped and unchecked. +We want a validation mechanism that can allow providing early error feedback to the translators & developers. +We need to decide on when the validation can & should happen, including the meaning of “build time” and “run time” in regards to validation. + +## 3: Allow for selectors to select a case depending on the value of one or more input arguments. + +**Discussion:** +This is a prerequisite for top-level selectors to be able to represent complex messages, without requiring those messages to be split up in an unergonomic manner. +This is an extension or relaxation of what's allowed in MessageFromat 1. + +While message references make it technically possible for the data model to represent multi-argument selectors otherwise, this requires the use of n²-1 artificial "messages", where n is the number of arguments. This is not desirable. + +## 4: Only allow for selectors at the top level of a message. + +**Discussion:** +Requiring selectors to only be available at the top level is a good way of helping to maintain the translatability of messages, as well as otherwise guiding MessageFormat 2 users towards good practices. + +After an in-depth exploration of the problem space, we have determined that while selectors are a necessary feature of MessageFormat, it is not necessary for them to be available within the body of a message, or directly within a case of a parent selector. + +All identified use cases of such constructions may be cleanly represented using a top-level selector that may use more than one input argument to select among a set of messages. +Furthermore, we may enable complete reversibility of message transformations to and from languages such as MessageFormat 1 and Fluent by using message references. + +## 5: Top level selectors together with message references provides the same value as nested selectors at a lower cost. + +**Discussion:** +Nested selectors provides capabilities that may be useful in avoiding variant permutation explosion in edge cases, but the use of them has not been evaluated in production localization systems to date. +The group believes that the known value of this feature can be sufficiently covered by the combination of message references and top level selection features, which together provide a sufficient feature set at a lower cost to the ecosystem than nested selectors would do. + +## 6: The group will attempt to avoid blocking addition of nested selectors in the future revisions of the standard. + +**Discussion:** +The cost analysis of the nested selectors feature was performed in the absence of sufficient in-field experience of use in production systems. +In result, the group's decision to reject the feature is based on the lack of sufficient known value that would require them, which the group recognizes may change in the future. +In result, it is the intent of the group to attempt to design MessageFormat 2 in such a way, that wouldn't block future revisions of the standard to be extended with nested selectors feature. From b818a4c9389a59789dafc63b7c9b90864e925c54 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 23 Feb 2021 18:37:28 +0200 Subject: [PATCH 2/9] Add sources for consensii --- docs/consensus_decisions.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index b33e8e1877..e15dad9266 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -3,6 +3,21 @@ During its proceedings, the working group has reached internal consensus on a number of issues. This document enumerates those, and provides a reference for later actions. +### Sources + +For more details on the process that lead to these decisions, please refer to the following: + +- **Consensus 1 & 2:** + Reached during the first three meetings of the "Issue #103 task-force", and codified during its [October 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/task-force/%23103-2020-10-26.md). + Accepted at the [November 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2020/notes-2020-11-16.md) of the working group. +- **Consensus 3 & 4:** + Reached in principle during the [December 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2020/notes-2020-12-14.md) of the working group. + Codified in [issue #137](https://github.com/unicode-org/message-format-wg/issues/137). + Discussed and accepted at the [January 2021](https://github.com/unicode-org/message-format-wg/issues/146) and [February 2021](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) meetings of the working group. +- **Consensus 5 & 6:** + Codified in [issue #137](https://github.com/unicode-org/message-format-wg/issues/137) during the [January 2021 meeting](https://github.com/unicode-org/message-format-wg/issues/146) of the working group. + Discussed and accepted at the [February 2021 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) of the working group. + ## 1: Include message references in the data model. **Discussion:** From 799f800a487ee51dfdc2398a30dd5c6162768dff Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 23 Feb 2021 18:55:58 +0200 Subject: [PATCH 3/9] Add more sources for consensii --- docs/consensus_decisions.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index e15dad9266..2655046685 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -8,13 +8,16 @@ This document enumerates those, and provides a reference for later actions. For more details on the process that lead to these decisions, please refer to the following: - **Consensus 1 & 2:** - Reached during the first three meetings of the "Issue #103 task-force", and codified during its [October 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/task-force/%23103-2020-10-26.md). + Identified as prerequisites for maintaining backwards-compatibility with MessageFormat 1 once Consensus 3 & 4 are agreed upon. + Reached during the meetings of the [issue #103](https://github.com/unicode-org/message-format-wg/issues/103) task-force, and codified during the [October 2020 task-force meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/task-force/%23103-2020-10-26.md). Accepted at the [November 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2020/notes-2020-11-16.md) of the working group. - **Consensus 3 & 4:** + The core result of the [issue #103](https://github.com/unicode-org/message-format-wg/issues/103) task-force ([minutes](https://github.com/unicode-org/message-format-wg/tree/master/meetings/task-force)). Reached in principle during the [December 2020 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2020/notes-2020-12-14.md) of the working group. Codified in [issue #137](https://github.com/unicode-org/message-format-wg/issues/137). Discussed and accepted at the [January 2021](https://github.com/unicode-org/message-format-wg/issues/146) and [February 2021](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) meetings of the working group. - **Consensus 5 & 6:** + The solution for [issue #127](https://github.com/unicode-org/message-format-wg/issues/127). Codified in [issue #137](https://github.com/unicode-org/message-format-wg/issues/137) during the [January 2021 meeting](https://github.com/unicode-org/message-format-wg/issues/146) of the working group. Discussed and accepted at the [February 2021 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) of the working group. From c9a8b8883466ef081a580e9ce84581e72ccb19bd Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Wed, 24 Feb 2021 09:31:05 +0200 Subject: [PATCH 4/9] Apply suggestions from code review Co-authored-by: Dan Minor --- docs/consensus_decisions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index 2655046685..59d43698cb 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -25,7 +25,7 @@ For more details on the process that lead to these decisions, please refer to th **Discussion:** The implementers would find a way to include references anyways, but including it in the data model (standard) can make it subject to best practices. -It’s still possible for users to do “the wrong thing” (ex: concatenation of strings/messages), but then you would find it more difficult to achieve. +It will unfortunately still be possible, but much more difficult, for users to do “the wrong thing” by concatenating strings or messages. One of the drawbacks of message references is that referenced messages effectively have a public API (names of parameters, variables, variants, etc.) which must be consistent across all callsites. This leads us to consensus 2. @@ -34,14 +34,14 @@ This leads us to consensus 2. **Discussion:** The variables/fields passed should not be completely untyped and unchecked. -We want a validation mechanism that can allow providing early error feedback to the translators & developers. -We need to decide on when the validation can & should happen, including the meaning of “build time” and “run time” in regards to validation. +We want a validation mechanism that can allow providing early error feedback to the translators and developers. +We need to decide on when the validation can and should happen, including the meaning of “build time” and “run time” in regards to validation. ## 3: Allow for selectors to select a case depending on the value of one or more input arguments. **Discussion:** This is a prerequisite for top-level selectors to be able to represent complex messages, without requiring those messages to be split up in an unergonomic manner. -This is an extension or relaxation of what's allowed in MessageFromat 1. +This is an extension or relaxation of what's allowed in MessageFormat 1. While message references make it technically possible for the data model to represent multi-argument selectors otherwise, this requires the use of n²-1 artificial "messages", where n is the number of arguments. This is not desirable. From 5151e95215cbb46ea92635507c2b5ae8e955c304 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Wed, 24 Feb 2021 14:27:56 +0200 Subject: [PATCH 5/9] Apply suggestions from code review --- docs/consensus_decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index 59d43698cb..8c89655bc2 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -30,7 +30,7 @@ It will unfortunately still be possible, but much more difficult, for users to d One of the drawbacks of message references is that referenced messages effectively have a public API (names of parameters, variables, variants, etc.) which must be consistent across all callsites. This leads us to consensus 2. -## 2: Allow parameters passed with message references to the message being referenced and validate it. +## 2: Allow message references to include parameters in a form that enables their validation. **Discussion:** The variables/fields passed should not be completely untyped and unchecked. From 7ef13ce6443131e6c674501c7cabef427ca0c414 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Fri, 26 Feb 2021 23:01:03 +0200 Subject: [PATCH 6/9] Apply suggestions from code review Co-authored-by: Elango --- docs/consensus_decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index 8c89655bc2..d209798313 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -65,5 +65,5 @@ The group believes that the known value of this feature can be sufficiently cove **Discussion:** The cost analysis of the nested selectors feature was performed in the absence of sufficient in-field experience of use in production systems. -In result, the group's decision to reject the feature is based on the lack of sufficient known value that would require them, which the group recognizes may change in the future. +In result, the group's decision to not currently incorporate the feature is based on the lack of sufficient known value that would require them, which the group recognizes may change in the future. In result, it is the intent of the group to attempt to design MessageFormat 2 in such a way, that wouldn't block future revisions of the standard to be extended with nested selectors feature. From 6288157e8f523877892a2598824e0a4089231a4d Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 2 Mar 2021 22:52:04 +0200 Subject: [PATCH 7/9] Apply suggestions from code review See PR discussion for details: https://github.com/unicode-org/message-format-wg/pull/154/files#r580985173 Co-authored-by: Dan Minor --- docs/consensus_decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index d209798313..7dce60e280 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -61,7 +61,7 @@ Furthermore, we may enable complete reversibility of message transformations to Nested selectors provides capabilities that may be useful in avoiding variant permutation explosion in edge cases, but the use of them has not been evaluated in production localization systems to date. The group believes that the known value of this feature can be sufficiently covered by the combination of message references and top level selection features, which together provide a sufficient feature set at a lower cost to the ecosystem than nested selectors would do. -## 6: The group will attempt to avoid blocking addition of nested selectors in the future revisions of the standard. +## 6: The group does not intend to block the addition of nested selectors in the future revisions of the standard. **Discussion:** The cost analysis of the nested selectors feature was performed in the absence of sufficient in-field experience of use in production systems. From 4140b1cfeb8d48e5c7e33e41779ac5db2bcb9207 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Wed, 3 Mar 2021 09:42:27 +0200 Subject: [PATCH 8/9] Oops, fix preceding change Proper fix for https://github.com/unicode-org/message-format-wg/pull/154#discussion_r580985173 --- docs/consensus_decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index 7dce60e280..a153eab313 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -61,7 +61,7 @@ Furthermore, we may enable complete reversibility of message transformations to Nested selectors provides capabilities that may be useful in avoiding variant permutation explosion in edge cases, but the use of them has not been evaluated in production localization systems to date. The group believes that the known value of this feature can be sufficiently covered by the combination of message references and top level selection features, which together provide a sufficient feature set at a lower cost to the ecosystem than nested selectors would do. -## 6: The group does not intend to block the addition of nested selectors in the future revisions of the standard. +## 6: The model will be designed to leave the door open for nested selectors being potentially reconsidered in the future. **Discussion:** The cost analysis of the nested selectors feature was performed in the absence of sufficient in-field experience of use in production systems. From 532e68d115ea9eea9e919e4d1631c6b4e1c09c1b Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Wed, 3 Mar 2021 11:32:27 +0200 Subject: [PATCH 9/9] Update docs/consensus_decisions.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Stanisław Małolepszy --- docs/consensus_decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus_decisions.md b/docs/consensus_decisions.md index a153eab313..bfb5b93b03 100644 --- a/docs/consensus_decisions.md +++ b/docs/consensus_decisions.md @@ -66,4 +66,4 @@ The group believes that the known value of this feature can be sufficiently cove **Discussion:** The cost analysis of the nested selectors feature was performed in the absence of sufficient in-field experience of use in production systems. In result, the group's decision to not currently incorporate the feature is based on the lack of sufficient known value that would require them, which the group recognizes may change in the future. -In result, it is the intent of the group to attempt to design MessageFormat 2 in such a way, that wouldn't block future revisions of the standard to be extended with nested selectors feature. +In result, it is the intent of the group to design MessageFormat 2 in a way that wouldn't prevent future revisions of the standard to be extended with nested selectors feature.