Potential translation cache warm-up in boot() via eager __() call (affects later package JSON paths)

[jaimercz]

Hi! First, thank you for maintaining this package.

I ran into a translation interoperability issue in a Laravel 12 app with multiple packages that register JSON translations via loadJSONTranslationsFrom().

In Rinvex\Country\Providers\CountryServiceProvider::boot(), these lines call __() immediately while booting:

__('validation.invalid_country')
__('validation.invalid_currency')

Because __() triggers translator JSON loading (//$locale) and Laravel caches loaded groups in-memory, this can happen before other packages add their JSON paths. In that case, later-added package JSON translations may not be considered for that request lifecycle.

Observed behavior

Package A boots first and calls __() in boot().
Package B boots later and calls loadJSONTranslationsFrom(...).
JSON keys from Package B are not resolved via __() unless translator loaded state is reset.

Expected behavior

Package B JSON keys should be available even if another package called __() earlier in provider boot.
Why I think this package contributes

The eager __() calls in boot() can be the first translation access in the lifecycle.
This is not “wrong” in isolation, but it can trigger ordering-sensitive behavior with other packages.

Suggestion

Would you consider avoiding eager translation resolution during provider boot()?
For example, defer translation resolution until validation message rendering time, instead of translating at rule registration time.