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 11:51

А если его родной язык - Javascript - то пусть лучше увольняется, реально от таких "разработчиков" только одни проблемы.

pro.jvm

22 Dec 2024 11:50

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

pro.jvm

22 Dec 2024 11:50

Это не его работа переводить.

pro.jvm

22 Dec 2024 11:49

Ладно. Делайте как хотите. Я просто свой взгляд на проблему описал и попытался аргументировать. Не претендую на истинность.

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

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

pro.jvm

22 Dec 2024 11:51

И до того как это попадет на бой - надо чтобы переводы были сделаны. Поэтому фолбек тут в принципе не нужен.

pro.jvm

22 Dec 2024 11:50

Так это не его зона ответственности, а переводчика.

pro.jvm

22 Dec 2024 11:49

Спор это хорошо, в нем в любом случае рождаются и новые идеи:)

pro.jvm

22 Dec 2024 11:47

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