Add support for pretty-printing PHP files in wp i18n make-php command

[sovetski]

It should resolve this issue: #395

[ernilambar]

@sovetski FYI: You can run Behat test locally easily using commands like:

WP_CLI_TEST_DBTYPE=sqlite composer behat features/makephp.feature:263

This will run behat test of given file and 263 is the line number of your new Scenario. This will be helpful for quick test in local environment. With using sqlite, you don't have to face hassle for MySQL setup.

[sovetski]

@sovetski FYI: You can run Behat test locally easily using commands like:

WP_CLI_TEST_DBTYPE=sqlite composer behat features/makephp.feature:263

This will run behat test of given file and 263 is the line number of your new Scenario. This will be helpful for quick test in local environment. With using sqlite, you don't have to face hassle for MySQL setup.

Thank you, it helped a lot, now the test pass successfully

[swissspidy]

Can we do tabs instead?

[sovetski]

I like using tabs for my own projects, but here as it is something which will be used on other developers IDE, I prefer to use spaces, because tabs configuration depends on the configuration of user. A space will be every time a space, but tab not. Some resources not related to this subject but still on the same issue:

https://medium.com/@peey/what-is-the-inconsistent-use-of-tabs-and-spaces-in-indentation-error-and-why-is-it-caused-f3bbb8b2568b
https://stackoverflow.com/questions/5685406/inconsistent-use-of-tabs-and-spaces-in-indentation

[swissspidy]

I prefer to use spaces, because tabs configuration depends on the configuration of user

That's actually an advantage of tabs :-) But I don't wanna start yet another tabs vs spaces discussion here.

I am mainly suggesting using tabs because that's the WordPress coding standard and IMHO we should be consistent with that.

[sovetski]

Great, in this case I will try to change it to tabs to respect the standards, thanks!

[swissspidy]

The whole function is a bit hard to grasp. What's with the\0 checks here for example, why do we need that? 🤔

[sovetski]

Without that, instead of getting

'You have %d new message' => 'Du hast %d neue Nachricht' . "\0" . 'Du hast %d neue Nachrichten',

we will get

'You have %d new message' => 'Du hast %d neue NachrichtDu hast %d neue Nachrichten',

You explained it on this article: https://make.wordpress.org/core/2024/02/27/i18n-improvements-6-5-performant-translations/#:~:text=Note%3A%20EOT%20here%20stands%20for%20the%20%E2%80%9CEnd%20of%20Transmission%E2%80%9D%20character%20(U%2B0004%2C%20or%20%22%5C4%22%20in%20PHP).%20It%E2%80%99s%20the%20same%20delimiter%20as%20in%20gettext%20used%20to%20glue%20the%20context%20with%20the%20singular%E2%80%82string.

[swissspidy]

My question is why is it doing this here and why is this not needed for the existing, non-pretty var_export() method?

[sovetski]

I don't understand. The command WP_CLI_TEST_DBTYPE=sqlite composer behat features/makephp.feature:263 was working as well, I just removed 1 space and adapted my scenario, I have this error without any explanation:

When I add -vvv it returns an unreadable PHP exception. But the returned error output matches the scenario's expected output, so very weird...

[swissspidy]

When I add -vvv it returns an unreadable PHP exception. But the returned error output matches the scenario's expected output, so very weird...

It sounds like it doesn't match exactly.

When I manually run the wp i18n command in my terminal, I get this output with lots of indentation (8 spaces):

<?php
return [
        'domain' => 'foo-plugin',
        'plural-forms' => 'nplurals=2; plural=(n != 1);',
        'language' => 'de_DE',
        'project-id-version' => 'Foo Plugin',
        'pot-creation-date' => '2018-05-02T22:06:24+00:00',
        'po-revision-date' => '2018-05-02T22:06:24+00:00',
        'messages' => [
                'Foo Plugin' => 'Foo Plugin',
                'Hello' => 'Hallo',
                'You have %d new message' => 'Du hast %d neue Nachricht' . "\0" . 'Du hast %d neue Nachrichten',
        ],
];

[swissspidy]

Closing in favor of #458. Thanks again for contribution!