Revert return value change when column value is null

[vencelkatai]

Hi,

• I've noticed that PR Allow configuration for handling null and empty strings in translations (Fixes #456) #465 changed the default behaviour and now getTranslation returns null instead of an empty string when the column value is null.
• This change also causes attribute mutators to not run in this case, which makes some use-cases impossible that has been working before. (Partially caused by my previous PR Fix attribute mutators #470 since it corrected this behaviour.)

I've removed the modifications from getTranslation and modified the test to reflect that.
I've also tested the modified test in a prior version (6.8.0) to verify that the return value was an empty string before.

Fixes #473

[freekmurze]

Thanks!

[negoziator]

Thanks ✨

[alipadron]

@vencelkatai I'd like to suggest a middle ground where we can both be satisfied. We could make this behavior configurable in the Translatable class. What about adding an option like $returnNullWhenColumnValueIsNull or something similar?

This would allow each developer to decide whether they want to get an empty string or null when the column has no translation.

Additionally, for consistency, we could consider making null the default value, as it's more explicit about the absence of data.

From my perspective, it's inconsistent to return an empty string when the column value is null, as null can be used to indicate that there's no translation, allowing for specific actions based on this condition.

I understand that returning an empty string for null values might work for your use case, but it doesn't align with my mental model.

I spent quite some time trying to figure out why, in models where the column has a default null value (since it's not mandatory), I was getting an empty string as the translation.

I'd be curious to hear @freekmurze thoughts on this regarding the package design.

I am writting this because i believe it's unfair to revert changes without a justifiable cause

Thank you!