Incorrect translation passed when exact match is missing, but prefix key exists

[Yinci]

I would have put this in issues if it was open...

Context:
Within my form request I have a custom rule that handles location data. I also have a rule to handle house number extensions. House number extensions are not relevant for my location data, and are validated separately. This results in 2 attributes:

• correct_location (an array of all data)
• correct_location.house_number_extension (a single item within the array)

The location rule translates using a custom rule within my validation files. The house number extension is validated as if, using an attribute. This results in me only having an attribute translation for
correct_location.house_number_extension. This has been imported into the database.

The issue:
When the validation for correct_location fails, the Validator will find the translation and replace attributes and what not. However, the overlaying translator from this package that checks the database doesn't seem to care if a key is only a prefix. Within the database, there is only the key for correct_location.house_number_extension. However, the translation loader seems to think that this is the translation I'm looking for, and so cuts the prefix, and returns the suffix in array format. This results in:

[
    'house_number_extension' => 'Huisnummer toevoeging',
]

while if I wasn't using the translation loader, it would return null (like I'd expect it to).

This causes a mb_strtoupper expects parameter 1 to be string, array given exception, when the Validator is trying to replace attribute placeholders.

Temporary fix:
By adding correct_location as translatable attribute, it will return that value and won't have an exception when trying to replace the non-existing attribute placeholder in my custom rule.

Versions:
Laravel: 7.30.4
Spatie/laravel-translation-loader: 2.7.0

[Yinci]

Even with the exact match in the database, it will still sometimes prefer the wrong key => value