-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
TranslatableMessage not extracted #39126
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
Comments
I found a workaround. |
hmm, given that the extractor is now able to extract from services, I think we should change the wiring of the commands so that they are not limited to PHP templates anymore. |
Yeah. That makes sense |
In fact, the commands are not related to PHP templates only. It works currently with non-removed services wiring the Translator services. It's hard to detect all PHP files that require trans extraction, and some of them aren't services at the end. That's why I think we should pass this resposibility to the user through a new option in related commands to append specific directories or files where to extract. For example:
This would reduce the number of files to be parsed. For the record: this PR #40229 was open to add the whole |
… from all of src (natewiebe13) This PR was squashed before being merged into the 5.3-dev branch. Discussion ---------- [FrameworkBundle][Translation] Extract translation IDs from all of src | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Related to #39126 possibly #35082 as well | License | MIT | Doc PR | TBD This PR allows extracting (`bin/console translation:update`) and debugging (`bin/console debug:translation`) translations using Translatable messages. Currently we only check classes that include the `TranslatorInterface`, but this no longer covers all instances of this. Current considerations: - Should this be treated as a bug fix or a new feature? On one hand, text extraction would no longer work if moving to TranslatableMessages (like we're doing) on the other, it wasn't intended to search all PHP files. As a bug fix would get this into Symfony faster, as a feature would mean having to wait until 5.3 is released. - Is there a better way to get the source directory that doesn't involve hardcoding `/src`? - Adding this in on a project with ~12k LOC in `/src` takes these operations from about 3s to 5s, but I feel like this is reasonable considering this command isn't likely called constantly. I can provide more accurate stats as requested. Commits ------- b02ae50 [FrameworkBundle][Translation] Extract translation IDs from all of src
Symfony version(s) affected: 5.2.0-RC1
Description
The class TranslatableMessage (and the shorthand t() function), introduced in symfony 5.2, allows to provide translatable messages without needing the translator service.
The PhpExtractor from the translation component does extract them.
However, the translation:update (and debug:translation) command only extract from services which have the translator service injected.
Possible Solution
The only solution I can think of would be to have the extraction parse all the PHP sources, but maybe as an option not enabled by default?
The text was updated successfully, but these errors were encountered: