Size: a a a

Обсуждения техдирские

2018 May 26

DS

Dmitry Simonov in Обсуждения техдирские
Пардон! Поправился :)
источник

DS

Dmitry Simonov in Обсуждения техдирские
Пора чатик переименовывать в "записки техдиров" и давать возможность писать свои размышления всем присутствующим техдирам :))))
источник

IS

Ilyas Salikhov in Обсуждения техдирские
Dmitry Simonov
Коллеги! Рад представить Ильяса Салихова, - технического директора одной из самых продвинутых систем для интернет-магазинов! Ильяс, - напиши пару слов о себе!
Спасибо) Исходно мы Интаро — веб-интегратор, который берет на поддержку и развитие крупный екоммерс. Запустили @retailcrm 5 лет назад, продукт вырос с нуля до 7000 магазинов, которые сейчас используют систему. Через нас проходит заказов сейчас где-то на 60 млрд. руб. в год (5-10% российского екома). Это все результат тяжёлой ежедневной работы с отдачей, и нас это прёт)
источник

ML

Maksim Lapshin in Обсуждения техдирские
Офигеть, 7000 магазинов
источник

DS

Dmitry Simonov in Обсуждения техдирские
источник

DK

Dmitriy Kovalenko in Обсуждения техдирские
Dmitry Simonov
Про локализацию софта
https://www.youtube.com/watch?v=mIwkvkwq96o

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

Самым первым систематичным и удобным подходом к решению задачи стал GNU GetText: https://ru.wikipedia.org/wiki/Gettext, хранение переводов в .po файлах или их модификациях.

За ним подтянулись аналогичные решения на практически всех платформах. Это или нативные решения на уровне стандартных классов, как сделано в Android и iOs или дополнительные библиотеки, как в многочисленных скриптовых и не только языках:

* Android - https://developer.android.com/guide/topics/resources/localization

* iOs -https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html

* php/Symphony - https://symfony.com/doc/current/components/translation.html, включающий в себе массу провайдеров поставщиков переводов, в том числе и  https://api.symfony.com/4.0/Symfony/Component/Translation/Loader/MoFileLoader.html

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

Задача эта настолько непроста и зависит от множества людей и факторов, что, например, телеграмму пришлось даже запустить собственную платформу для переводов: https://translations.telegram.org/

Если же свою платформу разрабатывать не хочется, есть готовые решения:


* https://crowdin.com/
* https://gitlocalize.com/
* https://poeditor.com/
* https://localise.biz/

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

Так, например, для андроида вместо .po файлов используется аналог strings.xml, а для ios -  Localizable.strings

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

Итого, true way для локализации является использование gettext или аналогов в стыковке с платформой по менеджменту переводов, умеющей экспортировать переводы в нужные форматы.
True way? Как по мне все варианты где в итоге используются файлы - ущербны по причине невозможности апдейта на лету без редеплоя/пересборки приложения. Я обычно применяю простой запрос на бекенд который вернет массив ключей + переводов для указанного языка. Для склонений и падежей используется стандарт icu. Итого имеем более простую систему, добавлять и редактировать фразы можно на лету. Подгружать можно на старте приложения, обновлять/перегружать по надобности.
источник

DK

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

DK

Dmitry Krokhin in Обсуждения техдирские
а все варианты, где используются файлы хороши тем, что можно использовать разные (стандартные) инструменты
источник

DK

Dmitriy Kovalenko in Обсуждения техдирские
это заканчивается тем что ребятам которые пишут под iOS чтобы изменить слово надо выливать новую версию приложения
источник

DK

Dmitry Krokhin in Обсуждения техдирские
ну это вы немного всё смешали в одну кучу. возможность сложить в сборку, не означает что это необходимо. я не согласен с позицией, что все варианты где используются файлы - ущербны.
тот же бэкенд может использовать эти файлы
источник

DK

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

DK

Dmitriy Kovalenko in Обсуждения техдирские
Сужу по своему опыту, проходили историю с gettext, poeditor, потом файлы на бекенде. Потом админка которая пишет в эти файлы. И наконец админка которая пишет в mysql. После этого вздохнули с облегчением, потому что имхо не стоит воспринимать переводы как что-то особенное, это еще одна порция данных которые приложение вгружает в память при старте или по надобности. С файлами все получается неудобно когда начинаешь скейлить систему. Начинаются нюансы с десятками переводчиков, надо удобный ui, + подсчет переводов для оплаты работы. ACL для определенных действий, ревью и все остальное.
источник

DK

Dmitry Krokhin in Обсуждения техдирские
если я правильно понял, в посте как раз есть пяток сервисов которые решают проблему работы над переводом нескольких переводчиков (учёт\оплата). на выходе просто файлы которые надо скормить бэкенду (чтобы обновлять динамически) либо включить в сборку.
можно, конечно, не использовать сервисы, а сделать свой инструмент
источник

DK

Dmitry Krokhin in Обсуждения техдирские
кстати, кто-нибудь использует микросервисный фронтэнд? если да, то какие есть инструменты? что-то вроде web-components, только мне нравится javascript-first подход. то есть компонент это в первую очередь класс, а не специальный элемент в dom.
источник

DS

Dmitry Simonov in Обсуждения техдирские
@d_kovalenko конечно же прав, - в случае с мобильными приложениями необходимо максимально избавляться от необходимости пересборки приложения, если без неё можно обойтись. Отличный апдейт к статье!

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

DS

Dmitry Simonov in Обсуждения техдирские
источник

DS

Dmitry Simonov in Обсуждения техдирские
Так держать, @d_kovalenko ! С удовольствием буду ждать от вас новых апдейтов :)
источник

DK

Dmitriy Kovalenko in Обсуждения техдирские
Благодарю, буду рад если мой опыт кому то поможет ;)
источник

DS

Dmitry Simonov in Обсуждения техдирские
Уже помогает, Дим! Расскажи пару слов о себе и своей работе!
источник

DS

Dmitry Simonov in Обсуждения техдирские
Надо также отметить @nekufa , который поддержал дискуссию! Без него мы бы не получили системный взгляд на поднимаемую проблему!
источник