• Число учёных и лжеучёных в мире почти сравнялось
    +8
    Про шестиугольники — ячейки Бенара.
    Сковородки отличаются поверхностью (смачиваемостью, например), тестируемый материал — различными физическими показателями (например, коэффициентом вязкости).
    www.sgu.ru/sites/default/files/textdocsfiles/2015/02/12/yacheyki_benara.pdf
  • SmartCAT: облачные технологии для переводчиков
    0
    Для pdf мы не вносим в исходный текст, мы распознаем в отдельный документ и уже с ним работаем. В текстовые pdf пока ничего не планируется вставлять, пока есть большие другие задачи. Для отсканированных pdf вариант с распознаванием и конвертацией в другой формат — единственный возможный. Но в планах есть специальный интерфейс для редактирования распознанного текста до того, как он попадет на перевод.
  • SmartCAT: облачные технологии для переводчиков
    0
    SaaS модель, диапазон цен — дешевле аналогов :), есть мысли по дополнительным платным сервисам.
    Отделяемое решение — зависит от конфигурации.
  • SmartCAT: облачные технологии для переводчиков
    0
    Это список языков текстов для перевода, я правильно понимаю?

    Это список языков, поддерживаемых технологиями ТМ с морфологическим поиском. Эти языки можно использовать в качестве исходного языка и в качестве языка перевода.

    И тексты на всех этих языках корректно извлекаются из документов и разбиваются на отдельные единицы?

    Да. Если найдете ошибки, сообщайте нам — исправим и продлим вам период триала.

    На какие именно единицы разбиваются, по предложениям? Есть ли возможность самостоятельно указывать параметры деления?

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

    Как решаете проблему внесения перевода в «статичные» форматы, типа pdf и djvu? И решаете ли вообще?… А, вижу pdf и djvu только в проекте. Как тогда планируется решать?

    У нас есть встроенная интеграция с OCR технологиями, т.е. эти документы распознаются в docx, дальше обрабатываются обычным способом. pdf и djvu поддерживаются уже сейчас.

    И какие сейчас доступны форматы файлов для импорта?

    .docx, .sdlxliff, .srt, .ttx, .txt, .xlf, .xliff, .pdf, .djvu и различные форматы для изображений (через OCR).
  • SmartCAT: облачные технологии для переводчиков
    +2
    реализован ли в SmartCAT контроль качества перевода? Если предусмотрена проверка орфографии, то на каком движке она реализована? Есть ли в тестируемой версии интеграция с тестируемой Lingvo.pro? (в частности интересует автоматическая проверка терминологии, если она учитывает морфологию, то для каких языков?)

    Да, реализован, проверка осуществляется сразу на уровне сегмента после его подтверждения.
    Проверка орфографии реализована при помощи собственного движка, для вариантов исправления подключается еще и Яндекс.
    Интеграция с Lingvo.Pro есть, фактически все ресурсы доступны в одном интерфейсе. Проверка терминологии с учетом морфологии есть для всех поддерживаемых языков.
    Кроме того, проверяется ряд стандартных ошибок — пунктуация, капитализация и т.д.
    будет ли реализовано моноязычное редактирование? Случай для примера: перевод презентации на польский отдали маркетологам в польский офис, они внесли правки, не ориентируясь на исходный текст. Эти правки необходимо отразить в памяти переводов. Вручную это сделать можно, если объём правок небольшой, но если правок много, языков перевода тоже много, эти правки носят регулярный характер, то решение подобной задачи вручную может стать серьёзной проблемой.

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

    Пока нет, но будем делать, в частности, настройку того, какие теги в xml переводить и т.д.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    0
    Отделение текста и доступ к репозиторию — это очень правильно, без всякого сарказма.
    Но вылезают вопросы:
    1. А текст-то все равно кто-то проверяет? Кто-нибудь поддерживает терминологию?
    2. Какова будет процедура инициации перевода — по любому коммиту или по графику? Если переводить, пока стабилизируется код, можно напереводить лишнего. Например, если проект идет несколько месяцев-год, то заказывая 2-3 раза за релиз (а не постоянно маленькими порциями), можно снять 5-10% переводческих костов на подобных циклах. В абсолютных цифрах особенно заметно, если много языков.
    3. Разграничение прав — понятно, но вопрос-то — как выбрать тех, кто подходит для перевода? Переводческую компанию, локальных представителей, и т.д.
    Локальные люди может и заинтересованы в переводе, но у них обычно много других важных задач, плюс не у всех у них есть профильное образование. Не всегда знание 2 языков означает, что человек может переводить.
    Переводческая компания — тоже, как выбрать, кому доверять? Небольшой проект они может вообще не заметят, переведут как-нибудь.
    4. Координаторам тоже надо платить?

    Резюме: сервис, наверняка, хороший, и, если правильно применять, можно добиться хороших результатов. Просто про процессы на своей стороне тоже надо не забывать.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    0
    А, ну тогда мы об одном и том же :). 0,5 центов за слово это все-таки перебор, даже не после инъяза берут побольше, даже за редактуру, не говоря о переводе. С таким ценником в паре английский-русский — сразу в сад, как, впрочем, и >10.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    0
    Кто бы ни занимался переводами, но мое мнение осталось неизменным: переводчик должен видеть само приложение.
    Да, контекст крайне необходим. Об этом мы напишем подробнее в продолжении статьи :).
    Скажем: Save: Сохранение, Сохранить, Спасти, Спасение, Припасы — в различных частях элементов, скажем, будь то заголовок или кнопка, может нести совершенно разное написание.
    Это частично компенсируется вдумчивой работой над исходным текстом. Save > Save File, Save > Save a child, Save > Saved Goods. Либо использование дополнительных комментариев в материалах на перевод. Например, можно для каждой строки писать внутренний идентификатор контрола, при условии, что он сам осмысленный: Save — btnSaveFile, Save — dlgTtlSaveAChild и т.д.
    «Один файлов не найдено», да.
    Знакомо — "{0} file(s) was not found.", или просто «File(s) wasn't found.».
    Решение: проверка в коде на число файлов: «File wasn't found» для одного, «Files weren't found.» для нескольких. Или «One or more files weren't found.». Или отдельный механизм, который будет выводить нужную строку для определенного числа файлов — чтобы в том же русском согласовать правильные окончания. Да сложно, но это и есть задача подготовки локализуемого софта. Если вы готовите продукт на международный рынок, эти издержки необходимо учитывать.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    +1
    Судя по примерам, ERP системы?
    Они самые. Чем больше система и число разработчиков, тем больше вариаций в тексте. «Что-то не найдено», «что-то удалено», «что-то невозможно сделать» — это все можно передать кучей разных способов, не зависимо от сущности «что-то», да и самой программы…
    Тогда надо было осветить еще и локализацию (планы счетов, печатные документы и т.д)
    Мы скорее хотели в общих чертах раскрыть весь процесс, а планы счетов, печатные документы — это уже достаточно конкретные технические детали.
    Как у вас это организовано?
    Данный пост готовился от компании ABBYY Language Services, которая входит в группу ABBYY, и которая является LSP, т.е. ее сфера деятельности — лингвистические услуги и технологии. Поэтому непосредственно у «нас» «это» не организовано :), но от клиентов идут заказы на локализацию, мы анализируем, какой контент нам выдается, периодически получаем фидбэк от переводчиков, прогоняем автоматические проверки текстов. Например, при сдаче проекта проверяется consistency текста, если для разных исходных сегментов перевод одинаков — мы отлавливаем это. В каких-то случаях переводчик мог ошибиться, а в каких-то переводчик фактически сработал унификатором контента :) — и всплывают подобные примеры.
    Планы счетов и печатные документы
    Опыт тоже имеется, но он, очевидно, не охватывает все вариации. Все зависит от того, что требуется, как реализована поддержка локализации и т.д. Далее под сущностью подразумеваем план счетов или еще что-то.
    Если система будет работать только на языке перевода (например, компания не является международной), то сущность можно загнать на языке перевода непосредственно в базу данных — на этапе внедрения. Если таких клиентов несколько — можно подготовить скрипты, которые будут это делать.
    Если хочется видеть сущность на разных языках, то можно:
    Сделать специальную таблицу, где будут храниться записи сущности на исходном языке + на нужных языках перевода. При этом надо не забыть сказать об этом отделу локализации (нужно вести список локализуемых таблиц в базе), чтобы они могли вытащить исходный текст и положить перевод обратно в базу. Не забыть, как это будет поставляться клиенту — чтобы перевод попал в финальный билд. А на рантайме дергать нужное поле записи по коду языка.
    Если переводы хранятся в отдельной таблице/файлах, то можно добавить таблицу сущности в процедуру парсинга исходных кодов, чтобы вытаскивать из нее необходимый текст, добавить вытащенный текст в материалы на перевод, вернуть обратно — чтобы механизм локализации его мог подцепить и т.д. Например, в коде добавить метод/функцию, которая на рантайме при обращении к сущности будет искать нужный перевод в таблице переводов (если используется таблица в базе для хранения файлов) — по самой строке, или по какому-нибудь идентификатору.
    Печатные формы — на основе чего они создаются?
    В общем случае — хранить сами лейблы в таблице/файлах, парсить их оттуда. Перевод можно загонять в базу, или в такие же файлы, но на локальном языке, в файл со всеми переводами и т.д. — в зависимости от механизма локализации. Нужна прослойка, которая будет подставлять лейблы на конкретную форму на исходном языке (в текстовом формате, Crystal, SSRS, и т.д.), и дополнительный метод, который будет подставлять вместо исходного текста перевод.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    +2
    Мы думаем написать статью по данной тематике уже после продолжения про процесс перевода :).
    Судя по нашему опыту CL легко могут снизить издержки на перевод до 5-10%. Все не пробовали, поэтому про самые гибкие сказать не можем. В целом, у всех разный набор поддерживаемых форматов/редакторов (самостоятельный или в ворде), разный набор правил, которые можно кастомизировать и т.д. Да, системы привязаны к конкретным языкам, причем у разных систем — разные. Основной язык — английский. У CL есть возможность использования глоссариев, в каких-то системах интеграция может быть, если нет — то это можно сделать через API. Не очень понятно, что именно подразумевается под интеграцией с CAT. Скорее есть CL, в ходе работы над текстом выделяются термины и добавляются в глоссарий, который либо является частью CAT, либо поставляется как отдельный модуль к ней, либо вообще является отдельной программой. Новые термины проходят процедуру перевода и согласования, а уже потом используются— либо как часть CAT, либо через интеграции, либо через импорт-экспорт.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    +1
    Зависит от типа текста. Технический текст (софтовые строки, хэлпы) — особенно если исходный текст проверили и причесали, стандартные юридические тексты — не нэйтив справится вполне. Маркетинг, «креативный» текст — да лучше нэйтив. Кроме того, в переводческих компаниях (точнее, в LSP, Language Service Provider) принята практика «переводчик-редактор-корректор». Это, пожалуй, самая распространенная практика на рынке, если брать уровень серьезных компаний, а не «бюро переводов». Дороже — да, зато качественно. Собственно переводчик может быть нэйтивом на исходном языке, редактор- нэйтив на языке перевода, но который знает исходный язык, он проверяет параллельные тексты, а корректор- нэйтив, который не знает исходный язык, и читает только перевод. Либо проще — переводчик не нэйтив, вычитка — нэйтив.
  • Как локализовать приложение на много языков, чтобы не было мучительно стыдно
    0
    Первое стремление при локализации — как-то вытащить текст и отдать на перевод, «выстрелил и забыл». Часто это не работает. Сервис или переводческая компания — это лишь малая часть всей цепочки, а большая и важная часть — глоссарии и исходный контент, инженерные задачи, поддержка всего переводческого цикла (включая апдейты) — это остается на стороне заказчика. Плюс выбор конкретных исполнителей и сервиса — на чем он основан? Мы планируем написать вторую часть статьи, которая будет касаться уже собственно перевода и дальнейших процессов, и там затронуть эти вопросы.