Replies: 3 comments
-
I confirm that this is an unobvious mechanic. But it works this way to maintain backwards compatibility. At the same time, Laravel 10 will also contain this mechanic: framework/src/Illuminate/Foundation/Application.php Lines 326 to 332 in d7cdf5c |
Beta Was this translation helpful? Give feedback.
0 replies
-
Just got burned by this issue and finding this post was a lifesaver. I think this oddity deserves an explicit mention in the docs. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Documentation for 9.x states that translations are stored in lang/[locale-id]/[group-id].php (https://laravel.com/docs/9.x/localization#introduction).
Further it states, that to override specific translation keys one can place them into resources/lang/vendor/[vendor-id]/[locale-id]/[group-id].php (https://laravel.com/docs/9.x/localization#overriding-package-language-files)
So I would assume that lang/... keys are used if they are not overridden by resources/lang/vendor/...
Problem is, that as soon as I have some translations overwritten, laravel no longer uses lang/[locale-id]/... for default translations, but resources/lang/[locale-id]/... which breaks all default translation keys. I haven't found this behaviour documented in https://laravel.com/docs/9.x/localization but looking at the code one can confirm:
framework/src/Illuminate/Foundation/Application.php
Lines 326 to 331 in 8bcd484
As long as resources/lang directory exists, it is used to search translations in and lang/ is not used anymore. This smells like a bug to me, as the documentation clearly states that default translation lives inside lang/ and not resources/lang. Am I missing something or should I create a bug issue?
best
Martin
Beta Was this translation helpful? Give feedback.
All reactions