Create notes-2025-04-21.md

Author: aphillips

meetings/2025/notes-2025-04-21.md

@@ -0,0 +1,169 @@
+# 21 April 2025 | MessageFormat Working Group Teleconference
+
+Attendees:
+
+- Addison Phillips \- Unicode (APP) \- chair  
+- Mihai Niță \\- Google (MIH)  
+- Shane Carr \\- Google (SFC)  
+- Daniel Gleckler (DAG)  
+- Tim Chevalier \\- Igalia (TIM)  
+- Richard Gibson \\- OpenJSF (RGN)
+
+
+- 
+
+**Scribe:**  MIH  
+
+
+
+## Topic: Info Share, Project Planning
+
+## Topic: PR Review
+
+*Timeboxed review of items ready for merge.*
+
+| PR | Description | Recommendation |
+| ----- | ----- | ----- |
+| \#1071 | Currency and unit conformance | Discuss |
+| \#1070 | Allow clamping of digit size options | Discuss, Merge? |
+| \#1068 | Design document for percent formatting | Discuss |
+| \#1067 | Semantic skeletons design | Discuss |
+| \#1065 | Draft new charter and goals for v49/v50 and beyond | Discuss |
+|  |  |  |
+
+## Topic: Semantic Skeletons
+
+*Reserving time to discuss the design.*
+
+[https://github.com/unicode-org/message-format-wg/pull/1067](https://github.com/unicode-org/message-format-wg/pull/1067)   
+[https://github.com/unicode-org/message-format-wg/pull/1067/files?short\_path=ee0a5f2\#diff-ee0a5f2b733a9fdd85ab9880271f9f036decc3910f560655df115e939ed168e4](https://github.com/unicode-org/message-format-wg/pull/1067/files?short_path=ee0a5f2#diff-ee0a5f2b733a9fdd85ab9880271f9f036decc3910f560655df115e939ed168e4)
+
+## Topic: Percent Formatting (\#956)
+
+*Reserving time to discuss whether to go with \`:percent\` or whether to use \`:unit unit=percent\` and how to handle percents if unscaled.*
+
+## 
+
+## Topic: Issue review
+
+[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
+
+Currently we have 31 open (was 32 last time).
+
+* 21 are tagged for 48  
+* 3 are tagged “Future”  
+* 13 are `Preview-Feedback`  
+* 2 are tagged Feedback  
+* 1 is `resolve-candidate` and proposed for close.  
+* 2 are `Agenda+` and proposed for discussion (see below)  
+* 0 are ballots
+
+| Issue | Description | Recommendation |
+| ----- | ----- | ----- |
+| \#1043 | Deployment, development, and maintenance of messageformat.unicode.org | Discuss |
+| \#1051 | Plans for v48 | Discuss |
+| \#1052 | TAG Review | Resolve (thank TAG) |
+| \#1062 | Test for unpaired surrogates is rejected by some JSON parsers | Discuss |
+
+## \#\# PRs
+
+### \#\#\# 1071 Currency and unit conformance
+
+Some comments on it, will continue there
+
+### \#\#\# 1070 Allow clamping of digit size options
+
+Ship it from Eemeli  
+Comment form SFC  
+Some comments on some tests  
+Open comments from people missing here, we will not merge today
+
+### \#\#\# 1065 Draft new charter and goals for v49/v50 and beyond
+
+Discussing with CLDR TC.  
+Add your comments if you have them
+
+### \#\#\# 1067 Semantic skeletons design
+
+APP: Emergent consensus that we will have several functions, instead of one function with too many options.  
+We will still have some grab-bag ones, like `` :datetime` ``  
+
+MIH: had two takes. Would rather have this in ICU before in MF. Know it can be mapped/implemented on top of existing skeletons. In general, MF only calls the date formatter so date formatter would have to be updated to support skeletons. 
+
+Settings for width apply to all buckets of pieces. So I says “day of week,day, month and want full” and I get Thursday and December etc. Cannot say the time zone to be short and day abbrev. Etc We are losing flexibility quite a bit. That’s the main thing.
+
+SFC: (from chat) re implementations: semantic skeletons can be implemented on top of DateTimePatternGenerator  
+re widths: we have a path for this. Does it block semantic skeletons in v48 for MF2?
+
+MIH: don’t want to put in MF that isn’t in the ICU formatters.  
+It is just a matter of order.  
+ICU would need to approve and implement semantic skeletons in DateFormat
+
+APP: individual field widths are an absolute necessity.  
+If we don’t have them then people will go back to option bags.
+
+APP: Let’s wait for SFC to be back online
+
+## \#\# Issues
+
+### \#\#\# 1062 Test for unpaired surrogates is rejected by some JSON parsers
+
+APP: Steven Loomis suggested a binary form in json  
+I would even question if we even need these tests, explicitly.
+
+TIM: I think it would be good to have them in the test files, since they are in the spec.
+
+APP: we actually don’t require implementations to support them.
+
+MIH: was pushing strongly for this. Certain frameworks do UTF16 possibly invalid. Could be implementation specific. “Do this in code”, we have this in code. In ICU we have like junits, outside the json space. If you are this sort of implementation write it outside the jsons. I would expect implementations to do this anyway. Result of a date format is you get what you get. 
+
+APP: don’t attempt to do that
+
+MIH: point is that you’ll have some tests like that.   
+To make sure that the plumbing between MF and the real formatters work.
+
+TIM: similar to the java implementation, so supports any utf16. There are tests in code. If we dropped from json, would be fine.
+
+APP: comment instead?
+
+TIM: sure, sounds like a good idea
+
+APP: I’ll do a PR, unless someone else wants to do it
+
+SFC: one can spend time writing all the pros / cons for separate / unique functions  
+Options on existing functions feel more natural for semantic skeletons  
+There is pushback for many functions, but only from Mark Davis  
+I think we should have 6 or 7 functions.  
+We would have date, time, datetime \+ zoned differences.
+
+People are very picky on how the tz are shown.  
+Width is about space, but also understanding.
+
+The only 2 fields.
+
+APP: devs and designers will be the ones interacting with semantic skeletons  
+We allow for 2 / 4 digit years, 0 filled hours, stuff over which we used go give people control  
+Should we take away these controls?
+
+SFO: 2 digits are already covered  
+We have 2 options for 2 digits fields that are independent of full / long / medium / short  
+They are in UTS \#35.
+
+APP: functions that are not zoned have different names (civil times, local times, between JS, Java, others)
+
+SFC: in JS most times are timestamps, sometimes with a tz information (proper tz is or offset)
+
+APP: as a user I want to format the date part of `` `Date` `` I call the `` `:date` `` method.  
+As a MF user I want to write a message, hand it over, and just show a date.
+
+APP: I understand the temporal argument.  
+But as one of the zillion new grads, I don’t understand the subtleties.
+
+RGN: JS date has no tz info. And sometimes has an offset, but is taken from the host
+
+MIH: MF is not strongly typed at all.  
+So having many functions, with strict typing, we will need a way to make MF fallback to something that makes sense and not “explode”
+
+SFC: you don’t pass a hash map to a `` `DateFormat` ``, or an integer.  
+For me passing an integer is as wrong as passing a hash map.
+