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
-
+1!!!! |
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
Uh oh!
There was an error while loading. Please reload this page.
-
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