Closed PedroTeixeira-unP closed 2 months ago
BOOM! Your first PR with us, thank you so much! Someone will take a look at it shortly.
Please keep in mind that:
Thank you!
-- Justin Case The Backpack Robot
Hi @pxpm, thank you for the reply
I believe there's a valuable use for this feature.
While allowing autofill for other languages may sometimes result in inaccuracies in the translations, in certain scenarios, leaving these fields empty is not ideal.
Having the ability to fill the translations might be a beneficial option, in my opinion.
I will also check those PR's 👌
While allowing autofill for other languages may sometimes result in inaccuracies in the translations, in certain scenarios, leaving these fields empty is not ideal.
This are the scenarios I want to know more about, can you elaborate please ?
Is it necessary to set the text on the other translation keys, or just init the translation keys ? I mean:
- [{pt: "ola", en: "ola", fr: "ola"}]
+ [{pt: "ola", en: "", fr: ""}]
I believe at the moment we only store [{pt: "ola"}]
right ?
Let me know more about it.
Cheers `
Hey guys,
I also don't think this is a good idea, so I'm going to close the PR. Storing title.fr => 'Olá tudo bem'
in the database should NOT be supported, because it breaks database integrity. The database no longer has correct information, it has false information.
For use cases where this is a good idea, I think the developer should implement workarounds on the PRESENTATION side, NOT the database side. For example, they can do something like $product->title['en'] ?? $product->title['fr'] ?? $product->title['fr']
. Personally, I would create a method in the Model that would return ANY translation, something like $product->any('title')
. That would fix my use case on the presentation side, and still have the DB information correct. If I want to understand what has been translated and what not... I can still do that.
Hope the explanation helps. Cheers!
WHY
BEFORE - What was wrong? What was happening before this PR?
On crud creation it wouldn't set the translations to all the available languages, leaving blank spaces
AFTER - What is happening after this PR?
This PR gives the option assign the current field not only into the current user lang but all the available
HOW
How did you achieve that, in technical terms?
A config field to disable/enable this option. If true it fetches all the available languages and it loops by them
Is it a breaking change?
No, in case the config key doesn't exists the code will keep the current/old method running
How can we test the before & after?
Create a new entry where there's a translatable field Change the config key between true/false