Translate emails #10914
Translate emails #10914
Conversation
…different locale than the default one
| @@ -1,29 +1,29 @@ | |||
| {% extends '@SyliusShop/Email/layout.html.twig' %} | |||
|
|
|||
| {% block subject %} | |||
| Order confirmation | |||
| {{ 'sylius.email.order_confirmation.subject'|trans({}, null, localeCode) }} | |||
There was a problem hiding this comment.
This could also be written as:
{% trans into localeCode %}sylius.email.order_confirmation.subject{% endtrans %}
What is a better option? /cc @Sylius/core-team
There was a problem hiding this comment.
I like the {% trans into localeCode %} version when no parameters or domain is present. It looks cleaner :D
There was a problem hiding this comment.
But it would be nice to create a PR for twig that adds a trans_default_locale just as they have a trans_default_domain. That would really help with the readability of such templates as this
|
I find passing the locale code to every translation call very annoying, so I did this: |
src/Sylius/Bundle/ShopBundle/Resources/translations/messages.pl.yml
Outdated
Show resolved
Hide resolved
GSadee
force-pushed
the
translatable-emails
branch
from
60a287f
to
91d2210
Compare
|
@vvasiloi Thanks for the suggestion, I was thinking about it and your solution looks quite convincing 👍 |
GSadee
force-pushed
the
translatable-emails
branch
from
91d2210
to
eb803e7
Compare
| public function anEmailWithResetTokenShouldBeSentTo(string $recipient, string $localeCode = 'en_US'): void | ||
| { | ||
| $this->assertEmailContainsMessageTo( | ||
| $this->translator->trans('sylius.email.password_reset.reset_your_password', [], null, $localeCode), |
There was a problem hiding this comment.
I'm in favor of this solution, but @pamil had some second thoughts about it.
There was a problem hiding this comment.
Don't have any better ideas though :)
src/Sylius/Bundle/ShopBundle/EmailManager/OrderEmailManager.php
Outdated
Show resolved
Hide resolved
|
Thanks, Grzegorz! 🎉 |
|
I realise this feature is now added in 1.7. and I'm sure my question has been asked before, but why are emails not implemented as translatable entities? I realise there would be BC concerns with this approach, but in principle I think it could be a more versatile approach overall.... maybe something to think about for Sylius 2.0 ? |
Order confirmation in e.q.
pl_PL: