Skip to content

[FrameworkBundle][Translation] Extract translation IDs from all of src #40229

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

Merged
merged 1 commit into from
Mar 5, 2021

Conversation

natewiebe13
Copy link
Contributor

@natewiebe13 natewiebe13 commented Feb 17, 2021

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.

@carsonbot carsonbot changed the title [Translation] Extract translation IDs from all of src Extract translation IDs from all of src Feb 17, 2021
@carsonbot carsonbot changed the title Extract translation IDs from all of src [FrameworkBundle][Translation] Extract translation IDs from all of src Feb 17, 2021
@yceruto
Copy link
Member

yceruto commented Feb 20, 2021

Should this be treated as a bug fix or a new feature?

I think this should be treated as a new feature, yes.

Is there a better way to get the source directory that doesn't involve hardcoding /src?

What about adding a new option in related commands to extract also from one specific directory or file?

For example, with such option we could add the src/ path to the current $viewPaths list:

bin/console translation:update en --extra-path=src

The option could accept an array of paths too. What do you think?

@Pixelshaped
Copy link

Have I missed something or TranslatableMessage are now extracted?
Went to see the PhpExtractor and found they were!
That's great: in our project we built a whole workaround to extract all keys that were not in classes where the TranslationInterface could be injected (say, enums, DTOs, etc). Using grep.
I'm absolutely seconding the fact that we should be able to provide all paths necessary to the extraction command!

@natewiebe13
Copy link
Contributor Author

natewiebe13 commented Feb 21, 2021

The option could accept an array of paths too. What do you think?

Thinking about DX I think having src included by default is consistent with having things "just work". I know our team would always want to include src. I've seen other places hardcode this path, but just wanted to mention it in case there's actually a way to avoid that.

Regarding adding that as an option does solve my concern around making this work for teams that use non-standard directories, but I think adding that should be in a separate PR as they are different features. If it turns out that including src by default isn't wanted, I think adding the path as an option is a good fallback.

@natewiebe13
Copy link
Contributor Author

Have I missed something or TranslatableMessage are now extracted?
Went to see the PhpExtractor and found they were!

Support was added to PhpExtractor along with the feature. The missing part is that the commands that use them only include classes that inject TranslatorInterface. I haven't had a chance to test this out, but potentially as another workaround, you could determine which tag is being detected by the commands and add it through services.yaml?

@nicolas-grekas nicolas-grekas added this to the 5.x milestone Feb 22, 2021
@natewiebe13
Copy link
Contributor Author

... potentially as another workaround, you could determine which tag is being detected by the commands and add it through services.yaml?

I had a chance to dig into this and it doesn't appear that this is a potential workaround.

@@ -140,6 +140,7 @@ protected function execute(InputInterface $input, OutputInterface $output): int
$transPaths[] = $this->defaultTransPath;
}
$viewsPaths = $this->viewsPaths;
$viewsPaths[] = $kernel->getProjectDir().'/src';
Copy link
Member

Choose a reason for hiding this comment

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

I would create a new array as src/ does not contain views, something like $codePaths?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fabpot just to provide context, currently if you inject TranslatorInterface, those classes get added to $viewPaths even though it doesn't contain any templates.

Here's an example dump:

^ array:16 [
  0 => "public"
  1 => "/var/www/html/vendor/symfony/twig-bridge/Resources/views/Email"
  2 => "/var/www/html/vendor/symfony/twig-bridge/Resources/views/Form"
  3 => "/var/www/html/vendor/symfony/framework-bundle/Command/TranslationDebugCommand.php"
  4 => "/var/www/html/vendor/symfony/form/Extension/Core/Type/ColorType.php"
  5 => "/var/www/html/vendor/symfony/form/Extension/Core/Type/TransformationFailureExtension.php"
  6 => "/var/www/html/vendor/symfony/form/Extension/Validator/Type/FormTypeValidatorExtension.php"
  7 => "/var/www/html/vendor/symfony/form/Extension/Validator/Type/UploadValidatorExtension.php"
  8 => "/var/www/html/vendor/symfony/form/Extension/Csrf/Type/FormTypeCsrfExtension.php"
  9 => "/var/www/html/vendor/symfony/validator/ValidatorBuilder.php"
  10 => "/var/www/html/vendor/symfony/framework-bundle/CacheWarmer/TranslationsCacheWarmer.php"
  11 => "/var/www/html/vendor/symfony/translation/DataCollector/TranslationDataCollector.php"
  12 => "/var/www/html/src/Controller/SecurityController.php"
  13 => "/var/www/html/vendor/symfony/form/Extension/Core/Type/FileType.php"
  14 => "/var/www/html/vendor/symfony/twig-bridge/Extension/TranslationExtension.php"
  15 => "/var/www/html/vendor/symfony/twig-bridge/Extension/FormExtension.php"
]

Can you confirm if we should keep it this way or if we should add $codePaths and then if we do add $codePaths would we just use it for adding the src folder or would we move some of these files into $codePaths instead?

Copy link
Member

Choose a reason for hiding this comment

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

I would say that the issue is the name $viewPaths. When the variable was first introduced, the PhpExtractor was targetting only PHP templates, not other usages of the translator

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Vars have been renamed to codePaths

@Pixelshaped
Copy link

Have I missed something or TranslatableMessage are now extracted?
Went to see the PhpExtractor and found they were!

Support was added to PhpExtractor along with the feature. The missing part is that the commands that use them only include classes that inject TranslatorInterface. I haven't had a chance to test this out, but potentially as another workaround, you could determine which tag is being detected by the commands and add it through services.yaml?

As long as TranslatableMessage aren't picked up in any class they might be declared in, the extract command will be a bit underwhelming. But I'm not sure that's the case: I went to see PhpExtractor and it seems all php files are parsed and every sequence in the $sequences array is looked for. Sure for ->trans( to work you have to inject the TranslatorInterface somewhere, but new TranslatableMessage( does not need this requirement and seems to be picked up by default. This is cool!

@fabpot fabpot force-pushed the translation-extration-src branch from f693ab3 to b02ae50 Compare March 5, 2021 12:17
@fabpot
Copy link
Member

fabpot commented Mar 5, 2021

Thank you @natewiebe13.

@natewiebe13 natewiebe13 deleted the translation-extration-src branch March 5, 2021 15:15
wouterj added a commit to symfony/symfony-docs that referenced this pull request Apr 7, 2021
…ebe13)

This PR was squashed before being merged into the 5.3-dev branch.

Discussion
----------

Update docs relating to translation extraction

Update translation extraction docs based on changes from symfony/symfony#40229

Fixes #15061

Commits
-------

77089fa Update docs relating to translation extraction
n-peugnet added a commit to n-peugnet/antilope that referenced this pull request Apr 8, 2021
This is a hack to scan froms for translation while waiting for
symfony/symfony#40229 to be released.
See symfony/symfony#35082 (comment)
n-peugnet added a commit to n-peugnet/antilope that referenced this pull request Apr 9, 2021
This is a hack to scan froms for translation while waiting for
symfony/symfony#40229 to be released.
See symfony/symfony#35082 (comment)
@fabpot fabpot mentioned this pull request Apr 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants