Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Principles #50

Closed
stasm opened this issue Feb 17, 2020 · 2 comments
Closed

Design Principles #50

stasm opened this issue Feb 17, 2020 · 2 comments
Labels
design Design principles, decisions

Comments

@stasm
Copy link
Collaborator

stasm commented Feb 17, 2020

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. Brittle Strict (#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?
@DavidFatDavidF
Copy link
Collaborator

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"..

@DavidFatDavidF DavidFatDavidF added the requirements Issues related with MF requirements list label Jul 27, 2020
@mihnita mihnita added design Design principles, decisions and removed requirements Issues related with MF requirements list labels Sep 24, 2020
@aphillips
Copy link
Member

This no longer seems to track anything, even thought we've spent a lot of time on these topics. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design principles, decisions
Projects
None yet
Development

No branches or pull requests

4 participants