Классно, довольно таки полезно, когда работаешь в проекте с переводами. Но небольшой совет — не надо совмещать локализацию и строковые переменные, есть 95% риск напороться на проблему «множественного числа». Если встретитесь с таким — очень хорошо стоит подумать, прежде чем браться.
У нас в команде _частично_ проще, к счастью. Тоже проект, на нескольких языках, рельсы-шмельсы, но к счастью встроенный i18n _частично_ спасает ситуацию с кучей языков, ибо в проекте все строки ссылаются на en.yml(в зависимости от текущего языка) файл, где и хранятся все строки, и вытаскиваются по ключу. И незадолго до деплоя, команда переводчиков со стороны заказчика все все переводит/обновляет переводы, создавая/обновляя копии es.yml, de.yml, и так далее, сколько языков там вам требуется.
Самая большая проблема — когда заказчику захотелось сделать в его проекте (проект по аудиту, рискам аудита, и прочему) изменяемые названия. Пользователь на одной там страничке вводит новое имя, и теперь его аудит называется не Audit, а, ну, Shmaudit. Окей, хорошо.
Посмотрели — у нас в куче описаний используется слово Audit, которое надо заменить на Shmaudit. А в другой куче описаний оно еще и с маленькой буквы используется. А еще дофига где оно в множественном числе, с маленькой или большой буквы. А у нас еще 5 языков есть других. А проект, мягко говоря — немаленький. В одном en.yml — 2548 строк. Это примерно 2500 строк переводов. А терминов этих — штук 50.
Если бы был один лишь английский — можно еще подключить какой-нибудь словарь, и все вроде как хорошо. Но словарей на 6 языков не напасешься. Да и ввод информации пользователем — нереально рандомная штука, и черт знает, что там со словарем получится. В общем, для аудиторского проекта решение на костылях не катит.
Решили просто к черту переписать все локали, где мы используем множественное число изменяемых терминов, на единственное. Все, что осталось — это делать lowercase или uppercase в зависимости от места, где переводим.
Вторая боль — немецкий язык. Предложения на немецком бывают в 2 раза длиннее, чем на английском. И в итоге, когда смотришь верстку на английском, все хорошо, все, прекрасно, переключаешь на немецкий, и… [нецензурная немецкая брань из советских фильмов], все нафиг съехало.
В чем мораль — использовать изменяемые термины, которые вводит пользователь, в файлах с локалями, а не дай бог, их еще и больше чем одна — приведет к боли. И переписыванию кучи текста. К счастью, над корректным переписыванием текста из множественного числа в единственное, думали на стороне заказчика люди, а не мы. А с немецким фиг знает, что делать. Верстать может с расчетом на него.
Как-то так.
Ну, дублирование — это не DRY. Толстые ответы с рендерингом всей страницы — а зачем тогда Ajax? Вы через turbolinks получите примерно похожее.
Даже не знаю, второй подход — это как в рельсах писать все запросы на SQL, когда есть ActiveRecord. Неоправданно, в общем.
Третий — то, для чего эти запросы и нужны, собственно, обмен JSONами с сервером, быстро и эффективно, и обновление информации real-time, с различными красивыми fadeIn и прочим.
Первый случай еще имеет место быть, но только в одном случае — когда это реально экономит вам время и деньги. Второй — просто не стоит биндить рендер страницы на один эвент.
P.s — простите за русско-английский, с телефона не торт писать.
Ну, почему уж реклама. Мы просто делимся личным опытом с другими, и благодаря этому, находим удобные решения.
Спасибо за наводку, познакомлюсь с circleci тоже :)
У нас в команде _частично_ проще, к счастью. Тоже проект, на нескольких языках, рельсы-шмельсы, но к счастью встроенный i18n _частично_ спасает ситуацию с кучей языков, ибо в проекте все строки ссылаются на en.yml(в зависимости от текущего языка) файл, где и хранятся все строки, и вытаскиваются по ключу. И незадолго до деплоя, команда переводчиков со стороны заказчика все все переводит/обновляет переводы, создавая/обновляя копии es.yml, de.yml, и так далее, сколько языков там вам требуется.
Самая большая проблема — когда заказчику захотелось сделать в его проекте (проект по аудиту, рискам аудита, и прочему) изменяемые названия. Пользователь на одной там страничке вводит новое имя, и теперь его аудит называется не Audit, а, ну, Shmaudit. Окей, хорошо.
Посмотрели — у нас в куче описаний используется слово Audit, которое надо заменить на Shmaudit. А в другой куче описаний оно еще и с маленькой буквы используется. А еще дофига где оно в множественном числе, с маленькой или большой буквы. А у нас еще 5 языков есть других. А проект, мягко говоря — немаленький. В одном en.yml — 2548 строк. Это примерно 2500 строк переводов. А терминов этих — штук 50.
Если бы был один лишь английский — можно еще подключить какой-нибудь словарь, и все вроде как хорошо. Но словарей на 6 языков не напасешься. Да и ввод информации пользователем — нереально рандомная штука, и черт знает, что там со словарем получится. В общем, для аудиторского проекта решение на костылях не катит.
Решили просто к черту переписать все локали, где мы используем множественное число изменяемых терминов, на единственное. Все, что осталось — это делать lowercase или uppercase в зависимости от места, где переводим.
Вторая боль — немецкий язык. Предложения на немецком бывают в 2 раза длиннее, чем на английском. И в итоге, когда смотришь верстку на английском, все хорошо, все, прекрасно, переключаешь на немецкий, и… [нецензурная немецкая брань из советских фильмов], все нафиг съехало.
В чем мораль — использовать изменяемые термины, которые вводит пользователь, в файлах с локалями, а не дай бог, их еще и больше чем одна — приведет к боли. И переписыванию кучи текста. К счастью, над корректным переписыванием текста из множественного числа в единственное, думали на стороне заказчика люди, а не мы. А с немецким фиг знает, что делать. Верстать может с расчетом на него.
Как-то так.
:)
Даже не знаю, второй подход — это как в рельсах писать все запросы на SQL, когда есть ActiveRecord. Неоправданно, в общем.
Третий — то, для чего эти запросы и нужны, собственно, обмен JSONами с сервером, быстро и эффективно, и обновление информации real-time, с различными красивыми fadeIn и прочим.
Первый случай еще имеет место быть, но только в одном случае — когда это реально экономит вам время и деньги. Второй — просто не стоит биндить рендер страницы на один эвент.
P.s — простите за русско-английский, с телефона не торт писать.
А ведь неплохой слоган, боже.
Спасибо за наводку, познакомлюсь с circleci тоже :)