pro.jvm

22 Dec 2024 12:19

В целом, тоже вариант, кмк.

pro.jvm

22 Dec 2024 12:16

фреймворк же. насколько я понял

pro.jvm

22 Dec 2024 12:15

сервис переводов не варик-если цель захватить планету)

pro.jvm

22 Dec 2024 12:10

Я имею в виду что фронт дату не просто выводит. Там надо код писать и работать с её значением. А тут получится еще что надо будет дважды делать лишние преобразования. Но вообще может быть все же Вы правы, и все таки если уже мы делаем i18n, то лучше делать по полной, чтобы бек отвечал все в одной локали, а не выборочно.

pro.jvm

22 Dec 2024 12:08

на стажировку в @javastart на месяцок?

pro.jvm

22 Dec 2024 12:05

https://coub.com/view/3dxslc

pro.jvm

22 Dec 2024 12:01

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

pro.jvm

22 Dec 2024 12:00

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

pro.jvm

22 Dec 2024 12:00

Вы же сами писали, что клиентов будет много. Т.е. вся эта логика будет размазана по всем ним.

pro.jvm

22 Dec 2024 11:59

Вы писали для фронта календарики когда-нибудь или какие-нибудь инпуты для чисел?

pro.jvm

22 Dec 2024 11:58

Задайте себе кучу вопросов и попробуйте с точки зрения Бека на рендеринг ошибки взглянуть. Там в дурку не долго уехать

pro.jvm

22 Dec 2024 11:58

А - если в тексте ошибки даты - то да - я бы перевел

pro.jvm

22 Dec 2024 11:57

Как? Вы же рендерить ошибку на беке будете

pro.jvm

22 Dec 2024 11:57

Не - вот это не надо. Это на фронте в одном месте один раз пишется. Иначе там будет пздц с визуальными компонентами для редактирования дат и чисел.

pro.jvm

22 Dec 2024 11:54

Нет человека - нет проблем. (с) Сталин

pro.jvm

22 Dec 2024 12:18

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

pro.jvm

22 Dec 2024 12:16

У вас монолит/микросервисы?

pro.jvm

22 Dec 2024 12:15

Я тоже пойду. Сервис с переводами, заманчивая вообще мысль. Вопрос только как сделать, чтобы это не снижало быстродействие. Не на лету же туда фронту обращаться, если надо получить каких-то 10 фраз на каком-то языке.

pro.jvm

22 Dec 2024 12:08

¿parse_date(..., locale)?

pro.jvm

22 Dec 2024 12:06

Понятно что это просто сделать. Вопрос целесообразности. Фронту это добавит гемору. Потому что ему надо писать длинный код для работы с датами, а тут еще придется при выводе Datepicker предварительно переводить эти даты во внутренний формат, там обрабатывать, потом все равно локализовать для пользователя, потом чтобы отправить обратно в API - все в обратном порядке.

pro.jvm

22 Dec 2024 12:03

Бек на основе локали может возвращать даты/числа в нужном формате без всяких фронтендов.

pro.jvm

22 Dec 2024 12:01

еще накинуть поддержку смещений часовых поясов не в часах, а в минутах - учитывать есть пояса со смещением на полчаса0)

pro.jvm

22 Dec 2024 12:00

Да, но там уже реализация визуальных компонентов своя

pro.jvm

22 Dec 2024 11:59

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

pro.jvm

22 Dec 2024 11:59

Зачем ещё тут фронт примешивать?

pro.jvm

22 Dec 2024 11:58

А если в данных для форм например - то нет.

pro.jvm

22 Dec 2024 11:58

А если там внутри дата или денежная единица?

pro.jvm

22 Dec 2024 11:57

Ну дак подготовит он для en/ru локали.
Для остальных, кмк, переводчики должны заниматься. С контекстом, т.е. не просто прогнать через сервис перевода и получить ошибки: отменить/отменить для cancel/discard changes.

pro.jvm

22 Dec 2024 11:56

А. Ещё. Вы ещё бек научите даты правильно в сообщении об ошибке рендерить. А то эти иностранцы напридумывал форматы mm-dd, dd/mm и т.д.

pro.jvm

22 Dec 2024 11:53

Все проблемы от разработчиков. Лажают. Зп требуют. Спорят. Не могут без багов писать.