Design Principles
Localization is an essential part of the user's experience. The localizers should have control over the translation and be able to adapt it easily to the circumstances and external arguments.
Each language is isolated and the localization logic of one language doesn't leak into other other languages nor into the source code.
Simple things should be simple. Complex things can be possible. The syntax used for describing translations should be easy to read and understand. At the same time it should allow, when necessary, to represent complex concepts from natural languages like gender, plurals, conjugations, and others.
The syntax is designed for reading first, editing second, writing from scratch last. A localizer not familiar with it should be able to write their own translation by looking at other translations in the file and copying-and-pasting.
Be liberal in what you require but conservative in what you do
The syntax should allow good error recovery: an error in one message should not break the whole file. The parser should resume normal parsing as soon as possible and with as few losses as possible.
Translations are objects with values and additional data which can be mapped to attributes of UI widgets and components.
Fluent is a toolbox of small independent modules. Each module does one thing and does it well. Modules can be used by third parties to build higher-level abstractions. Fluent itself builds on top of established resources like Unicode, ICU and CLDR.
(…) we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The less powerful the language, the more you can do with the data stored in that language.
Less powerful systems are easier to secure, are more flexible and allow more use-cases. Fluent should be not be powerful. The syntax should be declarative and easy to parse. The API should be simple, unopinionated and atomic — it's low-level and can't be broken apart, and can be used to build higher-level abstractions.