Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Command translation:update doesn't take into account domain #42285

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.

Sign up for GitHub

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

Jump to bottom
Closed
lukepass opened this issue Jul 27, 2021 · 10 comments
Closed

Command translation:update doesn't take into account domain #42285

lukepass opened this issue Jul 27, 2021 · 10 comments
Labels
Bug Status: Needs Review Translation

Comments

@lukepass
Copy link

lukepass commented Jul 27, 2021 •
edited by javiereguiluz
Loading

Hello, I am using Symfony 4.4 and I just realized that when using the following command:

php bin/console translation:update --force en

The command doesn't take into account the specified domain, for example:

class ChangePasswordFormType extends AbstractType
{
    /**
     * @var TranslatorInterface
     */
    private $translator;

    public function __construct(TranslatorInterface $translator)
    {
        $this->translator = $translator;
    }

    /**
     * @param mixed[]                                           $options
     * @param FormBuilderInterface<FormBuilderInterface|string> $builder
     */
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $message = $this->translator->trans('This is the string I would like to translate', $parameters = [], $domain = 'validators');

        // other code...
    }
}

The string This is the string I would like to translate should be inserted in the file validators.en.xlf but it's written in the messages.en.xlf file.

Thanks!
@JohJohan
Copy link
Contributor

I see you can pass domain as a argument to the command idk how that would effect the output?

@lukepass
Copy link
Author

Hi @JohJohan that argument should just filter the translations of the specified domain.

@xabbuh
Copy link
Member

xabbuh commented Jul 30, 2021

Generally, the PHP extractor should be able to extract domains too. Can you create a small example application that allows to reproduce the behaviour that you experience?

@lukepass
Copy link
Author

Of course! This is a really simple project, if you type ➜ php bin/console translation:update --force en the result is the following:

image

(it should be inside validators)

Thanks.

Project: translation_bug.zip

@xabbuh
Copy link
Member

xabbuh commented Jul 30, 2021

Thank you that helped a lot! I think the extractor is not able to parse the domain properly because of the use of the $domain variable.

If you change the line to something like this everything is working as expected for me:

        $message = $this->translator->trans('This is the string I would like to translate', [], 'validators');

@lukepass
Copy link
Author

Yes, I can confirm that if I remove $domain = 'validators' the string goes to validators correctly. Maybe it's related to PHP Parser and it's considered a non-constant expression?

@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@Koc
Copy link
Contributor

Koc commented Feb 7, 2022 •
edited
Loading

I can confirm that issue is still present for php extractor in 5.4.x.

@carsonbot carsonbot removed the Stalled label Feb 7, 2022
@nicolas-grekas
Copy link
Member

nicolas-grekas commented Feb 14, 2022 •
edited
Loading

/cc @welcoMattic
Anyone up for having a look and fixing this?

@welcoMattic welcoMattic mentioned this issue Apr 6, 2022
Closed
@welcoMattic
Copy link
Member

After discussion with @nicolas-grekas and @stof IRL, we concluded that is much more complicated to fix this issue (and not break concatenation of variable and string). So we decided to won't fix for now.

But, we noticed that we do not support named arguments in PhpExtractor. To do it, we need to write a new Extractor based on AST. Once this new Extractor will ne written, we may plan to support inline variable assignation.

@welcoMattic welcoMattic mentioned this issue Apr 12, 2022
Closed
@welcoMattic welcoMattic mentioned this issue Apr 25, 2022
Merged
2 tasks
fabpot added a commit that referenced this issue Oct 20, 2022
@fabpot
feature #46161 [Translation] Add PhpAstExtractor (welcoMattic)
38678dc 
This PR was merged into the 6.2 branch.

Discussion
----------

[Translation] Add `PhpAstExtractor`

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | Fix #44899, #42285, #45972, #45039
| License       | MIT
| Doc PR        | symfony/symfony-docs#17369

After discussions with `@stof` and `@nicolas`-grekas at SymfonyLive Paris 2022, it appears clear that we need a brand new PhpExtractor in Translation to support various syntax, especially PHP8 new syntax (named arguments for example).

In order to make this new extractor sustainable, performant and maintainable, it must be based on AST. That's why this PR adds a new optional dependency on [nikic/php-parser](https://github.com/nikic/PHP-Parser).

The tests suite is the same as PhpExtractorTest, in addition to new cases for newly supported syntax.

NB: I was inspired by https://github.com/php-translation/extractor design, with adaptations for Symfony.

To-do:

- [x] As suggested by `@Nyholm`, take a look at https://github.com/php-translation/extractor
- [x] Fix #45039 (could be achieved easily with AST tree)

Commits
-------

5d4a81f Add PhpAstExtractor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Status: Needs Review Translation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Koc @nicolas-grekas @welcoMattic @xabbuh @lukepass @JohJohan @carsonbot