Comments 13
На моем продукте я использую transifex. Честно говоря, у него много неудобных вещей и откровенно костылей, но есть одна вещь которая омрачает весь продукт. Там невозможно оперировать отдельными строками, только ресурсами. То есть для того, чтобы в проект запушить 1 новую фразу, нужно сначала скачать весь ресурс, потом добавить в этот ресурс новую фразу и запушить обратно. Вопрос: страдает ли от такого ваша платформа? Могу ли я пушить/удалять/проверять статус отдельных фраз?
Насколько я знаю, Crowdin тоже работает только с файлами целиком.
C галерки подсказывают, что уже можно работать с отдельными строками, подробнее вот здесь: http://blog.crowdin.com/post/91252586050/july-update-new-features
Очень качественное решение, за время использования практически всё понравилось. Несмотря на отсутствие русского интерфейса у сайта, техподдержка русскоязычная есть.
Что не понравилось (по ситуации на октябрь 2014 года):
1. Периодически слетают переведённые строки, если есть N однотипных файлов, и строки могут при перезаливке кочевать между файлами. Т.е. если разработчики используют формат, несовместимый с Краудином, и свой конвертер — надо им объяснить, что после конвертации новой версии строки должны оставаться в тех же файлах, что были в старой версии.
2. Плохо работает фильтрация по строкам внутри одного файла, если в параметрах выбран автоперевод дубликатов. Поддержка ответила, что это известный баг, но сроков исправления нет.
В остальном, на момент моего ухода с того проекта, у нас получалось поддерживать непрерывную локализацию на три target-языка в объёме чуть более 10 000 строк штатными средствами Краудина, и никаких особенных проблем не возникало. Переводчики были тоже довольны, хотя поначалу у них были некоторые трудности из-за строго англоязычного интерфейса Краудина (на наших проектах source-языком был русский, и переводчики работали именно с ним).
Конкурентов Краудину на текущий момент, если честно, я не вижу.
Что не понравилось (по ситуации на октябрь 2014 года):
1. Периодически слетают переведённые строки, если есть N однотипных файлов, и строки могут при перезаливке кочевать между файлами. Т.е. если разработчики используют формат, несовместимый с Краудином, и свой конвертер — надо им объяснить, что после конвертации новой версии строки должны оставаться в тех же файлах, что были в старой версии.
2. Плохо работает фильтрация по строкам внутри одного файла, если в параметрах выбран автоперевод дубликатов. Поддержка ответила, что это известный баг, но сроков исправления нет.
В остальном, на момент моего ухода с того проекта, у нас получалось поддерживать непрерывную локализацию на три target-языка в объёме чуть более 10 000 строк штатными средствами Краудина, и никаких особенных проблем не возникало. Переводчики были тоже довольны, хотя поначалу у них были некоторые трудности из-за строго англоязычного интерфейса Краудина (на наших проектах source-языком был русский, и переводчики работали именно с ним).
Конкурентов Краудину на текущий момент, если честно, я не вижу.
Русский интерефейс есть: http://crowdin.ru
Мы отказались от crowdin.net в пользу oneskyapp.com из-за ценовой политики crowdin, у нас один продукт для двух платформ, а плата в месяц подходит к 89 USD, при том, что мы используем сервис примерно раз в 3 месяца.
В то же время oneskyapp.com полностью бесплатный, а зарабатывают они на предоставлении профессионального перевода.
Хоть у crowdin.net и удобнее интерфейс, но в oneskyapp можно жить.
В то же время oneskyapp.com полностью бесплатный, а зарабатывают они на предоставлении профессионального перевода.
Хоть у crowdin.net и удобнее интерфейс, но в oneskyapp можно жить.
Еще неплохой проект, которым пользуемся – Lokalise. Есть все вышеперечисленные возможности и бесплатный, к тому же.
Пощупал немного на досуге. Что не понравилось по сравнению с Краудином:
— совсем нет Translation Memory (может стать проблемой на проектах свыше 500 строк)
— нельзя без танцев с бубном подсмотреть, как эта же фраза переведена на другие языки (зачастую требуется работать с парами A→B и A→C, где B и C — родственные языки, поэтому хочется иметь перед глазами как оригинал, так и уже имеющиеся переводы)
— нельзя быстро скопировать оригинальную фразу в перевод (полезно, когда строка состоит наполовину и более из форматных заглушек)
— хреновая дуракоупорность (переводчик легко может забыть строку формата и проглядеть маленький значок предупреждения)
Что понравилось по сравнению с Краудином:
— имея проект с изначальным языком A, можно работать исключительно в паре B→C (на свой страх и риск, повторяя ошибки предыдущего переводчика, но иногда это может и пригодиться)
API не щупал. В целом, на первый взгляд — для небольших проектов подходит вполне хорошо, для кровавого энтерпрайза — не очень. То, что бесплатное решение не вызывает явных рвотных рефлексов, уже вызывает уважение. Спасибо за наводку.
— совсем нет Translation Memory (может стать проблемой на проектах свыше 500 строк)
— нельзя без танцев с бубном подсмотреть, как эта же фраза переведена на другие языки (зачастую требуется работать с парами A→B и A→C, где B и C — родственные языки, поэтому хочется иметь перед глазами как оригинал, так и уже имеющиеся переводы)
— нельзя быстро скопировать оригинальную фразу в перевод (полезно, когда строка состоит наполовину и более из форматных заглушек)
— хреновая дуракоупорность (переводчик легко может забыть строку формата и проглядеть маленький значок предупреждения)
Что понравилось по сравнению с Краудином:
— имея проект с изначальным языком A, можно работать исключительно в паре B→C (на свой страх и риск, повторяя ошибки предыдущего переводчика, но иногда это может и пригодиться)
API не щупал. В целом, на первый взгляд — для небольших проектов подходит вполне хорошо, для кровавого энтерпрайза — не очень. То, что бесплатное решение не вызывает явных рвотных рефлексов, уже вызывает уважение. Спасибо за наводку.
А почему вы не ориентируетесь на одноразовых клиентов?
На нашем проекте около 1000 строк в сумме. Перевести проект нужно один раз, потом еще провести пару итераций правок. Это нам надо будет ежемесячно платить $30 только за то, что несколько наших xliff-файликов лежат в вашем интерфейсе?
Я понимаю, что у вас отличный интерфейс и куча плюшек, но я не сумею объяснить бизнесу необходимость в ежемесячной абонентской плате за то, чем мы не будем пользоваться. А отменять подписку, а потом, в случае необходимости в нескольких правках, ее опять продлевать как-то странно.
С такими задачами вам лучше обращаться к нам в Alconost. Процесс такой: вы даете нам ресурсные файлы, мы их переводим (или в Crowdin или с помощью других инструментов, или «по старинке» — ручками), если надо — тестируем, отправляем вам обратно. В результате вы получаете локализованный продукт, а как происходила локализация — от вас скрыто.
Интересно. У меня два вопроса — вы отказались от webtranslatit или ещё пользуетесь? И второй вопрос — раньше память переводов в Crowdin была общая для всех пользователей (т. е. качество локализации было невозможно контролировать) теперь они исправили эту проблему?
Мы ушли от webtranslateit после того, как они испортили код в ресурсных файлах на одном из больших проектов и мы с большой болью его восстановили.
В Crowdin можно использовать и глобальную память переводов (кстати, в этом случае выполненный перевод попадает в эту базу) и свою закрытую память для каждого проекта.
В Crowdin можно использовать и глобальную память переводов (кстати, в этом случае выполненный перевод попадает в эту базу) и свою закрытую память для каждого проекта.
Классно, довольно таки полезно, когда работаешь в проекте с переводами. Но небольшой совет — не надо совмещать локализацию и строковые переменные, есть 95% риск напороться на проблему «множественного числа». Если встретитесь с таким — очень хорошо стоит подумать, прежде чем браться.
У нас в команде _частично_ проще, к счастью. Тоже проект, на нескольких языках, рельсы-шмельсы, но к счастью встроенный i18n _частично_ спасает ситуацию с кучей языков, ибо в проекте все строки ссылаются на en.yml(в зависимости от текущего языка) файл, где и хранятся все строки, и вытаскиваются по ключу. И незадолго до деплоя, команда переводчиков со стороны заказчика все все переводит/обновляет переводы, создавая/обновляя копии es.yml, de.yml, и так далее, сколько языков там вам требуется.
Самая большая проблема — когда заказчику захотелось сделать в его проекте (проект по аудиту, рискам аудита, и прочему) изменяемые названия. Пользователь на одной там страничке вводит новое имя, и теперь его аудит называется не Audit, а, ну, Shmaudit. Окей, хорошо.
Посмотрели — у нас в куче описаний используется слово Audit, которое надо заменить на Shmaudit. А в другой куче описаний оно еще и с маленькой буквы используется. А еще дофига где оно в множественном числе, с маленькой или большой буквы. А у нас еще 5 языков есть других. А проект, мягко говоря — немаленький. В одном en.yml — 2548 строк. Это примерно 2500 строк переводов. А терминов этих — штук 50.
Если бы был один лишь английский — можно еще подключить какой-нибудь словарь, и все вроде как хорошо. Но словарей на 6 языков не напасешься. Да и ввод информации пользователем — нереально рандомная штука, и черт знает, что там со словарем получится. В общем, для аудиторского проекта решение на костылях не катит.
Решили просто к черту переписать все локали, где мы используем множественное число изменяемых терминов, на единственное. Все, что осталось — это делать lowercase или uppercase в зависимости от места, где переводим.
Вторая боль — немецкий язык. Предложения на немецком бывают в 2 раза длиннее, чем на английском. И в итоге, когда смотришь верстку на английском, все хорошо, все, прекрасно, переключаешь на немецкий, и… [нецензурная немецкая брань из советских фильмов], все нафиг съехало.
В чем мораль — использовать изменяемые термины, которые вводит пользователь, в файлах с локалями, а не дай бог, их еще и больше чем одна — приведет к боли. И переписыванию кучи текста. К счастью, над корректным переписыванием текста из множественного числа в единственное, думали на стороне заказчика люди, а не мы. А с немецким фиг знает, что делать. Верстать может с расчетом на него.
Как-то так.
:)
У нас в команде _частично_ проще, к счастью. Тоже проект, на нескольких языках, рельсы-шмельсы, но к счастью встроенный i18n _частично_ спасает ситуацию с кучей языков, ибо в проекте все строки ссылаются на en.yml(в зависимости от текущего языка) файл, где и хранятся все строки, и вытаскиваются по ключу. И незадолго до деплоя, команда переводчиков со стороны заказчика все все переводит/обновляет переводы, создавая/обновляя копии es.yml, de.yml, и так далее, сколько языков там вам требуется.
Самая большая проблема — когда заказчику захотелось сделать в его проекте (проект по аудиту, рискам аудита, и прочему) изменяемые названия. Пользователь на одной там страничке вводит новое имя, и теперь его аудит называется не Audit, а, ну, Shmaudit. Окей, хорошо.
Посмотрели — у нас в куче описаний используется слово Audit, которое надо заменить на Shmaudit. А в другой куче описаний оно еще и с маленькой буквы используется. А еще дофига где оно в множественном числе, с маленькой или большой буквы. А у нас еще 5 языков есть других. А проект, мягко говоря — немаленький. В одном en.yml — 2548 строк. Это примерно 2500 строк переводов. А терминов этих — штук 50.
Если бы был один лишь английский — можно еще подключить какой-нибудь словарь, и все вроде как хорошо. Но словарей на 6 языков не напасешься. Да и ввод информации пользователем — нереально рандомная штука, и черт знает, что там со словарем получится. В общем, для аудиторского проекта решение на костылях не катит.
Решили просто к черту переписать все локали, где мы используем множественное число изменяемых терминов, на единственное. Все, что осталось — это делать lowercase или uppercase в зависимости от места, где переводим.
Вторая боль — немецкий язык. Предложения на немецком бывают в 2 раза длиннее, чем на английском. И в итоге, когда смотришь верстку на английском, все хорошо, все, прекрасно, переключаешь на немецкий, и… [нецензурная немецкая брань из советских фильмов], все нафиг съехало.
В чем мораль — использовать изменяемые термины, которые вводит пользователь, в файлах с локалями, а не дай бог, их еще и больше чем одна — приведет к боли. И переписыванию кучи текста. К счастью, над корректным переписыванием текста из множественного числа в единственное, думали на стороне заказчика люди, а не мы. А с немецким фиг знает, что делать. Верстать может с расчетом на него.
Как-то так.
:)
Sign up to leave a comment.
Crowdin: обезболивающее при локализации