-
-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add translation helper shell script #2332
Add translation helper shell script #2332
Conversation
I did not do any sort of CSV clean up, but maybe someone else wants to take the lead on that. For example, adding missing translations or maybe removing translations that aren't used. Edit: One warning about possibly removing unused translations, it's possible as mentioned in the previous comment that there could be some usages of calling |
Wow nice work! Will review when I get the time. |
I don't know much about github actions, but maybe this could also be used for one to check that translation strings have been included if necessary. |
wow this is great also for multistore development! |
have you checked if n98-magerun has sth similar already? |
@tmotyl I did look but I don't see anything like it:
|
As mentioned in #2333, I added a new mode to find deprecated usage of the global # list deprecated usage only
php shell/translations.php deprecated
# fix deprecated usage, DO NOT RUN IN PRODUCTION
php shell/translations.php deprecated --fix |
This is an interesting PR and thank you for your contribution @justinbeaty. If I look at its description in the Questions or Comments section, I see that there are 422 unused strings and 85 missing strings. That is a problem. I'll take a look to see what it's all about. For the deprecated option there is also a fix option. Running the command what is done cannot be reversed. We should evaluate if it is possible to make a backup of the files beforehand. If it is not possible, then a warning message must be mentioned to make a backup. We have to check where these changes are and find the parent directory of the files. If there are issues, either put all the files back in place, and if he uses Git he can do a revert. |
Ideally someone should not just blindly run the
I am not sure if we are responsible for backing up files for someone not using git and deploying directly to production. But if there's a better warning or other way to prevent accidental changes we can add it. |
As mentioned in #2429 I think a new mode can be added such as:
This mode would allow us to change the first column in en_US csv files when we change a translation string. It would be required to add an entry to this shell script so that we can simply find/replace the changes. In other words, take this example: "Password must be at least of %d characters." We can instead fix that in both columns and also put in this shell script something like: $upgrades = array(
"Password must be at least of %d characters." => "Password must be at least %d characters.",
); And when the user runs Thoughts? Feedback from others who use non-english language packs is appreciated. This would be a new step users must take during upgrades. |
Column 1 is what is used in PHP/PHTML files. It is obvious that we must pay attention to column 2. And then the modification should occur on column 1 of the CSV, but once we modified it must have a correspondent in the PHP/PHTML file. PHP/PHTML FILE => COLUMN 1 CSV => COLUMN 2 CSV To remain Column 2 then the process must be reversed. |
Let me try to re-explain what I propose. When we want to change a string, we can do so in the PHTML files and also in both columns in the en_US csv files. This keeps everything consistent in our source code. At the same time, we add an entry to translations.php shell script such that it will find/replace in all translation packs the old string with the new string. So when a user upgrades to a new OpenMage version, they just have to run the script to fix what we broke in their translation files. The only negative is that they need to be aware of having to run that script. |
I understand what you mean. I haven't tested the script yet, but I will, including in destructive mode to see what happens and how such a "mistake" can be fixed. |
I'm pretty sure something like this already exists. If not in n98-core, maybe as addon? However, I'll test this later :) |
I'd like to have 3 further repos at OpenMage ...
These shell scripts are not needed for production ... just install them with |
created the repos and set you as admin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can approve this first (for better history) and then apply #2853
Description (*)
Because in #2317 I lost track of which translation strings I introduced, I wrote a quick helper script for me to find strings used in the
__
function or in XML files but not defined in a CSV file. I thought it would be useful so I fixed it up a bit and added it asshell/translations.php
.It has two modes,
missing
which will tell you which strings you must add to a CSV file, andunused
which will print strings defined in CSV files but not apparently used anywhere in the source. Additionally, it lets you pipe in a list of files to only check, which is useful to test PRs.Related Pull Requests
Fixed Issues (if relevant)
Manual testing scenarios (*)
php shell/translations.php missing --verbose
to see php, phtml, or xml files that used non-defined translationsphp shell/translations.php unused --verbose
to see CSV files that have unused translationsQuestions or comments
It could be possible that the code to find usage of the
__
function is not perfect, such as__('Total: ' . $total)
would only pick up'Total: '
, but I don't think that's used often, or shouldn't be, as the%s
usage is preferred.Contribution checklist (*)