Fallback to default locale with numeric field is not working as expected

[rampol]

First of all, congrats and thanks for this great package!

You must be wondering why to translate a number: what I'm trying to achieve is to track the completion of translations with a boolean (tinyint) field, which is translatable. When the user has finished the translation of that article, he will check the "translation is ready". The best place to store that field is into the translation itself. So, we're translating a number, but it doens't work when translation fallback is active. It shows always the value of the main record, no matter what value is stored into the DB.

To reproduce the issue:

• Translation fallback is active.
• I create a record in the default language, and assign a value to this field, let's say 1.
• I create a new record in another language, and assign a value 0 to this field. This last value is stored correctly into the DB.
• When I edit this last record again, the fallback is triggered, when it shouldn't (because this record has already a translation), and brings the value 1 (from the record we first created), when it should be the 0 stored in the DB.

Strangely, the same happens when I use a text field and the value is numeric. The fallback fills this field with the value stored in the original language (even when the translation exists).

As a workaround I'm using a text field with "y" or "n" and everything works fine.
Did anyone find this problem?

[Gummibeer]

Hey,

thanks for your thoughts. This behavior was already described in #393 - like said there the major issue is how PHP handles weak comparison.
If you want to stick to tinyint you should be able to use 1 & 2 or all other non false values.

It's sometimes good to get back to old issues after some time. The best solution to this atm is to use a dedicated method isTranslatableAttributeEmpty($key, $value). By default it could hold the current logic but every developer could override it and adjust the logic. Also per field because the key is passed. This would prevent a BC Like using type safe comparison by default or only checking for null.

[rampol]

Thank you so much @Gummibeer for your quick and enlightening answer. Sure, somewhere must be placed a comparison == instead of the strict ===. With your help I'm able to move forward. Thanks again!

[Gummibeer]

https://github.com/dimsav/laravel-translatable/releases/tag/v9.5.0