5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Я тоже пойду. Сервис с переводами, заманчивая вообще мысль. Вопрос только как сделать, чтобы это не снижало быстродействие. Не на лету же туда фронту обращаться, если надо получить каких-то 10 фраз на каком-то языке.
Читать полностью…
Понятно что это просто сделать. Вопрос целесообразности. Фронту это добавит гемору. Потому что ему надо писать длинный код для работы с датами, а тут еще придется при выводе Datepicker предварительно переводить эти даты во внутренний формат, там обрабатывать, потом все равно локализовать для пользователя, потом чтобы отправить обратно в API - все в обратном порядке.
Читать полностью…
Бек на основе локали может возвращать даты/числа в нужном формате без всяких фронтендов.
Читать полностью…
еще накинуть поддержку смещений часовых поясов не в часах, а в минутах - учитывать есть пояса со смещением на полчаса0)
Читать полностью…
Представьте что у вас с бека может прийти для одного языка в одном формате, для другого в другом
Читать полностью…
Ну дак подготовит он для en/ru локали.
Для остальных, кмк, переводчики должны заниматься. С контекстом, т.е. не просто прогнать через сервис перевода и получить ошибки: отменить/отменить для cancel/discard changes.
А. Ещё. Вы ещё бек научите даты правильно в сообщении об ошибке рендерить. А то эти иностранцы напридумывал форматы mm-dd, dd/mm и т.д.
Читать полностью…
Я имею в виду что фронт дату не просто выводит. Там надо код писать и работать с её значением. А тут получится еще что надо будет дважды делать лишние преобразования. Но вообще может быть все же Вы правы, и все таки если уже мы делаем i18n, то лучше делать по полной, чтобы бек отвечал все в одной локали, а не выборочно.
Читать полностью…
Увы, это уже не избежать, там будет логика работы со значением типа дата / число до отображения пользователю, поэтому в данном случае данные нужно гонять строго в одном определенном формате.
Читать полностью…
И при баге в одном месте, нужно будет править каждый клиент.
Читать полностью…
Вы же сами писали, что клиентов будет много. Т.е. вся эта логика будет размазана по всем ним.
Читать полностью…
Вы писали для фронта календарики когда-нибудь или какие-нибудь инпуты для чисел?
Читать полностью…
Задайте себе кучу вопросов и попробуйте с точки зрения Бека на рендеринг ошибки взглянуть. Там в дурку не долго уехать
Читать полностью…
Не - вот это не надо. Это на фронте в одном месте один раз пишется. Иначе там будет пздц с визуальными компонентами для редактирования дат и чисел.
Читать полностью…