У меня есть нож, есть арбалет,
Они служат мне уже тысячу лет.

(с) КиШ

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

Привет, Хабр. Мы недавно перевели на арабский язык 2ГИС Онлайн, и хотим поделиться своим опытом адаптации интерфейса под RTL (right-to-left). Это будет актуально и для иврита, и для персидского языка.

Я разделю этот опыт на две статьи — теоретическую и практическую. Сегодня — больше про теорию. Я расскажу, зачем нам понадобилось переворачивать весь интерфейс, что для разработчика интерфейсов значит фраза «сделать арабскую версию» и как справиться с арабским языком, смешанным с английским. Особое внимание уделю алгоритму, по которому строится отображение текста смешанной направленности — unicode bidirectional algorithm.

Привет, Хабр!

В недавней статье наш коллега Дмитрий Марущенко yojick рассказал о том, как доставлять динамические обновления переводов с сервера на мобильные устройства. В продолжение темы сегодня поговорим о том, как мы используем эти обновлённые переводы в наших приложениях.

Исторически сложилось, что все основные мобильные платформы «из коробки» обладают превосходной поддержкой локализации сообщений. В iOS, Android и Windows Phone приложение можно локализовать без всяких трудностей. Все средства для этого уже встроены в IDE: просто укажите нужный язык в списке поддерживаемых локализаций, введите текст на этом языке — и всё остальное за вас сделает IDE. Работает как часы. Но у этого подхода всё же есть недостатки.

Нашли в тексте ошибку? Хотите что-то перефразировать? Вам нравится экспериментировать с разными обращениями к разным целевым группам? Во всех случаях ответ один: придётся пересобирать приложение, снова выкладывать его в магазин, проходить проверку, получать одобрение, публиковать новую версию со всеми изменениями и ждать, чтобы пользователи обновили приложение на своих устройствах. Даже если все процедуры пройдут без заминок, это займёт дни или недели. А если пользователи не захотят обновляться? Или того хуже — не смогут этого сделать по техническим причинам вроде неподдерживаемой ОС? Тогда нежелательный текст в вашем приложении проживет гораздо дольше, чем хотелось бы.

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

Текстовые редакторы, как тип программного обеспечения, появились чуть позже чем динозавры, и вероятнее всего это был вообще первый софт, с которым вы столкнулись в своей жизни, возможно кто-то даже застал MS-DOS Editor.

Однако с переходом большой части ПО в браузеры актуальны и соответствующие визуальные редакторы Rich Text Editors, и проблемных мест в их разработке масса. Если вы по какой-то причине решили сделать свой собственный редактор, то подумайте еще раз — есть мнение, что делать этого не нужно.



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

Disclaimer: статья написана на основании доклада Егора на конференции Frontend Conf 2017 в июне 2017 года. Ситуация с поддержкой браузерами определенных API с тех пор уже могла измениться.

Локализация приложения или сервиса — не просто перевод. Об этом знают почти все, однако на практике недооценивают амбициозность этой задачи.

Правильно выстроенный процесс локализации гарантирует, что пользователи приложения во всех странах одновременно получат полноценный доступ ко всему функционалу. А это значит, что она должна быть встроена в процесс разработки, начиная с планирования новых функций, и, помимо самого интерфейса, обеспечить выход всех сопроводительных материалов вместе с оригинальной версией (в случае с Wrike — английской).

Герои сериала «Шерлок»

Привет! Я Алексей Тимин, инженер из команды локализации Badoo. В этом посте я расскажу вам о том, как мы помогаем переводчикам в их нелёгком труде, и о новом Open Source-решении, позволяющем генерировать скриншоты дизайна, подготовленного в Sketch, для разных языков.

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

Привет, Хабр! Мы с ребятами из Smartcat решили сойти с ума и попробовать перевести на английский все посты, которые были опубликованы здесь до 19 июля 2017 года, а потом оценить, сколько это будет стоить в среднем, если будет переводить Человек VS Машина. Под катом вы узнаете, что у нас из этого получилось.

или Перерастает ли количество в качество

Статья по мотивам выступления на конференции РИФ+КИБ 2017.

Neural Machine Translation: почему только сейчас?

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

Тем не менее, вот динамика популярности в поиске запросов про нейронные сети вообще и про нейронный машинный перевод в частности:



Прекрасно видно, что на радарах вплоть до недавнего времени нет ничего про нейронный машинный перевод – и вот в конце 2016 года свои новые технологии и системы машинного перевода, построенные на базе нейронных сетей, продемонстрировали сразу несколько компаний, среди которых Google, Microsoft и SYSTRAN. Они появились почти одновременно, с разницей в несколько недель или даже дней. Почему так?

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

В одной только России насчитывается более сотни языков, многие из которых являются родными для десятков и сотен тысяч человек. Причем часть из них ограничена в употреблении или даже находится на грани исчезновения. Машинный перевод мог бы помочь в сохранении этих языков, но для этого надо решить главную проблему всех подобных систем – отсутствие примеров для обучения.

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



Правила против статистики

Машинный перевод, то есть автоматический перевод с одного человеческого языка на другой, зародился в середине прошлого века. Точкой отсчета принято считать Джорджтаунский эксперимент, проведенный 7 января 1954 года, в рамках которого более 60 фраз на русском языке были переведены компьютером на английский. По сути, это был вовсе и не эксперимент, а хорошо спланированная демонстрация: словарь включал не более 250 записей и работал с учетом лишь 6 правил. Тем не менее результаты впечатлили публику и подстегнули развитие машинного перевода.

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

Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).

А как же составить это самое регулярное выражение?

До недавнего времени существовало 2 ответа на этот вопрос:

1. Изучить документацию по регулярным выражениям и составить регулярку самому
2. Попросить кого-то более опытного сделать это за вас

Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:

» Генератор регулярных выражений

История

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

Всем, привет! Мессенджеры демонстрируют наибольший уровень вовлеченности пользователей, по сравнению со всеми остальными приложениями других категорий. В связи с этим наблюдаются измениния в сформировавшейся парадигме пользовательского опыта. Мессенджеры представляют из себя «браузер», а боты «веб-приложения». Они позволяют получать любую необходимую информацию мгновенно. Сегодня я хочу поделиться с вами наиболее полезными из них и показать, как можно прокачать свой Telegram.

k_s интересуется: «Я один не догнал логику разрыва ссылки на три части?»

Для ясности, вместо арабских букв в примерах будем пользоваться транслитерацией.

Текст той ссылки в HTML-коде записан так:

Например, wayawm baṣal эта ссылка yawm ʿasal выглядит разорванной

Браузер отображает арабский текст справа налево:

Например, laṣab mwayaw эта ссылка lasaʿ mway выглядит разорванной

Теперь обозначим в HTML-коде саму ссылку:

Например, wayawm baṣal эта ссылка yawm ʿasal выглядит разорванной

Браузер отображает арабский текст в прежних местах, причём части ссылки так и остаются частями ссылки:

Например, laṣab mwayaw эта ссылка lasaʿ mway выглядит разорванной

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

Например, ويوم بصل эта ссылка يوم عسل выглядит разорванной

---

Арабская пословица «yawm ʿasal wayawm baṣal» означает «День — как мёд, а день — как лук.»

В лингвистике сосуществуют две традиции описания языка: одна из них, до сих пор продолжающая традицию шумеров и древних греков, описывает язык фрагментарно — отдельно фонетику и фонологию, отдельно морфологию, отдельно синтаксис и т. д. Другая, идущая с четвертого — пятого веков до н. э. от индийского монаха Панини, описывает язык как интегральное целое — описание фонетики, морфологии, синтаксиса, семантики строится в виде взаимно ориентированных правил, с помощью которых из элементарных языковых единиц строятся тексты.

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



Лектор Александр Николаевич Барулин — сотрудник Института языкознания РАН. Закончил отделение структурной и прикладной лингвистики филологического факультета МГУ им. М. В. Ломоносова. Учился в аспирантуре Института востоковедения АН СССР, защитил диссертацию на тему «Теоретические проблемы описания турецкой именной словоформы» (1984). Проработал в Институте востоковедения 12 лет. В 1991 году совместно с В. К. Финном и Д. Г. Лахути организовал факультет информатики РГГУ и возглавил созданное на этом факультете отделение теоретической и прикладной лингвистики. В 1992 по проекту Барулина был организован факультет теоретической и прикладной лингвистики — он стал деканом этого факультета, а также заведующим кафедрой теоретической и прикладной лингвистики.

Под катом — подробная расшифровка лекции.

Существуют разные способы локализации WPF-приложения. Самый простой и распространенный вариант — использование файла ресурсов Resx и автоматически сгенерированный к ним Designer-класс. Но этот способ не позволяет менять значения «на лету» при смене языка. Для этого необходимо открыть окно повторно, либо перезапустить приложение.
В этой статье я покажу вариант локализации WPF-приложения с мгновенной сменой культуры.

Почти с самого своего рождения Lingualeo замышлялся как глобальный сервис, с помощью которого студенты по всему миру будут учить английский язык. В качестве полигона для отработки процесса выхода на новые рынки была выбрана Бразилия.

Уже летом 2012 года перед командой встала задача — локализация сервиса Lingualeo на португальский язык. При этом необходимо было создать процесс, легко масштабируемый на другие языки.

Процесс локализации продукта рождался в Черногории, куда команда Lingualeo выезжала для интенсивной работы над новыми фичами. По первоначальной оценке на локализацию должно было потребоваться всего пару недель разработки перед тем, как систему можно будет отдать переводчикам. Оценки оказались чересчур оптимистичными, команда “встряла” на 1,5 месяца. Lingualeo прошла сложный путь и столкнулась с целым рядом проблем, которых другие могут избежать, прочитав этот пост до конца. Мы попросили Игоря Любимова, Head of localization, почетного ветерана локализации Lingualeo, пересказать сюжет в деталях.

Как вы знаете, ABBYY занимается разработкой технологии анализа естественных языков Compreno. Сейчас система работает на английском и русском языках, и активно используется во многих проектах. Однако изначально сама технология была задумана как многоязычная, поэтому мы много внимания уделяем и «обучению» другим иностранным языкам. И тут можно провести некоторую аналогию с человеком: после изучения одного иностранного языка другие даются легче. В частности, сейчас мы добавляем в технологию немецкий язык и параллельно исследуем возможности рынка – есть ли интерес к этому направлению. Сразу оговоримся – пока речь о продуктах, поддерживающих немецкий, не идёт, мы в самом начале пути.

Мультиязычные сайты — это хорошо, но довольно муторно. И если для самых популярных языков достаточно иметь несколько вариантов текста, то с добавлением RTL (right-to-left) всё становится гораздо хуже. Приходится заводить новый набор стилей с заменой всего правого на левое и наоборот (касается свойств типа float, padding, margin etc), но и это ещё не все. Могут возникнуть ситуации, когда в одном документе соседствуют фразы на языках с разным направлением, здесь и начинает работать bidi. Если это кому-нибудь интересно....

За последние полгода было много статей о том, как написать крутой фреймворк объемом ~100 строк. Подкатом история о том, как написать ~2000 строк и ни одного фреймворка.

Сегодня я хочу рассказать вам о проекте, над которым я работал (и продолжаю работать) в Evernote с 2008 года, и которое несколько дней назад стало Свободным ПО.



Для многих разработчиков локализация ассоциируется с дополнительным пластом проблем: как поддерживать локализованные ресурсы в актуальном состоянии? А что если языков не 2-3, а 20-30? Как вовремя отправлять новые строки на перевод? А что если во время перевода разработка ушла вперед, и каких-то строк уже нет, а есть новые? Как мержить присланные переводчиками файлы ресурсов? Не секрет, что из-за этого многие просто забивают на локализацию или стараются отложить ее на потом.

Сейчас у Evernote более 150 млн пользователей по всему миру, более 70% этих пользователей находятся за пределами США, каждый месяц мы переводим по 15 тыс. новых слов в 40 с лишним проектах на более чем 26 языков, и выпускаем новые релизы наших продуктов одновременно на всех языках. При этом на техническую поддержку всей этой системы требуется один человек, и то изредка.

Как нам это удается?

В день запуска ботов в Telegram я за 3 часа собрал бота, который присылает температуру воздуха в ответ на геолокацию пользователя. С того же дня я бредил вызовом такси через бота в Telegram, так как API службы такси у меня был под рукой.

Моя цель – не просто рассказать, как я собрал бота для вызова такси, а поделиться этим процессом с другими, чтобы то время, которое я потратил на реализацию алгоритма не тратили остальные. Вследствие этой работы любая служба такси, при наличии API, может за 5 минут настроить шаблон этого бота под себя. Или владелец бота с большим количеством пользователей сможет быстро подключать к себе службу такси.