Skip to content

Design Principle: DRY vs. WET #62

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

Closed
stasm opened this issue Mar 2, 2020 · 6 comments
Closed

Design Principle: DRY vs. WET #62

stasm opened this issue Mar 2, 2020 · 6 comments
Labels
design Design document or issues related to design resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. Stale Obsolete?

Comments

@stasm
Copy link
Collaborator

stasm commented Mar 2, 2020

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?

@stasm stasm mentioned this issue Mar 2, 2020
@Fleker
Copy link

Fleker commented Mar 2, 2020

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
Copy link
Member

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
Copy link
Member

zbraniecki commented Mar 2, 2020

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
Copy link

asmusf commented Mar 2, 2020 via email

@zbraniecki
Copy link
Member

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
Copy link

asmusf commented Mar 2, 2020 via email

@mihnita mihnita added the design Design document or issues related to design label Sep 24, 2020
@aphillips aphillips added Stale Obsolete? resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. labels Aug 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design document or issues related to design resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. Stale Obsolete?
Projects
None yet
Development

No branches or pull requests

6 participants