Какие практики используются для локализации писем в Laravel?

Question

[Сергей delphinpro]

Имеется мультиязычный сайт. Пользователь может выбрать язык, пользователю могут отправляться письма. Письма необходимо отравлять на языке, выбранном пользователем.

Как это вижу я:
Создаю шаблоны письма для каждого языка

views/emails
  en/
    welcome.blade.php
  ru/
    welcome.blade.php
  ar/
    welcome.blade.php

Для удобства навелосипедил небольшой трейт

trait TranslatableMail
{
  protected function localizedView($name, $locale = null): string
  {
    $localizedView = 'emails.'.($locale ?? $this->user->language).'.'.$name;
    return View::exists($localizedView) ? $localizedView : 'mails.en.'.$name;
  }
}

И подмешиваю в свои Mailable классы

class WelcomeMail extends Mailable implements ShouldQueue
{
  use Queueable, SerializesModels;
  use TranslatableMail;
  public function build(): WelcomeMail {
    return $this->from(config('mail.from.address'), config('mail.from.name'))
      ->subject(__('mail.subject.welcome', [], $this->user->language))
      ->view($this->localizedView('welcome'));
  }
}

В принципе, всё работает, но может есть какие-то общепринятые практики?

Answer 1

[Aleksey]

Или вы что-то переусложнили или я не понял чего вы хотите добиться.

Вот тут описано как при отправке задать язык - https://laravel.com/docs/8.x/mail#localizing-mailables.

А сам перевод можно хранить как обычно.

views/emails/welcome.blade.php

lang/
  ru/
    mails.php
  ar/
    mails.php

Не вижу смысла в дублировании вьюшек.

Comments

[Сергей delphinpro]

Да, я это видел. Я так понимаю, таким образом можно задать локаль, которая будет использована при использовании во вьюхе письме переводных функций, вроде __().
Но дело в том, что письмо целиком написано на разных языках.

Пример самого простого письма на двух языках

Dear {{ $user->salutation }} {{ $user->fullname }};

Welcome to Platform.

Your Email Verification Code No. {{ $no }} is: {{ $code }}

Sincere Regards;

Уважаемый (ая) {{ $user->salutation }} {{ $user->fullname }};

Добро пожаловать на платформу.

Ваш код подтверждения для электронной почты № {{ $no }}: {{ $code }}

С уважением,

Есть более объемные письма.

[jazzus]

Сергей delphinpro, такие можно собрать без вьюх с помощью мейл методов нотификаций

[Сергей delphinpro]

jazzus, Есть более сложные, с условным отображением информации. Да и в целом мне кажется так удобнее тексты редактировать при необходимости. Особенно на арабском языке =).

[jazzus]

Сергей delphinpro, с условными принцип dry нарушается. Потом условие поменяется и придется во все вьюхи лезть.

[vism]

Сергей delphinpro, всё правильно у вас (как в вопросе)
Просто люди мыслят шаблонами "правильного программирования" и очень сильно усложняют себе жизнь пытаясь сделать через __() и т.п. Это приходит только с опытом и ошибками.
Не думают о требованиях бизнеса и смысл имейлов для разных стран.

Не вздумайте сомневаться и переделывать на translate методы. потом настрадаетесь. только разные view для разных стран

[jazzus]

vism, лазить по десяткам вьюх и руками картинки всьавлять с форматированием и логикой конечно удобней lang директив с ключами. это ведь снобы и идиоты их придумали, чтобы жизнь усложнить, а ошибки чф юзеры переживут)

[jazzus]

vism, в отдельные файлы имеет смысл выносить только большие блоки текста и то это должны быть включаемые файлы, чтобы шаблон с логикой не трогать которую тоже в компонент вынести. а тупо целиком вьюхи дублировать плохая идея.

[Сергей delphinpro]

jazzus, В данном случае это вьюхи письма

@component('mail::message')
много текста
@endcomponent

Т.е. по сути – тело сообщения. Которое должно быть переведено целиком.

[jazzus]

Сергей delphinpro, если прям текст простыней то да с переводами заморочено и включаемыми частями можно разместить в файлах. а во всех других случаях lang trans и скобки, как в Ларавел написано. А в твоем примере вообще без вьюх можео собрать методами в нотификации - там уже готовая структура с приветствием, футером сообщением, экшеном итд

[jazzus]

Сергей delphinpro, сложно сделать просто, гораздо сложнее сделать просто, но нужно стремиться)

[vism]

jazzus, для картинок с логикой существуют компоненты, инклуды или спец класс-сервис по подготовке.

[jazzus]

vism, а для переводов переводы. Что у кого существует надо конкретно смотреть, а то разговор ниочем. Говорят одно, а на деле бессмысленный велосипед и все гораздо проще делается. Например как в примере выше с вьюхами

[jazzus]

vism, вот письмо для welcome https://github.com/spatie/laravel-welcome-notifica...
а не три вьюхи

[Сергей delphinpro]

jazzus, Чем хранение четырех строк перевода в трех файлах (допустим три языка) лучше хранения просто трех файлов?
Опять же, если смотреть на ваш пример, то эти строки хранятся в json файлах - а они только по одному на язык, группировку сделать нельзя, в отличие от использования ключей

__('Photographer Services') VS __('order.photografer')

А это значит, что у вас все письма будут свалены в один файл. Причем, разбиты построчно. Да там черт ногу сломит.
У меня в проекте, на минуточку, более 30 разных писем. Более половины из них - это гораздо больше четырех предложений.

У меня из ваших ответов складывается впечатление (возможно ошибочное), что вы не сильно много работали с ларкой. Просто документацию-то я и сам прочитал. Меня же интересуют решения, которые люди используют, когда проект чуть более выходит за рамки примеров из официальной документации.

[Aleksey]

Сергей delphinpro, затянулся ваш спор вижу, давайте ещё один пример приведу.

Захотели вы письма изменить. Сложные они у вас, 1000 тегов там вложенных. Что проще править - файлы перевода, или 10 ваших шаблонов?

Посмотрите как в самом фреймворке письмо реализовано. Куча отдельных компонентов, условия, красивые кнопочки.. И ни единой попытки продублировать эти кнопочки на 100 языков. Смекаете?

[jazzus]

Сергей delphinpro, тем лучше, что когда мне нужно править переводы я лезу в файлы переводов, а не блуждаю по компонентам из 40ка вьюх с картинками логикой и всякой фигней. Я Ларавел изучал не для изучения, а для создания проектов с которыми почти каждый день работаю и примеров кучу видел, где в 99% случаев отхождение от документации вообще ничем не оправдано. понятно, что ивой велосипед гораздо лучше решения ларавел, тк свое не пахнет. а документация нужна, чтобы про нее в комментах писать исключительно, а не для использования на реальных проектах с 1000 вьюх для 10 писем.

[Сергей delphinpro]

Aleksey, jazzus, Хорошо. Но. Все мои 30 писем уникальны. Если мне нужно поправить перевод, мне нет разницы, править строки перевода, или отдельные файлы.
Для простоты вернемся к простому примеру с письмом выше.

{
  "Dear :salutation :username;" : "Dear :salutation :username;"
  "Welcome to Platform." : "Welcome to Platform."
  "Your Email Verification Code No. :no is: :code" : "Your Email Verification Code No. 
  :no is: :code"
  "Sincere Regards;" : "Sincere Regards;"
}

Dear {{ $user->salutation }} {{ $user->fullname }};

Welcome to Platform.

Your Email Verification Code No. {{ $no }} is: {{ $code }}

Sincere Regards;

Первый пример умножим на 30 и прибавим туда еще кучу переводных строк.

Как по мне второй вариант намного чище и его удобнее править.

Куча отдельных компонентов, условия, красивые кнопочки.. И ни единой попытки продублировать эти кнопочки на 100 языков. Смекаете?

Да. Есть пара кнопок-ссылок. Я так же использую для них встроенные компоненты (те, что для маркдауна). Я так же использую для них функцию __('') если надпись на кнопке какая-то общая.

Но, повторяюсь уже, я завел речь о письмах в целом. Об уникальных текстах писем, которые более нигде не используются. Использование файлов перевода для этого мне оказалось крайне неудобным.

Один файл – одно письмо (целиком) на одном языке. Markdown. Очень удобно скинуть файлы переводчику и получить обратно переведенный файл, готовый к коммиту.

[Aleksey]

Сергей delphinpro, Реально - спор бесконечный, и каждый останется при своём. vism, например вас поддержал. Пару плюсов и я получил. А решения так и нет. Да наверное и быть не может. Каждый подход имеет право на жизнь.

[jazzus]

Сергей delphinpro, а где письмо то, которое в переводах не оформить? его бы в вопрос добавить, а то непонятно что обсуждаем. обычно переводы все уникальны. то, которое для простоты делается элементарно с одной вьюхой.

[jazzus]

наверняка там

приветствие
текст
кнопка
компонент с логикой и переменными
картинка
текст
кнопка
прощание
футер

убираем уникальные тексты и слова на кнопках в переводы и все. и наслаждаемся одной вьюхой. если прямо структура с версткой разная тогда еще можно в файлы убрать и то подумать, может чтото с письмами не то

[vism]

Сергей delphinpro, Забей. не все осознают суть проблемы. Подавляющее большинство разработчиков мыслят шаблонами документации. Нет опыта пока.
У jazzus всего несколько лет опыта, он довольно толковый новичек(уже отличный мидл наверняка), один из немногих на тостере.
То, что они говорят сработает тоже, но в поддержкке будет адище. Оно будет по патернам, по докам, они будут тратить море времени, чтоб это закодить и поддерживать, а потом поймут, что надо было делать по простому. Поймут, что время затраченное на хотелки бизнеса не получается внедрить, без кучи временных затрат. Будут доказывать заказчику, что он просит не кошерные фичи, убеждать привести всё письма к каким то паттернам, страдать добавляю и дробя эти lang строки, меняя их местами.
И может на этом остановятся, а может поймут, что иногда стоит сделать быстро и не по паттернам, но удобно для изменений. Так как нужно бизнесу, а не авторам книжек чистого кода и авторам доков пакетов.

[Сергей delphinpro]

jazzus, почему 1000 вьюх? по одной на каждый язык.
Вы правда не видите разницы между удобством поддержки этих двух вариантов?

spoiler

еще пример

<x-mail.message>

  ## Dear {{ __($user->salutation, [], 'en') }} {{ $user->fullname }};

  Please note your trip with Order number <b>{{ $orderNo }}</b> that you placed was
  successfully completed and processed on Platform.

  You are receiving attached to this email the Service Level Agreement along with all the details of your trip to
  Russia.

  Your payment of <b>{{ $payment->amount_value }}</b> Rubles was successfully processed and received.

  The tickets of the flights related to your travel and trip to Russia are processed separately and will be sent
  directly to your registered email.

  Thank you for your business and trust.

  We wish you a pleasant and unforgettable journey.

  Our Customer Support Desk is available 24/7, please do not hesitate to call us for any additional enquiry or
  clarification.

  <img src="{{ $message->embed(public_path('images/common/logo_en_100.png')) }}" alt="" border="0">
  <br><b>Platform Reservation.</b>

</x-mail.message>

Зачем мне это письмо дробить построчно? Целиком сразу виден весь контекст, это удобно для правок, это удобно для переводчика, это удобно для добавления нового языка.

[jazzus]

vism, мыслят шаблонами документации)) сразу хочется на код автора посмотреть. Покажи примеры писем? Что за трудности давай обсудим. А то пишешь много, а примеров нет. А насчте Ларавел давно все известно - говнокодеры и вообще к практике отношения не имеют. Сайты свои и сервисы на фрилансе заказывают т.к. с их практиками ничего нормального не сделать. Ты бы их хоть проконсультировал как надо, а то мучаются люди.

[Сергей delphinpro]

Aleksey,

Реально - спор бесконечный

В споре рождается истина =) Я для того и задал вопрос.

[jazzus]

Сергей delphinpro, насчет простыней текста писал уже - там можно подумать, чтолбы разместить в файлах. Но даже в твоем примере

это

spoiler

Thank you for your business and trust.

We wish you a pleasant and unforgettable journey.

Our Customer Support Desk is available 24/7, please do not hesitate to call us for any additional enquiry or
clarification.



Platform Reservation.

в шаблон футера для всех писем вместе с началом.

Остается текст

spoiler

Please note your trip with Order number {{ $orderNo }} that you placed was
successfully completed and processed on Platform.

You are receiving attached to this email the Service Level Agreement along with all the details of your trip to
Russia.

Your payment of {{ $payment->amount_value }} Rubles was successfully processed and received.

The tickets of the flights related to your travel and trip to Russia are processed separately and will be sent
directly to your registered email.

в ключ message языкового файла с передачей переменных

насчет самого файла переводов - если наглядность в письмах не нужна,а она там не нужна т.к. и так понятно про что письмо, то я бы размещал в php в коротких ключах

[jazzus]

Сергей delphinpro,

return [
  'message' => 'Please note your trip with Order number <b>:order</b> that you placed was
  successfully completed and processed on Platform.

  You are receiving attached to this email the Service Level Agreement along with all the details of your trip to
  Russia.

  Your payment of <b>:amount</b> Rubles was successfully processed and received.

  Very big text with html.'
];

это неудобно и ненаглядно? И у тебя нормальный шаблон письма, который ты можешь вертеть как хочешь без трейтов, запаривания и залезания в тысячи вьюх.

[jazzus]

Сергей delphinpro, ну и че ты истину искал и пропал. Если нечего возразить принимай правильные ответы решением и следующий вопрос)

Answer 2

[jazzus]

Бест практику можно найти в самом Ларавел https://github.com/laravel/framework/blob/b1257c4e...

Переводы для множества языков с блоками большого текста можно размещать в коротких ключах языковых php файлов. Пример здесь https://laravel.com/docs/8.x/localization#using-sh...

Автор, как читающий документацию (хочется верить не вертикально) должен все это знать. И не надо рассказывать бред про неведомые "реальные проекты". Эти инструменты созданы для реальных проектов, а не для виртуальных. Велосипеды на реальных проектах пишут от незнания фреймворка и неумения им пользоваться, а не потому что там есть такая потребность. Именно такие письма пишу я, Ларавел и вижу в различных пакетах и проектах. Еще ни разу 1000 вьюх для 10 писем я не видел, но представляю какой геморой это поддерживать.