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]

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

[pxpm]

Hey @PedroTeixeira-unP thanks for the PR, really appreciated.

I am trying to understand if this is a good thing to do, at the moment I don't think this should be done.
I have two main reasons that believe are show stoppers, unless I am wrong:

• 1) We will have "misleading" information in the database. The title.fr => 'Olá tudo bem' is not very accurate is it ?
• 2) You lose the ability to know what languages are translated and what are missing, because everything will be "translated" by default.

Having this behind a configuration does not worry me, I know it will be safe.
But I am not seeing the use case where having all keys with the same translation on the database would be a nice thing to have.

I think I may get the reason why you want to do this, correct me if I am wrong, but the intention is to when you edit the entry in other locales you have the "native translation" there ?

If that's the case I agree with you, it's a pain point at the moment. We already have some PR's and discussions open to address that:

• Translatable with fallbacks #4267
• Allow manual translating field attributes #4271

Is that something that would work for you ?

Let me know more, so that we merge/close this and/or prioritize those PR's I mentioned.

Cheers

[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
`