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!

[freekmurze]

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 agree with this, and would accept a PR to accomplish this

[vencelkatai]

@alipadron My goal was to fix the issues quickly, I didn't know if the maintainers are open for changing this.

I also agree with you, but I have 2 suggestions:

• I don't think we can return early from that method. People might wanna mutate the null value to something else, like providig a fallback value.
• In your previous implementation it was still inconsistent a bit, having null in the database returned null, but in case of a missing translation it still returned empty string. You have to change the default value here in my opinion to cover both cases:

  laravel-translatable/src/HasTranslations.php

  Line 76 in de81937

  $translation = $translations[$normalizedLocale] ?? '';

[alipadron]

@vencelkatai ok! I will take a look and get back to you if have something!

Thanks for your feedback.

[alipadron]

@vencelkatai Happy New Year! I have found a solution that satisfies our needs.

null Value in the Database Is Not the Same as "Missing Translation"

In your previous implementation, it was still a bit inconsistent. Having null in the database returned null, but in the case of a missing translation, it still returned an empty string.

As I see it, the library has always treated missing translations for locales as empty strings. The issue I tried to address in #456 was about the null value for the column in the database, which I believe is consistent with returning null if the database column value is null.

When I first read what you said, I agreed with you. However, now that I’ve had time to think about it, I realize that these are two distinct cases.

Returning null Early Was a Bad Idea

I don't think we can return early from that method. People might want to mutate the null value to something else, like providing a fallback value.

I agree with you on this, and I’ve found a way to still treat null as a value for translation while ensuring all mutators are called as usual.

Next Steps
I’ll create a pull request and ask for your opinion to see if it makes sense to you. Thanks!