[POC/WIP] ability to see original content from translated attributes #4262
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHY
BEFORE - What was wrong? What was happening before this PR?
As reported in #4100 our translatable fields have a stange behaviour.
en
value is there pre-populated. You could think: ok, nice, it kinda helps to know the english value for translation, but it's something you don't want translated in that language, so you just clear the field, and submit the form.If you go to the database, you will see that you have both keys
en/fr
and thaten
has value andfr
is null, as is expected.But if you open that same entry to edit in
fr
again, you will see that the sameen
value is populated. If you notice you can just delete it again and save, but if it's in other tab and you hit save without checking that you will have thefr
translation with theen
translation.AFTER - What is happening after this PR?
This PR aims to provide a away to don't pre-populate un-translated fields, but easy enough to get the translations.
HOW
How did you achieve that, in technical terms?
Read
trait.getTranslation
will assume that empty, null or not present is the same as not beeing translated, so it get the value through the fallbacks.Is it a breaking change or non-breaking change?
I think it is, not that I think the previous behaviour was ok, so this can also be seen as a fix.
How can we test the before & after?
Use the simple example I gave, it's very easy to spot this problem.
Disregard completely any code refactoring / functionality etc. This is a POC for us to discuss if we should aim for a solution like this.