-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
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. |
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:
We require people to write:
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:
Redundancy is good when it results in high-quality translations. At the same time, its helpful if the source can do complete string references ( So I guess I would say we should support it but discourage its use. |
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. 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". |
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.
|
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. |
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.
|
Uh oh!
There was an error while loading. Please reload this page.
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?
The text was updated successfully, but these errors were encountered: