message-format-wg
message-format-wg copied to clipboard
Design Principles
As we gather the requirements, I'd like to start the discussion about something slightly broader: design principles. By that I mean statements and guidelines which we want to follow and encourage as we make decisions about the standard. The principles will help establish what it means for a decision to be "idiomatic" or "aligned" with the goals of the working group and the new standard.
To start the discussion, I'd like to list a few dimensions (or spectra) which have accompanied Fluent's development. In many cases, I wasn't sure if my choice of wording was correct; please feel free to suggest alternatives! Also, I'm sure there are more!
- Computational vs. Manual (#60)
- Do we want the runtime to have some capacity to transform translations, e.g. by providing a method to automatically turn text to title-case? Or do we want localizers to provide all possible variants of translations to ensure all edge-cases are handled manually?
- Developer Control vs. Localizer Control (#61)
- How much logic do we want localizers to handle? The more control they have, the more expressive translations they can build, at the cost of increased complexity.
- DRY vs. WET (#62)
- Do we prefer to factor common translations or logic out for re-use in multiple messages, or do we accept some redundancy for the benefit of reduced complexity?
- Resilient vs.
BrittleStrict (#63) - How far do we want to go to provide fault tolerance in case of runtime errors (an error in a formatter, a missing variable, a mismatched selector, etc.) and syntax errors (unclosed placeable, missing delimiter, invalid comment sigil, etc.)?
- People-Friendly vs. Machine-Friendly (#64)
- If we end up defining the syntax for messages, who should the target group be? Do we expect people to read it? Edit it? Write it from scratch? Are those people developers, project managers, localization engineers, linguists, translators?
I believe we are in need of some more general design principles before we start addressing some of the features related to the above stated axes, such as #60 I believe that based on #59 being closed as of last month, we can conclude that forwards and backwards compatibility as well as capability of localization roundtrip are some important general design principles that should precede specific diving into any of the "feature knobs"..
This no longer seems to track anything, even thought we've spent a lot of time on these topics. Closing.