FB
я могу про скриншоты рассказать
Я тоже с удовольствием послушаю)
Size: a a a
2019 November 09
IA
Я тоже с удовольствием послушаю)
Ну тогда я с удовольствием прямо здесь и отвечу:
1. Универсальных решений нет (и, как по мне, не будет в обозримом будущем).
2. Универсальных коробочных решений нет тем более.
3. Есть решения для конкретных платформ (зачастую, мобильных), но все они завязаны на свои SaaS (TMS), что нивелирует их достоинства (я исхожу из постулата, что иметь по отдельному технологическому процессу и по отдельной TMS для каждой платформы никто не захочет).
4. Все решения для конкретных платформ требуют установки SDK и дополнительного инструментирования билдов. Примеры: OneSky, Applanga. Никто не гарантирует, что ваше приложение с установленным сторонним SDK будет работать корректно. Эти SDK довольно инвазивны. (У нас был, правда довольно давно, неудачный опыт прикручивания подобного SDK.)
5. Даже наличие коробочной версии решения не означает, что процесс сбора скриншотов можно будет автоматизировать. Обычно сбор скриншотов подразумевает наличие либо ручного прохода по тест-плану, либо автотестов.
6. Писать автотесты дорого и долго (локализацию надо делать раньше, чем написаны автотесты); а на ручное тестирование полагаться для полного покрытия не стоит.
7. Большинство "ограниченно-успешных" внедрений скриншотинга имеют кучу оговорок: "да, у нас это есть, но только для определенной платформы, и только для основных экранов приложения".
8. Для экономии и для отсутствия привязки к какому-то дополнительному SaaS чаще всего скриншоты делают как побочные артефакты автотестов (особенно когда автотесты уже внедрены, и на их написание уже выделены человеческие ресурсы). В таких случаях скриншоты получаются "почти бесплатно", но остальные минусы сохраняются (долго ждать покрытия новых фич, т.е. там, где скриншоты для локализации нужны больше всего).
9. Наибольшего успеха можно достичь там, где разработчики сами в процессе добавляют инструментирование для автотестов. Тогда покрытие тестами (и скриншотами) нового функционала будет идти быстрее.
Мы пробовали и один из сторонних SDK (неудачно), и брать скриншоты с автотестов, когда они у нас были (чуть более успешно, но всего для пары платформ). В итоге у меня сложилось ощущение, что гораздо проще и дешевле точечно вручную предоставлять скриншоты (прикреплять их к сегментам в CAT) когда о них явно просят. Они нужны далеко не всегда при начальном переводе, а финальное тестирование уже надо проводить во внутренних сборках продукта. Но если в компании уже есть инфраструктура написания автотестов, то грех ей не воспользоваться и не собирать скриншоты пусть и не для начальной локализации, но хоть для периодической оценки лингвистами.
А вообще, если уж тратить время и деньги на дополнительное инструментирование, то целесообразнее вкладываться в инфраструктуру in-context редактирования, нежели в скриншоты.
1. Универсальных решений нет (и, как по мне, не будет в обозримом будущем).
2. Универсальных коробочных решений нет тем более.
3. Есть решения для конкретных платформ (зачастую, мобильных), но все они завязаны на свои SaaS (TMS), что нивелирует их достоинства (я исхожу из постулата, что иметь по отдельному технологическому процессу и по отдельной TMS для каждой платформы никто не захочет).
4. Все решения для конкретных платформ требуют установки SDK и дополнительного инструментирования билдов. Примеры: OneSky, Applanga. Никто не гарантирует, что ваше приложение с установленным сторонним SDK будет работать корректно. Эти SDK довольно инвазивны. (У нас был, правда довольно давно, неудачный опыт прикручивания подобного SDK.)
5. Даже наличие коробочной версии решения не означает, что процесс сбора скриншотов можно будет автоматизировать. Обычно сбор скриншотов подразумевает наличие либо ручного прохода по тест-плану, либо автотестов.
6. Писать автотесты дорого и долго (локализацию надо делать раньше, чем написаны автотесты); а на ручное тестирование полагаться для полного покрытия не стоит.
7. Большинство "ограниченно-успешных" внедрений скриншотинга имеют кучу оговорок: "да, у нас это есть, но только для определенной платформы, и только для основных экранов приложения".
8. Для экономии и для отсутствия привязки к какому-то дополнительному SaaS чаще всего скриншоты делают как побочные артефакты автотестов (особенно когда автотесты уже внедрены, и на их написание уже выделены человеческие ресурсы). В таких случаях скриншоты получаются "почти бесплатно", но остальные минусы сохраняются (долго ждать покрытия новых фич, т.е. там, где скриншоты для локализации нужны больше всего).
9. Наибольшего успеха можно достичь там, где разработчики сами в процессе добавляют инструментирование для автотестов. Тогда покрытие тестами (и скриншотами) нового функционала будет идти быстрее.
Мы пробовали и один из сторонних SDK (неудачно), и брать скриншоты с автотестов, когда они у нас были (чуть более успешно, но всего для пары платформ). В итоге у меня сложилось ощущение, что гораздо проще и дешевле точечно вручную предоставлять скриншоты (прикреплять их к сегментам в CAT) когда о них явно просят. Они нужны далеко не всегда при начальном переводе, а финальное тестирование уже надо проводить во внутренних сборках продукта. Но если в компании уже есть инфраструктура написания автотестов, то грех ей не воспользоваться и не собирать скриншоты пусть и не для начальной локализации, но хоть для периодической оценки лингвистами.
А вообще, если уж тратить время и деньги на дополнительное инструментирование, то целесообразнее вкладываться в инфраструктуру in-context редактирования, нежели в скриншоты.
MG
Насчет автотестов неистово плюсую. Но это надо нанимать людей, которыре будут их писать. Здесь потребуются вложения. У нас автотесты позволили сократить количество тестировщиков в три раза. Заодно локализацию подкрутили.
А есть вообще у кого-нибудь "инфраструктура in-context редактирования"? Вот не так чтобы для одного приложения, а прям конвейер для софта на разных платформах и тэдэ.
А есть вообще у кого-нибудь "инфраструктура in-context редактирования"? Вот не так чтобы для одного приложения, а прям конвейер для софта на разных платформах и тэдэ.
IA
Я ничего универсального для in-context не знаю. обычно отдельно для мобилок, отдельно для веба. на вебе с этим проще всего, так что решений уже больше десятка наскрести, наверно, получится.
MG
ну вот с мобилками жопка, да. там для каждого теста надо билд пересобирать, а это время. а уж если редактуру как-то прикручивать, то это совсем люто
IA
Я лишь пока в нашей системе непрерывной локализации сделал на будущее задел для подключения in-context редакторов. Там самый главный принцип — иметь возможность из сторонней системы (т.е. локализуемого софта) сослаться по внешнему ID сегмента на этот сегмент в CAT (просто тупо уметь открыть URL с нужным сегментом как самый базовый уровень интеграции). Соответственно, я добавил возможность генерировать глобально уникальный ID строки и иметь его в приложениях. Остается только инструментировать все наши приложения, что может произойти через год, через два или примерно никогда. 😉
IA
если кто хочет поэкспериментировать, то я могу подробнее рассказать и поделиться ссылочками
IA
ну вот с мобилками жопка, да. там для каждого теста надо билд пересобирать, а это время. а уж если редактуру как-то прикручивать, то это совсем люто
с мобилками есть решения (те же OneSky, Applanga и Qordoba) которые на лету пропихивают переводы с сервера
IA
Там все демо с гарантированным wow-эффектом. только вот надо полностью на их решения локализацию переводить. взять их технологию и органично встроить в существующий процесс не получится.
MG
последним сообщением ты все испортил
IA
лан, ща все сотру и по новой...
AD
Я лишь пока в нашей системе непрерывной локализации сделал на будущее задел для подключения in-context редакторов. Там самый главный принцип — иметь возможность из сторонней системы (т.е. локализуемого софта) сослаться по внешнему ID сегмента на этот сегмент в CAT (просто тупо уметь открыть URL с нужным сегментом как самый базовый уровень интеграции). Соответственно, я добавил возможность генерировать глобально уникальный ID строки и иметь его в приложениях. Остается только инструментировать все наши приложения, что может произойти через год, через два или примерно никогда. 😉
Игорь, спасибо! Очень ценная информация! Мы тоже этим периодически занимаемся. У нас есть самописный плагин в Web-интерфейсе, который позволял нам делать локализацию прямо в нем, но перевести все хорошо таким способом невозможно. Переводчик не может открыть все окна, те же сообщения с ошибками. А как потом выискивать недопереведенные места, тоже непонятно. В общем мы быстро отказались от такого способа (ну это было давно). Сейчас мы его используем только для определения идентификатора строки, чтобы потом найти в системе перевода и исправить ошибку. Опять же это только Web, для каждого интерфейса нужно что-то свое.
Со ссылками по ID в конкретное место системы тоже думали. Были мысли, что надо генерировать скриншоты для каждой строки, но когда мы это сделаем, видимо, тогда же когда и вы :))
Со ссылками по ID в конкретное место системы тоже думали. Были мысли, что надо генерировать скриншоты для каждой строки, но когда мы это сделаем, видимо, тогда же когда и вы :))
IA
Игорь, спасибо! Очень ценная информация! Мы тоже этим периодически занимаемся. У нас есть самописный плагин в Web-интерфейсе, который позволял нам делать локализацию прямо в нем, но перевести все хорошо таким способом невозможно. Переводчик не может открыть все окна, те же сообщения с ошибками. А как потом выискивать недопереведенные места, тоже непонятно. В общем мы быстро отказались от такого способа (ну это было давно). Сейчас мы его используем только для определения идентификатора строки, чтобы потом найти в системе перевода и исправить ошибку. Опять же это только Web, для каждого интерфейса нужно что-то свое.
Со ссылками по ID в конкретное место системы тоже думали. Были мысли, что надо генерировать скриншоты для каждой строки, но когда мы это сделаем, видимо, тогда же когда и вы :))
Со ссылками по ID в конкретное место системы тоже думали. Были мысли, что надо генерировать скриншоты для каждой строки, но когда мы это сделаем, видимо, тогда же когда и вы :))
> Сейчас мы его используем только для определения идентификатора строки, чтобы потом найти в системе перевода и исправить ошибку.
Полностью согласен. in-context нужен не как основной инструмент перевода, а как инструмент для превью и QA. Уметь редактировать прямо внутри, не открывая CAT — это бонус (и может быть, ненужный и дорогой)
Полностью согласен. in-context нужен не как основной инструмент перевода, а как инструмент для превью и QA. Уметь редактировать прямо внутри, не открывая CAT — это бонус (и может быть, ненужный и дорогой)
FK
Из моего опыта - есть относительно простая и в меру удобная штуковина для автоматизации снятия скринов - autohotkey. Это кликер с развесистым паскаль-образным скриптовым языком, который очень удобно использовать для оптимизации механических действий (например сделать скрины всех предметов в игре, всех неписей и так далее - при наличии отладочной консоли в игре - мы так делали например создание 40000 скринов предметов для одной ММО, чтобы сравнить внешний вид предмета с его названием и исключить невлезания в описаниях), а также для написания простых автотестов - в духе "запусти игру, дождись главного экрана, зайди в настройки, смени язык, загрузи сохранение, пройдись по меню, понаделай скринов, залей на ftp". Это такой недоавтотест с простым языком, изначально предназначенный для автоматизации последовательности действий и написания ботов, на котором тем не менее можно написать что угодно, и плюс в нем есть распознавалка и сравнение изображений - что в играх полезно.
IA
Fedor Kulikov
Из моего опыта - есть относительно простая и в меру удобная штуковина для автоматизации снятия скринов - autohotkey. Это кликер с развесистым паскаль-образным скриптовым языком, который очень удобно использовать для оптимизации механических действий (например сделать скрины всех предметов в игре, всех неписей и так далее - при наличии отладочной консоли в игре - мы так делали например создание 40000 скринов предметов для одной ММО, чтобы сравнить внешний вид предмета с его названием и исключить невлезания в описаниях), а также для написания простых автотестов - в духе "запусти игру, дождись главного экрана, зайди в настройки, смени язык, загрузи сохранение, пройдись по меню, понаделай скринов, залей на ftp". Это такой недоавтотест с простым языком, изначально предназначенный для автоматизации последовательности действий и написания ботов, на котором тем не менее можно написать что угодно, и плюс в нем есть распознавалка и сравнение изображений - что в играх полезно.
Autohotkey в мире Windows — по-моему самая распространенная тулза для автоматизации. Круто, что вы ее и в локализации эффективно употребили.
FK
Autohotkey в мире Windows — по-моему самая распространенная тулза для автоматизации. Круто, что вы ее и в локализации эффективно употребили.
Я ее даже в свое время использовал для массового начисления подарков пользователям в ММО, где в серверной части не было возможности это сделать через базу или через админку. То есть отдельная машинка с админским клиентом, в которую посылаются админские команды, читая список награждаемых пользователей из текстовичка - send #username -itemid 12345 -itemquantity 1 -now . Правда это все происходило неторопливо - 15000 пользователей награждались двое суток )
A
Ну тогда я с удовольствием прямо здесь и отвечу:
1. Универсальных решений нет (и, как по мне, не будет в обозримом будущем).
2. Универсальных коробочных решений нет тем более.
3. Есть решения для конкретных платформ (зачастую, мобильных), но все они завязаны на свои SaaS (TMS), что нивелирует их достоинства (я исхожу из постулата, что иметь по отдельному технологическому процессу и по отдельной TMS для каждой платформы никто не захочет).
4. Все решения для конкретных платформ требуют установки SDK и дополнительного инструментирования билдов. Примеры: OneSky, Applanga. Никто не гарантирует, что ваше приложение с установленным сторонним SDK будет работать корректно. Эти SDK довольно инвазивны. (У нас был, правда довольно давно, неудачный опыт прикручивания подобного SDK.)
5. Даже наличие коробочной версии решения не означает, что процесс сбора скриншотов можно будет автоматизировать. Обычно сбор скриншотов подразумевает наличие либо ручного прохода по тест-плану, либо автотестов.
6. Писать автотесты дорого и долго (локализацию надо делать раньше, чем написаны автотесты); а на ручное тестирование полагаться для полного покрытия не стоит.
7. Большинство "ограниченно-успешных" внедрений скриншотинга имеют кучу оговорок: "да, у нас это есть, но только для определенной платформы, и только для основных экранов приложения".
8. Для экономии и для отсутствия привязки к какому-то дополнительному SaaS чаще всего скриншоты делают как побочные артефакты автотестов (особенно когда автотесты уже внедрены, и на их написание уже выделены человеческие ресурсы). В таких случаях скриншоты получаются "почти бесплатно", но остальные минусы сохраняются (долго ждать покрытия новых фич, т.е. там, где скриншоты для локализации нужны больше всего).
9. Наибольшего успеха можно достичь там, где разработчики сами в процессе добавляют инструментирование для автотестов. Тогда покрытие тестами (и скриншотами) нового функционала будет идти быстрее.
Мы пробовали и один из сторонних SDK (неудачно), и брать скриншоты с автотестов, когда они у нас были (чуть более успешно, но всего для пары платформ). В итоге у меня сложилось ощущение, что гораздо проще и дешевле точечно вручную предоставлять скриншоты (прикреплять их к сегментам в CAT) когда о них явно просят. Они нужны далеко не всегда при начальном переводе, а финальное тестирование уже надо проводить во внутренних сборках продукта. Но если в компании уже есть инфраструктура написания автотестов, то грех ей не воспользоваться и не собирать скриншоты пусть и не для начальной локализации, но хоть для периодической оценки лингвистами.
А вообще, если уж тратить время и деньги на дополнительное инструментирование, то целесообразнее вкладываться в инфраструктуру in-context редактирования, нежели в скриншоты.
1. Универсальных решений нет (и, как по мне, не будет в обозримом будущем).
2. Универсальных коробочных решений нет тем более.
3. Есть решения для конкретных платформ (зачастую, мобильных), но все они завязаны на свои SaaS (TMS), что нивелирует их достоинства (я исхожу из постулата, что иметь по отдельному технологическому процессу и по отдельной TMS для каждой платформы никто не захочет).
4. Все решения для конкретных платформ требуют установки SDK и дополнительного инструментирования билдов. Примеры: OneSky, Applanga. Никто не гарантирует, что ваше приложение с установленным сторонним SDK будет работать корректно. Эти SDK довольно инвазивны. (У нас был, правда довольно давно, неудачный опыт прикручивания подобного SDK.)
5. Даже наличие коробочной версии решения не означает, что процесс сбора скриншотов можно будет автоматизировать. Обычно сбор скриншотов подразумевает наличие либо ручного прохода по тест-плану, либо автотестов.
6. Писать автотесты дорого и долго (локализацию надо делать раньше, чем написаны автотесты); а на ручное тестирование полагаться для полного покрытия не стоит.
7. Большинство "ограниченно-успешных" внедрений скриншотинга имеют кучу оговорок: "да, у нас это есть, но только для определенной платформы, и только для основных экранов приложения".
8. Для экономии и для отсутствия привязки к какому-то дополнительному SaaS чаще всего скриншоты делают как побочные артефакты автотестов (особенно когда автотесты уже внедрены, и на их написание уже выделены человеческие ресурсы). В таких случаях скриншоты получаются "почти бесплатно", но остальные минусы сохраняются (долго ждать покрытия новых фич, т.е. там, где скриншоты для локализации нужны больше всего).
9. Наибольшего успеха можно достичь там, где разработчики сами в процессе добавляют инструментирование для автотестов. Тогда покрытие тестами (и скриншотами) нового функционала будет идти быстрее.
Мы пробовали и один из сторонних SDK (неудачно), и брать скриншоты с автотестов, когда они у нас были (чуть более успешно, но всего для пары платформ). В итоге у меня сложилось ощущение, что гораздо проще и дешевле точечно вручную предоставлять скриншоты (прикреплять их к сегментам в CAT) когда о них явно просят. Они нужны далеко не всегда при начальном переводе, а финальное тестирование уже надо проводить во внутренних сборках продукта. Но если в компании уже есть инфраструктура написания автотестов, то грех ей не воспользоваться и не собирать скриншоты пусть и не для начальной локализации, но хоть для периодической оценки лингвистами.
А вообще, если уж тратить время и деньги на дополнительное инструментирование, то целесообразнее вкладываться в инфраструктуру in-context редактирования, нежели в скриншоты.
Игорь, спасибо за обзор! 👍🏻 Жму отсутствующую кнопку Like : )
n
Насчет автотестов неистово плюсую. Но это надо нанимать людей, которыре будут их писать. Здесь потребуются вложения. У нас автотесты позволили сократить количество тестировщиков в три раза. Заодно локализацию подкрутили.
А есть вообще у кого-нибудь "инфраструктура in-context редактирования"? Вот не так чтобы для одного приложения, а прям конвейер для софта на разных платформах и тэдэ.
А есть вообще у кого-нибудь "инфраструктура in-context редактирования"? Вот не так чтобы для одного приложения, а прям конвейер для софта на разных платформах и тэдэ.
А lingoport смотрел? Мне понравился их in-context review, правда, в демо 🙃
IA
А lingoport смотрел? Мне понравился их in-context review, правда, в демо 🙃
У Lingoport та же проблема с необходимостью написания автотестов (или ручного прохода) поверх интеграции их решения (а равно как и у Smartling, не к ночи будь помянут).
Вот выдержка из https://wiki.lingoport.com/About_InContext_Translation
> With each navigation to a new page on the instrumented deployment, the InContext Capture Chrome extension saves the context back to the Lingoport VM. LRM then sends the association between the context and each of the base resources to the TMS.
При переводе на русский это означает: пока ты (или автотест) не зайдешь на новую страницу, никакой контекст в TMS не попадет.
В случае же с прокси-решением от Smartling там и на перевод строки не попадут. И получается, что чтобы локализация бегала и контекст выцеплялся, странички надо сначала сверстать, опубликовать на сервере, а потом кому-то на эту страницу еще и зайти.
Вот выдержка из https://wiki.lingoport.com/About_InContext_Translation
> With each navigation to a new page on the instrumented deployment, the InContext Capture Chrome extension saves the context back to the Lingoport VM. LRM then sends the association between the context and each of the base resources to the TMS.
При переводе на русский это означает: пока ты (или автотест) не зайдешь на новую страницу, никакой контекст в TMS не попадет.
В случае же с прокси-решением от Smartling там и на перевод строки не попадут. И получается, что чтобы локализация бегала и контекст выцеплялся, странички надо сначала сверстать, опубликовать на сервере, а потом кому-то на эту страницу еще и зайти.
IA
А так выглядит вполне ничего...