feat: Command lang:find behavior with parameters

[neznaika0]

Now, when scanning the application files, only "clean" translation keys will be added. For example, lang('File.key') but not lang('File.key', [$val]) lang('File.key', [$val], 'de')

It would be good if such options could be processed. I'm not sure about the final result yet, I'll leave this task as a reminder.

• If you learn to recognize all these variables, you can improve the translation hints.

'key' => 'File.key {0} {1}'
'key' => 'File.key {name} {date}'

• Identify the selected locale

[kenjis]

I know this is a bit late, but isn't it a bug that this command can't find lang() with parameters?

[neznaika0]

Initially, I did not plan this. There are many options for "gluing" the function lang("App." . $langKey . $optionKey), etc. Main mode is to search for clean keys.

[kenjis]

Code like lang("App." . $langKey . $optionKey) is not good. We cannot know the key unless we run the code.
I think few users write such code.

But code like lang('Tests.apples', [3]) is more common. It is documented.
https://codeigniter4.github.io/CodeIgniter4/outgoing/localization.html#replacing-parameters

[neznaika0]

I personally write this code.
That's why I implemented lang:sync - not all translations can be found automatically.

        $groups = [
            self::USER  => lang('UserGroup.role.' . self::USER),
            self::ADMIN => lang('UserGroup.role.' . self::ADMIN),
        ];

Your second example is also not absolutely correct. Most likely lang('Tests.apples', [$val])

I still haven't found a good solution to the problem.

[kenjis]

Yes, lang('Tests.apples', [$val]) would be actual code.

How about this?

--- a/system/Commands/Translation/LocalizationFinder.php
+++ b/system/Commands/Translation/LocalizationFinder.php
@@ -192,7 +192,7 @@ class LocalizationFinder extends BaseCommand
         }
 
         $fileContent = file_get_contents($file->getRealPath());
-        preg_match_all('/lang\(\'([._a-z0-9\-]+)\'\)/ui', $fileContent, $matches);
+        preg_match_all('/lang\(\'([._a-z0-9\-]+)\'/ui', $fileContent, $matches);
 
         if ($matches[1] === []) {
             return compact('foundLanguageKeys', 'badLanguageKeys');

If you want a perfect solution, I think the following is better:

• remove lang command to a Composer package
• parse PHP code with nikic/PHP-Parser to find lang() function

[kenjis]

Another feature request.
It would be nice that the command can find the case in codeigniter4/shield#1159.
When there are placeholders in messages, and lang() does not have proper arguments,
the command shows the lang() without proper arguments.

[neznaika0]

Yes, this case is stated in the first message.
I have not studied the parser. It can probably be done .

[rozpuh]

Doesn't work with Cyrillic

[neznaika0]

@kenjis wrote:

parse PHP code with nikic/PHP-Parser to find lang() function

We discussed the situation when CI4 is installed from the archive. How do I use PHP-Parser?
If there is a parser, then there will be a php-cs-fixer 😐

[kenjis]

I think if you really use PHP-Parser, you should create a Composer package for this command.

CI4 still supports Zip installation, that is no Composer at all.
So if we really add the feature that depends on PHP-Parser, we need to add PHP-Parser in system/ThirdParty/.
However, I don't think the members would like to add such a huge development library to ThirdParty.

[neznaika0]

It's a good option. But it will be an unofficial package. I won't be able to support on github.