Design Principle: DRY vs. WET

[stasm]

A dedicated issue for discussing one of the design dimensions proposed in #50.

DRY vs. WET

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?

[Fleker]

A middle ground could be considered as DAMP (Descriptive and Meaningful Phrases). Extracting out common logic can be a good idea for removing redundancy, but keeping enough in each message to still be meaningful (~1 level of abstraction). This may mean there is still some redundancy at times.

[aphillips]

There are two questions: do we support factoring and do we encourage (or discourage) factoring?

One of the design tenets I favor is: "it is difficult to write a translation unit that is not a complete thought". That is, we promote the creation of complete semantic unit strings instead of string concatenations. This often requires a higher level of repetition than software developers like. For example, instead of this:

"you have {numChances, plural =0 {no more chances} one {one more chance} other {# more chances}} remaining"

We require people to write:

{numChances, plural =0 {you have no more chances remaining} one {you have one more chance remaining} other {you have # more chances remaining} }

The reason I mention this here is that there is a tendency to for developers to want to write grammatically suspicious messages by using "shared" or "common" translations inline:

Welcome to your new {productName} 
// where productName == phone, tablet, app, TV, etc.
// inclusion of brand names obfuscates this,
// e.g. Fire phone, Fire tablet, Kindle, Kindle app, and FireTV are all terminology
// but aren't any better/simpler grammatically

Redundancy is good when it results in high-quality translations.

At the same time, its helpful if the source can do complete string references (press [buttonLabel] to continue or maybe When you see the message <b>[someMessageId]</b> the process is complete).

So I guess I would say we should support it but discourage its use.

[zbraniecki]

That's exactly where I stand. Changing data model and/or syntax is very costly for individual projects and for the industry.

Therefore I'm a strong proponent of very permissive data model and very open ended at syntax and all limitations to be placed on top.

An example with full sentences vs chunks - at Mozilla we strongly encourage full sentences. In the future we may add linters to warn on that. But we may also, one day, find out that we need chunks - Siri examples are a good intro as to why. Then, changing our tooling to enable and support it will be many orders of magnitude easier than trying to extend data model or syntax to support it. Or starting work on next-gen localization system that will support it.

That thinking leads to the AST as Fluent has with generic varian selectors with mandatory defaults to aid error recoery, open ended function calls and arbitrary extendible arguments and primitive literal types.

Dave Herman when advising us on Fluent design used the phrase "never design the data model / syntax to teach your users what you consider best practice". I'd like to put best practices and tunable linters on top of the data model. Those may survive or be replaced within 1-5 years. I'd like the data model to aspire to survive 10-20 years into the future of software industry that we cannot predict.

[asmusf]

On 3/2/2020 12:18 PM, Zibi Braniecki wrote:

Dave Herman when advising us on Fluent design used the phrase "never design the data model / syntax to teach your users what you consider best practice".

Without contradicting this advice, I want to note that it is diametrically opposed to some statements made here by others. Looks like there should be formal discussion/consensus by the group on this.

I must admit that I feel some sympathy with the confusion that people face when presented with seemingly equivalent choices. So, I would push back on choice for the sake of choice (assuming it can be determined whether it is that).

On the other hand, I find the argument about not locking down a single model/way of doing things on the syntax or data model level quite persuasive.

If we collect a useful set of "typical" use cases (varied by language, but also by approach to localization) then we could perhaps better judge what things we shouldn't rule out by design.

[zbraniecki]

I also see that there may be contradicting opinions to mine within this group. Another thing is that it's a spectrum not a binary choice. I'm open to kick off a thread about it if stas thinks this is not a subset of one of his design principles.

[asmusf]

On 3/2/2020 1:53 PM, Zibi Braniecki wrote:

I also see that there may be contradicting opinions to mine within this group. Another thing is that it's a spectrum not a binary choice. I'm open to kick off a thread about it if stas thinks this is not a subset of one of his design principles.

We just need to find out where the group consensus is on that one, so we can avoid being at cross-purposes.