Size: a a a

DocOps-сообщество

2019 July 22

IA

Igor Afanasyev in DocOps-сообщество
всем привет! 👋 Если вдруг будут вопросы по локализации вообще и по Serge (по-нашему, "сержу") в частности — задавайте!
источник

NV

Nick Volynkin in DocOps-сообщество
Igor Afanasyev
всем привет! 👋 Если вдруг будут вопросы по локализации вообще и по Serge (по-нашему, "сержу") в частности — задавайте!
Хочу прикрутить в Zing экспорт и импорт в XLIFF. К чему конкретно их прикручивать? Есть уже другие конвертеры форматов?
источник

NV

Nick Volynkin in DocOps-сообщество
Идеально было бы сделать какой-то подключаемый экстеншен, потому что я буду реализовывать конкретные требования наших переводчиков.
источник

IA

Igor Afanasyev in DocOps-сообщество
@Nick_Volynkin Zing сам по себе не является самостоятельным CAT: он заточен и работает только как фронтенд к Serge, и понимает исключительно .po-файлы. А Serge умеет с XLIFF работать: https://serge.io/docs/plugins/parser/parse_xliff/ (так что в связке Serge+Zing локализовать XLIFF можно)
источник

IA

Igor Afanasyev in DocOps-сообщество
все поддерживаемые форматы описаны тут: https://serge.io/docs/plugins/parser/metaparser/ (см. список в левом меню)
источник

IA

Igor Afanasyev in DocOps-сообщество
XLIFF, кстати, сам по себе наверняка же не является исходным форматом в вашей документации? Лучше всего локализовать исходные файлы напрямую, минуя XLIFF как промежуточное звено (Serge сам создаст промежуточные файлы для локализации)
источник

IC

Ivan Cheban in DocOps-сообщество
И всё-таки XLIFF - более универсальный формат, который понимают такие кошки как Традос, мемокью
источник

IA

Igor Afanasyev in DocOps-сообщество
Ivan Все верно: XLIFF по определению есть универсальный *промежуточный* формат для передачи от заказчика к переводчику. Просто при использовании конкретно Serge он не нужен в качестве *входного* формата: Serge сам умеет работать с исходными файлами и сам генерирует промежуточные файлы на перевод (кстати, помимо .po он может генерить и те же xliff-файлы).
источник

NV

Nick Volynkin in DocOps-сообщество
Igor Afanasyev
XLIFF, кстати, сам по себе наверняка же не является исходным форматом в вашей документации? Лучше всего локализовать исходные файлы напрямую, минуя XLIFF как промежуточное звено (Serge сам создаст промежуточные файлы для локализации)
Я бы рад его миновать, но переводчикам он нужен
источник

NV

Nick Volynkin in DocOps-сообщество
Igor Afanasyev
Ivan Все верно: XLIFF по определению есть универсальный *промежуточный* формат для передачи от заказчика к переводчику. Просто при использовании конкретно Serge он не нужен в качестве *входного* формата: Serge сам умеет работать с исходными файлами и сам генерирует промежуточные файлы на перевод (кстати, помимо .po он может генерить и те же xliff-файлы).
Куда он будет эти файлы генерить, если не подключать к нему Zing?
источник

IA

Igor Afanasyev in DocOps-сообщество
так, тут надо разобраться подробнее: что переводчикам на самом деле нужно? XLIFF или Zing? если использовать Zing, то там никакие форматы файлов наружу не торчат (обмен с Zing происходит в .po, но это внутренняя кухня Serge+Zing)
источник

IC

Ivan Cheban in DocOps-сообщество
Думаю, переводчики будут юзать свою любимую кошку ))
источник

NV

Nick Volynkin in DocOps-сообщество
Ivan Cheban
Думаю, переводчики будут юзать свою любимую кошку ))
Ну для интерфейсных текстов они уже используют Crowdin. Я надеюсь, что мы и в документации перейдём на онлайн-CAT. Но хочется оставить возможность использовать оффлайновые инструменты. Так людям спокойнее.
источник

IA

Igor Afanasyev in DocOps-сообщество
С Zing такое не получится (онлайн + офлайн именно через XLIFF). Можно настроить онлайн + офлайн через PO-файлы (в случае использования связки Serge+Zing), или только офлайн через XLIFF (используя только Serge), но, положа руку на сердце, лучше единожды перейти на непрерывную локализацию онлайн (Serge+Zing) и про пересылку файлов и форматы файлов забыть как страшный сон. Вы столько себе и переводчикам времени сэкономите...
источник

IC

Ivan Cheban in DocOps-сообщество
Все зависит от того, насколько хорош ваш zing. Я лучше мемокью пока не встречал инструмента.
источник

IA

Igor Afanasyev in DocOps-сообщество
Zing и memoQ — совершенно разные инструменты и по набору функций, и по идеологии, и по применимости к определнным процессам локализации.. Я не хотел бы тут активно продвигать Zing, но готов продолжить дискуссию в личке и ответить на вопросы, если есть желание 🙂

И, кстати, от переводчика в наши дни выбор инструмента зависит все меньше (к счастью или нет — тема для отдельной дискуссии). Обычно их ставят перед фактом, что работать нужно будет в такой-то системе.
источник
2019 July 23

NK

ID:0 in DocOps-сообщество
Ещё один пост про ретроспективы конференций в Plesk, на этот раз даже со скриншотами. Вообще это отчёт по #HighloadSiberia, о ретроспективах — в конце поста.

https://habr.com/ru/company/plesk/blog/460885/
источник

NV

Nick Volynkin in DocOps-сообщество
Igor Afanasyev
Zing и memoQ — совершенно разные инструменты и по набору функций, и по идеологии, и по применимости к определнным процессам локализации.. Я не хотел бы тут активно продвигать Zing, но готов продолжить дискуссию в личке и ответить на вопросы, если есть желание 🙂

И, кстати, от переводчика в наши дни выбор инструмента зависит все меньше (к счастью или нет — тема для отдельной дискуссии). Обычно их ставят перед фактом, что работать нужно будет в такой-то системе.
Я не буду возражать против продвижения Zing ))
источник

IC

Ivan Cheban in DocOps-сообщество
На сайте не очень-то много написано о цинге. Как оно работает с ТМ и ТБ, какие функциональные возможности.
источник

IA

Igor Afanasyev in DocOps-сообщество
Ivan посмотреть живьем можно тут: https://translate.evernote.com/ru/
а вот тут небольшая документация: https://translate.evernote.com/pages/getting-started/
источник