Add support for custom translation blade directives

[michaelw85]

Solves #435

Add a new option --blade-directives making it possible to use custom directives as translation functions.
These directives will be rewritten to __( to allow them to be picked up as translation strings.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[swissspidy]

Thanks for your PR.

As per #435 (comment), I am hesitant to add something like this. This change may work for your particular use case, but not for everyone else's.

It's unclear how this would work for other functions like _x() or _n(). And what if someone has different directives with different signatures?

That's why I said this quickly leads to additional complexity.

[michaelw85]

As per #435 (comment), I am hesitant to add something like this. This change may work for your particular use case, but not for everyone else's.

I thought I would give it a go, and you might accept it since it's an optional argument. I understand that in its current state, it is very limited in what it supports. The only way to fully support this feature would be to inject custom directives, and I don't think this would be possible in any way. This would mix your local WP code with WP-CLI.

It's unclear how this would work for other functions like _x() or _n(). And what if someone has different directives with different signatures?

I could update the syntax for the params to something like @t:__ to support a custom mapping.

If you don't want to accept this change, I would ask if I can achieve this in a custom plugin? I haven't made any yet and I would think I'm making changes to something that I can't extend.

[swissspidy]

If you don't want to accept this change, I would ask if I can achieve this in a custom plugin? I haven't made any yet and I would think I'm making changes to something that I can't extend.

Not in a WordPress plugin, but in a custom WP-CLI command. You have already forked the repository for this PR, so you could install that via wp package install https://github.com/michaelw85/i18n-command and then wp i18n would be using your customized version.

[michaelw85]

Thx for the info! I will close this pr and ticket and will go with a custom install.

[michaelw85]

If you don't want to accept this change, I would ask if I can achieve this in a custom plugin? I haven't made any yet and I would think I'm making changes to something that I can't extend.

Not in a WordPress plugin, but in a custom WP-CLI command. You have already forked the repository for this PR, so you could install that via wp package install https://github.com/michaelw85/i18n-command and then wp i18n would be using your customized version.

FYI installing a custom branch will not completely replace an existing one. Due to how composer works it will still autoload certain classes from the original code so it becomes part custom, part original code 😅 . Fun little challenge I'm currently working on.
For the install I needed to use wp package install user/repo, the full url was giving me errors for some reason.