Design questions for Rosetta 2.1

[jbphet]

In the previous iteration (Iteration R2, from May 15 thru June 4 2025), a team was assigned to spend some time thinking about how to extend Rosetta to support translation of a11y strings, and to do some early prototyping of our ideas. This work is now going on the back burner for a while, and the team would like to capture some UX design questions that have come over the course of this effort. Below is this list of design questions that came up.

This issue should be used to record any decisions made on these questions, but separate issues should be logged for any implementation steps. A checkmark in this list means that the question has been answered, and not that it has been implemented.

• Should the a11y strings be in a separate section within each of the major translation form sections (sim-specific, shared, and common) or should they appear with the strings for the component with which they are associated when possible?
• Do the a11y strings (or all strings) need comments that describe their context? Or other metadata that would be displayed in the UI to indicate their purpose? (i.e. - this string is for Voicing, this string is for Interactive Description, and so on).
• What kind of supporting materials should we have in the user interface for translators? Links to information about Fluent syntax? Links to what accessibility and screen readers are? Descriptions about how users will discover this content?
• We are thus far assuming that showing the a11y strings is off by default, and translators will need to opt in by doing something like checking a checkbox. Agreed? The motivation here is that there are generally more a11y strings than visual ones, and they are often much longer, so it will look like a log more work and we don't want to overwhelm the translators.
• We are assuming that the percentage complete indicator for each sim in the translation report should have a separate number for the a11y strings so that these values don't all drop from something like 100% to something like 20%. Agreed?
• How should we allow translators to test the a11y strings? The two options that we've come up with so far are to use the a11y in much the same way that the current "Test" button works, or to have a more in situ button that allows translators to see all permutations of the a11y string for which they've entered a value.
• Should there be an "Accept All" option for the AI-generated strings, or should a translator have to review each string individually and accept it? The former sounds good, but may lead to translators just pressing the button and not taking the time to do a quality job, while the latter may be daunting and lead to translators just skipping the a11y strings.
• What kind of validation is required for fluent patterns, and how do we present that to the user? Does the interface look like a code editor with syntax highlighting?

[jbphet]

I'm going to assign this to @AgustinVallejo and @jessegreenberg to review and add anything else that they can think of (please edit the list above rather than add new comments if you have something to add), and to @marlitas because she wanted to see it for planning purposes. Once they've all reviewed and potentially commented, please set this to "deferred" and we'll pick this up in a few months when it becomes a priority again.

[AgustinVallejo]

Looks good to me. Unassigning.

[samreid]

Self-assigning to review, thanks!