Skip to content

feat: [Commands] lang:find show bad keys when scanning #8149

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

Closed
wants to merge 2 commits into from

Conversation

neznaika0
Copy link
Contributor

Description
I tried to add a list of bad keys when scanning.
Now this is not exactly what @kenjis was talking about, but it's still better than nothing
Example:

$ ./spark lang:find --dir Controllers/Translation --verbose

CodeIgniter v4.4.3 Command Line Tool - Server Time: 2023-11-04 08:23:17 UTC+00:00

File found: Controllers/Translation/TranslationNested/TranslationFour.php
File found: Controllers/Translation/TranslationOne.php
File found: Controllers/Translation/TranslationThree.php
File found: Controllers/Translation/TranslationTwo.php
Files found: 4
New translates found: 0
Bad translates found: 5
+---+------------------------+
| № | Bad key                |
+---+------------------------+
| 0 | TranslationTwo         |
| 1 | .invalid_key           |
| 2 | TranslationTwo.        |
| 3 | TranslationTwo...      |
| 4 | ..invalid_nested_key.. |
+---+------------------------+

All operations done!

Originally posted by @kenjis in #7896 (comment)

I say on removing lang() from the code, or changing the argument.
E.g. lang('Cache.unabelToWrite')lang('Cache.unableToWrite')
Cache.unabelToWrite is gone (but not deleted in the lang file), and Cache.unableToWrite is added.

I want to say, if there are items in the lang files that are not used by lang(),
it seems better to have a way to know them.

Checklist:

  • Securely signed commits
  • Component(s) with PHPDoc blocks, only if necessary or adds value
  • Unit testing, with >80% coverage
  • User guide updated
  • Conforms to style guide

@kenjis kenjis added enhancement PRs that improve existing functionalities 4.5 labels Nov 5, 2023
$tableBadRows[] = [$key, $value];
}

CLI::table($tableBadRows, ['№', 'Bad key']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you need the No. for? I want the file paths.

Suggested change
CLI::table($tableBadRows, ['', 'Bad key']);
CLI::table($tableBadRows, ['', 'Bad Key']);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The number is just for understanding which line. I think file paths are not an option to show. Since one language key can be in ~1000 different files. How do you see it?

Copy link
Member

@kenjis kenjis Nov 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a bad key is used in 1000 files, then those 1000 locations should be shown.

No. Bad Key File
1 BadKey1 path/to/file1.php
2 BadKey1 path/to/file2.php
... ... ...
1000 BadKey1 path/to/file1000.php

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, I'll try to do it.

Comment on lines +373 to +374
$foundLanguageKeys[0] = array_replace_recursive($findInFile[0], $foundLanguageKeys[0]);
$foundLanguageKeys[1] = array_merge($findInFile[1], $foundLanguageKeys[1]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The variable names are difficult to understand. Don't use [0] or [1].
Name meaningful variable names.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good. this is because the function returns multiple values instead of one

@neznaika0
Copy link
Contributor Author

Do you have a suggestion on how to check existing translations from app/Language/? Should there be a separate lang command:validate, because the current code will be too large if you create the --validate flag?

@kenjis
Copy link
Member

kenjis commented Nov 8, 2023

@neznaika0 neznaika0 closed this Nov 9, 2023
@neznaika0 neznaika0 deleted the lang-find-show-bad-keys branch November 9, 2023 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement PRs that improve existing functionalities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants