|
| 1 | +# 09 December 2024 | MessageFormat Working Group Teleconference |
| 2 | + |
| 3 | +### Attendees |
| 4 | + |
| 5 | +- Addison Phillips \- Unicode (APP) \- chair |
| 6 | +- Eemeli Aro \- Mozilla (EAO) |
| 7 | +- Mihai Niță \- Google (MIH) |
| 8 | +- Elango Cheran \- Google (ECH) |
| 9 | +- Richard Gibson \- OpenJSF (RGN) |
| 10 | +- Tim Chevalier \- Igalia (TIM) |
| 11 | +- Mark Davis \- Google (MED) |
| 12 | +- |
| 13 | + |
| 14 | +### Previous Attendees |
| 15 | + |
| 16 | +- Addison Phillips \-Unicode (APP) \- chair |
| 17 | +- Mihai Niță \- Google (MIH) |
| 18 | +- Eemeli Aro \- Mozilla (EAO) |
| 19 | +- Tim Chevalier \- Igalia (TIM) |
| 20 | +- Elango Cheran \- Google (ECH) |
| 21 | +- Mark Davis \- Google (MED) |
| 22 | +- Richard Gibson \- OpenJSF (RGN) |
| 23 | +- Matt Radbourne \- Bloomberg (MRR) |
| 24 | +- |
| 25 | + |
| 26 | + |
| 27 | + |
| 28 | +**Scribe:** RGN |
| 29 | +**Previous Scribe:** TIM |
| 30 | + |
| 31 | +To request that the chair add an *issue* to the agenda, add the label `Agenda+` To request that the chair add an agenda item, send email to the message-format-wg group email. |
| 32 | + |
| 33 | +## [**Agenda**](https://github.com/unicode-org/message-format-wg/wiki#agenda) |
| 34 | + |
| 35 | +## Topic: Info Share |
| 36 | + |
| 37 | +ECH: got the tests into CLDR |
| 38 | + |
| 39 | +EAO: npm package is up-to-date with the spec |
| 40 | + |
| 41 | +### Topic: PR Review |
| 42 | + |
| 43 | +*Merge what is mergeable. Close what is closeable.* |
| 44 | + |
| 45 | +### Topic: Issue Review |
| 46 | + |
| 47 | +*Review 46.1 issue list.* |
| 48 | + |
| 49 | +### Default Bidi Strategy |
| 50 | + |
| 51 | +*Tim has raised some issues with the default bidi strategy description. Let’s discuss.* |
| 52 | + |
| 53 | +## Topic: Section ordering |
| 54 | + |
| 55 | +[https://github.com/aphillips/cldr/blob/aphillips-messageformat-46-1/docs/ldml/tr35-messageFormat.md](https://github.com/aphillips/cldr/blob/aphillips-messageformat-46-1/docs/ldml/tr35-messageFormat.md) has: |
| 56 | + |
| 57 | +1. Syntax |
| 58 | +2. ABNF |
| 59 | +3. Formatting |
| 60 | +4. Errors |
| 61 | +5. Default function registry |
| 62 | +6. Unicode namespace |
| 63 | +7. Data model |
| 64 | +8. Appendices |
| 65 | + |
| 66 | +APP: The design document seems to be heading in the direction of separating the default function registry. |
| 67 | + |
| 68 | +MED: We have a six month cycle, and if function registration needs something faster then we’d pull them out. |
| 69 | + |
| 70 | +## Topic: Release notes |
| 71 | + |
| 72 | +MED: We’ll need a section describing changes, and also implementations would be useful. |
| 73 | + |
| 74 | +MED: Also a blog post about the release. |
| 75 | + |
| 76 | +APP: I volunteer. |
| 77 | + |
| 78 | +MED: I’ll be away starting tomorrow, but Peter Edburg and/or Steven Loomis are available. |
| 79 | + |
| 80 | +EAO: What is the timing of the blog post? I’m wondering if we can adopt messageformat.dev as the official documentation site. |
| 81 | + |
| 82 | +APP: That’s an open question that probably won’t be resolved until January. |
| 83 | + |
| 84 | +MED: We can always follow up with another post. |
| 85 | + |
| 86 | +## ** Topic: PR Review** |
| 87 | + |
| 88 | +*Timeboxed review of items ready for merge.* |
| 89 | + |
| 90 | +| PR | Description | Recommendation | |
| 91 | +| ----- | ----- | ----- | |
| 92 | +| \#971 | Add namespaces to example non-default functions | Merge | |
| 93 | +| \#969 | In default bidi strategy, make steps consistent with each other | Discuss | |
| 94 | +| \#968 | Clarification to default bidi strategy | Discuss | |
| 95 | +| \#923 | Test schema: allow src property to either be string or array of strings | Discuss | |
| 96 | + |
| 97 | +### PR 971 |
| 98 | + |
| 99 | +[https://github.com/unicode-org/message-format-wg/pull/971](https://github.com/unicode-org/message-format-wg/pull/971) |
| 100 | + |
| 101 | +EAO: Should be easy to merge in. |
| 102 | + |
| 103 | +MED: It just needs to go in today. |
| 104 | + |
| 105 | +### PR 923 |
| 106 | + |
| 107 | +[https://github.com/unicode-org/message-format-wg/pull/923](https://github.com/unicode-org/message-format-wg/pull/923) |
| 108 | + |
| 109 | +APP: Not for today. |
| 110 | + |
| 111 | +### PR 969 |
| 112 | + |
| 113 | +[https://github.com/unicode-org/message-format-wg/pull/969](https://github.com/unicode-org/message-format-wg/pull/969) |
| 114 | + |
| 115 | +EAO: The current wording is clumsy and unclear. But the fix proposed in this PR would make things more confusing, because the format string is not appended to anything. I think the whole of the described algorithm should instead build a concatenated string with prefixes and postfixes. |
| 116 | + |
| 117 | +APP: I agree. The strategy never actually says what to do. |
| 118 | + |
| 119 | +TIM: I’ll try to fix after the meeting. |
| 120 | + |
| 121 | +EAO: So, an algorithm that takes into account both placeholders and text and outputs a string, or… |
| 122 | + |
| 123 | +TIM: I’ll look at suggestions from both EAO and APP. |
| 124 | + |
| 125 | +EAO: I think a big change is needed in this case. Intent alone is not enough. |
| 126 | + |
| 127 | +APP: Does this need to go in 46.1? |
| 128 | + |
| 129 | +EAO: I think this is for 47\. |
| 130 | + |
| 131 | +MED: I agree. |
| 132 | + |
| 133 | +… |
| 134 | + |
| 135 | +(more to discuss) |
| 136 | + |
| 137 | +## Topic: Issue review |
| 138 | + |
| 139 | +[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues) |
| 140 | + |
| 141 | +Currently we have 36 open (was 31 last time). |
| 142 | + |
| 143 | +* 3 are tagged for 46.1 (2 are resolve-candidate, 1 is Action-Item) |
| 144 | +* 15 are tagged for 47 |
| 145 | +* 4 are tagged “Seek-Feedback-in-Preview” |
| 146 | +* 6 are tagged “Future” |
| 147 | +* 13 are `Preview-Feedback` |
| 148 | +* 7 are `resolve-candidate` and proposed for close. |
| 149 | +* 0 are `Agenda+` and proposed for discussion. |
| 150 | +* 0 are ballots |
| 151 | + |
| 152 | +| Issue | Description | Recommendation | |
| 153 | +| ----- | ----- | ----- | |
| 154 | +| | | | |
| 155 | +| | | | |
| 156 | +| | | | |
| 157 | +| | | | |
| 158 | +| | | | |
| 159 | +| | | | |
| 160 | + |
| 161 | +### Issue 856 |
| 162 | + |
| 163 | +[https://github.com/unicode-org/message-format-wg/issues/856](https://github.com/unicode-org/message-format-wg/issues/856) |
| 164 | + |
| 165 | +APP: done |
| 166 | + |
| 167 | +### Issue 931 |
| 168 | + |
| 169 | +[https://github.com/unicode-org/message-format-wg/issues/931](https://github.com/unicode-org/message-format-wg/issues/931) |
| 170 | + |
| 171 | +APP: Any objections to closing? |
| 172 | + |
| 173 | +(none) |
| 174 | + |
| 175 | +### Issue 819 |
| 176 | + |
| 177 | +[https://github.com/unicode-org/message-format-wg/issues/819](https://github.com/unicode-org/message-format-wg/issues/819) |
| 178 | + |
| 179 | +### Issue 818 |
| 180 | + |
| 181 | +[https://github.com/unicode-org/message-format-wg/issues/818](https://github.com/unicode-org/message-format-wg/issues/818) |
| 182 | + |
| 183 | +### Issue 817 |
| 184 | + |
| 185 | +[https://github.com/unicode-org/message-format-wg/issues/817](https://github.com/unicode-org/message-format-wg/issues/817) |
| 186 | + |
| 187 | +### Issue 724 |
| 188 | + |
| 189 | +[https://github.com/unicode-org/message-format-wg/issues/724](https://github.com/unicode-org/message-format-wg/issues/724) |
| 190 | + |
| 191 | +### Issue 663 |
| 192 | + |
| 193 | +[https://github.com/unicode-org/message-format-wg/issues/663](https://github.com/unicode-org/message-format-wg/issues/663) |
| 194 | + |
| 195 | +### Issue 675 |
| 196 | + |
| 197 | +[https://github.com/unicode-org/message-format-wg/issues/675](https://github.com/unicode-org/message-format-wg/issues/675) |
| 198 | + |
| 199 | +### Issue 586 |
| 200 | + |
| 201 | +[https://github.com/unicode-org/message-format-wg/issues/586](https://github.com/unicode-org/message-format-wg/issues/586) |
| 202 | + |
| 203 | +EAO: Defining markup handling further than we have now without formatToParts becomes very difficult. I would be open to leaving this out because we do not have appetite for that. |
| 204 | + |
| 205 | +EAO: This needs improved explanation of markup. |
| 206 | + |
| 207 | +MIH: I think this needs implementation experience. For example, XLIFF has a separate document in addition to the actual spec. |
| 208 | + |
| 209 | +EAO: Right now, our analogs are HTML and XML. |
| 210 | + |
| 211 | +ECH: I was interpreting MIH to imply that we need to see how people are using this before making normative text. We should see what implementations actually do with this. |
| 212 | + |
| 213 | +EAO: If we want space to possibly use later, we could ask for feedback on our earlier decision about requiring pairing for open and close. |
| 214 | + |
| 215 | +ECH: We need a superset of valid pairing, because segmentation can happen in the middle… |
| 216 | + |
| 217 | +ECH: We got here for a reason. |
| 218 | + |
| 219 | +EAO: I have a concern that well-intentioned/well-founded choices we have made to use braces look like warts to MF2 users. There is a danger of competing MF2-like syntaxes. |
| 220 | + |
| 221 | +MIH: Those variants risk cross-platform compatibility. |
| 222 | + |
| 223 | +ECH: Back to the very beginning of the group, we had analysis paralysis about being a universal solution. |
| 224 | + |
| 225 | +EAO: We’re partially creating a \*JavaScript\* formatting system… “better” dialects may emerge. The data model allows for multiple different syntaxes. Should we really be discouraging dialects? Do we want people coming to this group with syntax suggestions? |
| 226 | + |
| 227 | +ECH: I can imagine people creating higher-level DSLs to be more natural in specific languages. The data model ensures interop, and if they interop then we’ve done our job. |
| 228 | + |
| 229 | +… |
| 230 | + |
| 231 | +EAO: We could ask for preference of interchange tooling based on our syntax vs. just the data model. |
| 232 | + |
| 233 | +ECH: Either the data model is sufficient and we wasted over a year debating syntax, or… |
| 234 | + |
| 235 | +EAO: I don’t want to revisit decisions, I’m talking about how to represent what we’ve done, given that some people will consider those decisions to be mistakes. |
| 236 | + |
| 237 | +ADD: If you think we’ve made a mistake, then you should come talk to us and listen to our answers. |
| 238 | + |
| 239 | +… |
| 240 | + |
| 241 | +EAO: Does this indecision mean that we shouldn’t ask about markup? |
| 242 | + |
| 243 | +## ** Topic: AOB?** |
| 244 | + |
0 commit comments