User feedback survey for MessageFormat

[echeran]

Hi, I'm curious if your group would be interested in designing a user feedback survey/form/study that would help the MessageFormat specification.

We currently have a technical preview version of the spec in CLDR's LDML v45.

We have technical preview implementations in ICU v75 to match, both in C++ (ICU4C) and Java (ICU4J). ICU & CLDR have releases 2 times a year, and new APIs in ICU typically go through a process of stages: technical preview (for 1+ releases), beta (at least a few releases), final (if no complaints received in the last few years of beta).

There's also an ECMA-402 proposal for Intl.MessageFormat. The ECMA-402 proposal is of course tied to having a stabilized spec, which needs feedback from users to weigh in on design decisions.

It would really help to figure out from users of any technical preview implementations of the current version of the new MF spec what they think. Ex: what features are useful? not useful? easy? difficult? etc. Also, in order to rush and meet the deadline for the spec along with ICU implementations ready for the joint CLDR v45 / ICU v75 release, some decisions were postponed for the post CLDR v45 period, or we took a short term compromise resolution. So now is a good time to revisit, reflect & collect feedback. It would confer more clarity & confidence to take forward our future work.

cc @aphillips @eemeli @mihnita @stasm @catamorphism

[codehag]

This would be potentially interesting and a good way to evaluate the MessageFormat syntax as part of the MessageFormat proposal in TC39. As you mentioned, the 402 proposal is currently blocked on the user evaluation, but a well designed survey could help in soliciting and evaluating that feedback. Since it has an impact on a TC39 specification, I believe it is in scope.

[codehag]

@echeran Do you have a list of questions that you would want to answer? This would help when thinking about the study.

[echeran]

Good question. Here's a first attempt. I first have to remind myself of who we think the target audience of interested people are, and as we see it, that group is potentially diverse in their backgrounds:

• application engineers (who are authoring the messages in their code)
• translators (translating messages that were originally authored for an application and subsequently extracted and sent for translation)
• implementation engineers (implementing MF2 support in their own i18n library / programming language / framework)
• localization managers (concerned about level of support for translation/l10n features)
• localization tool industry (ex: people who implement CAT tools that translators depend on to do their job; online services offering translation of documents given in different formats; etc.)

Some questions that come to mind:

• If you have used ICU MessageFormat previously, what has been your experience with it? What works well? What doesn't work well?
• If you have used another message authoring in some other library or system, which were they? (ex: gettext, Android string resources, Mozilla Fluent, etc.) For each, what worked well, and what didn't work well?
• How do you interact with user-facing application messages in your daily work?
• What role(s) do you serve in your daily work?
• What are your biggest pain points regarding user-facing application messages, past or present?
• What are your most important flows of work / use cases regarding user-facing messages, if different from above?
• What are your overall thoughts about the current MF2 spec and implementation?
• What features about the current MF2 spec and implementation do you like most?
• What features about the current MF2 spec and implementation do you like least?
• Are there features in the current MF2 spec and implementation that you would like to see, but do not yet exist?
• Are there features in the current MF2 spec and implementation that you do not use at all?
• With the current MF2 spec in a technical preview phase, what changes would you want to see made before it can progress to the beta phase, and onwards to a final release?

cc @mradbourne who also might be interested

[codehag]

We discussed this potential study as part of TG5's meeting last Wednesday. Michael Coblenz had some good suggestions and a few questions. We'd like to schedule a breakout meeting in about 3 months time. What does your availability look like and are there others who would be interested in joining?

Prior to this meeting, we have a leading question. Rather than start with questions you would ask potential survey memebers, we want to focus on the goal. For you as designers, what do you want to know? What do you want to verify?

[echeran]

I should be around and available to meet in 3 months time, unless it's during the 4th week of October. Did you mean 3 months, or 3 weeks?

Asking about the goal is a good question to start from. At a high level, we want to gather feedback for the API design & behavior described by the spec text. As designers, we've had disagreements when coming to decisions (& sometimes after decisions were made). Sometimes that boiled down to a disagreement of what the requirements are, or what the evaluative criteria are to decide among the options. Ex: different people filling in the sentence, "I think people using this feature would prefer ____" with different answers. Without having some type of data / feedback, it's hard to really evaluate those arguments, even when we sort out the alternatives.

So I'd like to know how people perceive the new API design, in order to have more tangible insights. If nothing else, I think it would allow us to view feedback all together, since I still find it mysterious whose feedback tends to make how much of an impression on the group's focus and why.

Of course, we can get into specifics of technical decisions and ask people how they like the syntax, what they think about the function registry, and the various things in the spec that are required & optional to implement. Maybe the linguistic features that they would like their messages to support that they have problems with right now. And we can get to even more granular details, like their expectations on syntax whitespace handling, expectations on composing functions in a message, error handling behavior, function registry schemas, etc.

I wasn't sure what level of specificity you were asking, so I tried to cover a wide range. I hope an answer to your question is somewhere in there... Other people might be interested, so I should ask in our next meeting to find out.

[codehag]

sorry, i had meant 3 weeks! What is your availability in the coming weeks?

[echeran]

Here's a calendar time planning doodle thing for next week. I'll be on vacation for the 3 weeks following that, though. Once I'm back, I should be around with no major planned absences for a while.

[mcoblenz]

I replied to the poll. Hopefully we can find a time that works.

[sffc]

I added my availability; it's a bit limited due to time zones but you don't need to consider me required!

[mcoblenz]

There aren’t any times that work for us all this week. Closest is Thursday 2:30 - 3:30, but Eemeli isn’t available then. Do we want to meet anyway or defer until after Elango is back from vacation? Michael

…

On Jun 24, 2024, at 8:48 AM, Shane F. Carr ***@***.***> wrote: I added my availability; it's a bit limited due to time zones but you don't need to consider me required! — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD4YD6J6UI5RVSHANFMYSLZJA5TZAVCNFSM6AAAAABHL53TX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHA4DKOBVHE>. You are receiving this because you are subscribed to this thread.

[codehag]

Since im in CEST its a little hard for me to attend, but since I am not critical for this meeting beyond organization feel free to exclude me.

[mcoblenz]

Would it be better to defer until after Elango gets back from vacation? I’ll be available then too. Michael

…

On Jun 26, 2024, at 8:17 AM, yulia ***@***.***> wrote: Since im in CEST its a little hard for me to attend, but since I am not critical for this meeting beyond organization feel free to exclude me. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD4YD24S2VK73DMGNEEH2DZJLLPVAVCNFSM6AAAAABHL53TX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJRHE3TENBSGM>. You are receiving this because you are subscribed to this thread.

[echeran]

I don't mind touching base for 30 mins tomorrow before vacation, just so I can get a better sense of what I should do to be properly useful here.

I set up a Meet meeting at 10am Pacific Time tomorrow (6/28) if that works, happy to move the time around, or we can just defer until 3 weeks later.

On Monday in our weekly meeting, @eemeli mentioned that you would be interested in knowing specific items that we're wanting feedback on. @aphillips pointed out that our wiki page "Things that Need Doing" has a section pointing to the repo issues that are marked as being feedback on our Technical Preview implementation.

[mcoblenz]

I can do 30 minutes tomorrow but only 30 minutes, since I have another meeting at 11. Where can I find the meeting link? Michael

…

On Jun 27, 2024, at 2:58 PM, Elango Cheran ***@***.***> wrote: I don't mind touching base for 30 mins tomorrow before vacation, just so I can get a better sense of what I should do to be properly useful here. I set up a Meet meeting at 10am Pacific Time tomorrow (6/28) if that works, happy to move the time around, or we can just defer until 3 weeks later. On Monday in our weekly meeting, @eemeli <https://github.com/eemeli> mentioned that you would be interested in knowing specific items that we're wanting feedback on. @aphillips <https://github.com/aphillips> pointed out that our wiki page "Things that Need Doing" <https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing> has a section pointing to the repo issues <https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3APreview-Feedback> that are marked as being feedback on our Technical Preview implementation. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD4YD3MYPLNXHRSQ4FPJJDZJSDIZAVCNFSM6AAAAABHL53TX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJVG4ZDOMJUGM>. You are receiving this because you are subscribed to this thread.

[echeran]

Here it is (forgot to paste it): meet.google.com/tuf-eupk-qsg