8000 [Translation] Placeholder parameter is not replaced · Issue #49093 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content
8000

[Translation] Placeholder parameter is not replaced #49093

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
mhitza opened this issue Jan 24, 2023 · 4 comments
Closed

[Translation] Placeholder parameter is not replaced #49093

mhitza opened this issue Jan 24, 2023 · 4 comments
Labels
Bug Status: Needs Review Translation

Comments

@mhitza
Copy link
mhitza commented Jan 24, 2023

Symfony version(s) affected

6.2.5

Description

Target translation message contains a placeholder %parameter% which is not replaced.

How to reproduce

I have a translation message in my messages.en.xlf file:

<trans-unit id="gxuTKpj" resname="relative_date.last_week">
  <source>relative_date.last_week</source>
  <target>last week %day%</target>
</trans-unit>

And a twig extension which exposes a filter (relativeDate) that returns a translatable message (simplified):

return new TranslatableMessage('relative_date.last_week', ['%day%' => match($dt->format('l')) {
    'Monday' => new TranslatableMessage('relative_date.monday'),
    'Tuesday' => new TranslatableMessage('relative_date.tuesday'),
    'Wednesday' => new TranslatableMessage('relative_date.wednesday'),
    'Thursday' => new TranslatableMessage('relative_date.thursday'),
    'Friday' => new TranslatableMessage('relative_date.friday'),
    'Saturday' => new TranslatableMessage('relative_date.saturday'),
    default => new TranslatableMessage('relative_date.sunday')
}]);

Output which I use in my twig template:

<td class="p-2">{{ item.date|relativeDate|trans }}</td>

The end result is the message without replaced parameters:

<td class="p-2">last week %day%</td>

Possible Solution

No response

Additional Context

No response
@mhitza mhitza added the Bug label Jan 24, 2023
@MatTheCat
Copy link
Contributor

I get last week relative_date.tuesday because relative_date.tuesday has no translation.

Could you provide a reproducer?

Also note that if you got the intl extension you can translate a date’s day of week with

\IntlDateFormatter::create($locale, pattern: 'EEEE')->format($dt);

@mhitza
Copy link
Author
mhitza commented Jan 25, 2023

@MatTheCat while writing out the reproduction code and running the translation extraction command I get a messages+intl-icu.en.xlf file. Whereas in my original repository I have a messages.en.xlf file. With the intl-icu suffixed file I can replace the % with curly brackets and the replacement takes place (this doesn't happen in the project where I have the issue). Similar to #35328 which I came across, before posting my issue.

I don't know the internals of the translation bundle and when one or the other type of suffix is generated, thus I'm not sure how to replicate the issue I have in my original project.

Does this somehow happen because the messages file was originally generated without the presence of intl extension, and when the intl extension was installed an alternate codepath is taken for the translation?

@MatTheCat
Copy link
Contributor

The issue you describe would be the reverse: the IntlFormatterInterface used on the legacy message format.

Does refreshing the cache change anything?

@mhitza
Copy link
Author
mhitza commented Jan 25, 2023

@MatTheCat found the issue and I'm going to close the ticket.

In my original repository the relativeDate filter was initially implemented with return type string so even though later on I was returning TranslatableMessage the execution path taken was one for strings (so TranslatableMessage->trans was never called; thus the arguments were not used). In my repoduction code I've instinctively written the signature with return type TranslatableMessage and that's why it worked.

@mhitza mhitza closed this as completed Jan 25, 2023
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
3 participants
@mhitza @MatTheCat @carsonbot
0