Closed luisprmat closed 3 years ago
I will do a check too
I thought it seemed to me :-)
In the near future I will check and will check the keys from the previous version.
@luisprmat, @caouecs, I know why this happened:
v9.1.1:
v10.0.1:
The locale.json file splitting script works like this:
locale.json
file are loaded into a variable;nova.json
;nova.json
file;nova.json
file with the original ones;nova.json
file;The script removes lines like Reset Password Notification, since it is already used in nova.json
.
The problem is that the Laravel framework does not have a json file with translations.
Therefore, we do not know what keys should be left in the locale.json
file.
What you can do: now we have a script that scans Jetstream and Fortify projects, collects keys from them for translations and saves them to files. I can load the Laravel Framework dependencies and do the same with it. At the moment, this is the only option to get a complete list of these keys, since the script does not know which keys it needs to recover.
Another option: I can find all translation keys, save them to a file and merge them with the current files. It will be the same, but the project will not need to be installed when running phpunit and deploying the project locally.
I know how to solve this problem.
A little later we will create a PR.
Hm...
Oh no
appears in this view in Laravel 8.
Yes, I have already found and deleted my unnecessary messages 😅
I will do this:
Current state after searching for keys in laravel/framework
project:
Are they not very few? About these?
We must bear in mind that some translations do not wrap strings directly but rather variables that contain strings. For example:
$message
variable through the constructor method (line 27) and later translated from this view (line 5) __($exception->getMessage() ?: 'Forbidden')
Since these strings it was always possible to translate them from previous versions I don't see why now they should disappear
@luisprmat, should not.
The problem is that we have added translation keys nova, jetstream, fortify and others to one file.
From a code point of view, after splitting a file, it is not known which keys should remain in the main file.
This is precisely the current problem.
The screenshot above is what the parser was able to find.
This is why I will manually search for other translation keys in order to recreate the original file.
Only after that I will restore the translation of the lines that were lost during the upgrade from 9 to 10 version.
Hey @andrey-helldar,
did I understand correctly that the error occurred only when splitting the files (from V9 to V10) and when adding new packages that also have duplicates to other packages, this error will not occur in the future? When adding new packages, the error with duplicates should not occur.
Wouldn't it be easier to optimize the splitting script (applied to V9) and apply it again to V9 (with subsequent merge to V10)? Just a quick thought from me, without understanding exactly what happened.
@ottenso, yes it is a separation problem. I'm working on it.
The easiest way is to return the state of the files before we added the Nova and Jetstream translations to it.
Description:
Using the translations in a new project I was able to observe that some translations that were already correct have been lost.
Some of them are:
The above translations were present in the version 9.1.2 in
source/en.json
Everything seems to indicate that they are the translations wrapped in
Lang::get('...')
and@lang
directive that I referred to in this commentSteps To Reproduce: