Create method locale override

[PedroTeixeira-unP]

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

[welcome[bot]]

BOOM! Your first PR with us, thank you so much! Someone will take a look at it shortly.

Please keep in mind that:

• if this constitutes a breaking change, it might take quite a while for this to get merged; we try to emulate the Laravel release cycle as much as possible, so developers can upgrade both software once; this means a new big release every ~6 months;
• even if it's a non-breaking change, it might take a few days/weeks for the PR to get merged; unless it's a no-brainer, we like to have some community feedback on new features, before we merge them; this leads to higher-quality code, in the end; we learnt this the hard way :-)
• not all PRs get merged; sometimes we just have to hold out new features, to keep the packages lean; sometimes we don't include features that only apply to niche use cases;
• we're not perfect; if you think we're wrong, call us out on it; but in a kind way :-) we all make mistakes, best we learn from them and build better software together;

Thank you!

-- Justin Case The Backpack Robot

[PedroTeixeira-unP]

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 👌

[pxpm]

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 `

[tabacitu]

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!