Mudlet: Остановить потерю переводов при изменении

Любая идея, как исправить? @толпа

Где вы проводите грань между сохранением или отказом от перевода?

Мне кажется, лучше всего вернуть перевод в TM, его очень легко снова вытащить, и переводчик может решить, хотят ли они повторно использовать текст или нет.

Именно эту линию нужно рисовать отдельно для каждой строки, как предлагает скриншот из Crowdin.

Я бы приветствовал возможность для переводчиков запускать этот всплывающий диалог после получения строк из github.

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

Я не считаю разумным тратить часы на каждую модификацию, исследуя, какие переводы не работают.

При использовании собственного лингвиста Qt (или, скорее, lupdate ) для обновления набора файлов .ts , специфичных для языка, непосредственно из исходного кода, у lupdate есть опция:

          Drop all obsolete and vanished strings.

Только если эта опция указана, это приводит к тому, что неиспользуемые или устаревшие - как я думаю, CrowdIn обрабатывает изменение комментария - строки, которые будут удалены из файлов .ts . Каким-то образом нам нужно заставить CrowdIn вести себя так для нас. :молиться:

Важно отметить, что я не думаю, что изменение комментария (хотя, возможно, изменение значения неоднозначности отличается) должно очищать перевод - для него может быть приемлемо потерять статус «одобрено», но не для того, чтобы его забыли.

Всем привет,

Имейте в виду, что вы можете сохранить переводы для измененных строк при обновлении файла через CLI/API/GitHub, указав параметр update_option в файле конфигурации ( crowdin.yml ), хранящемся в вашем репозитории.

Больше информации:
https://support.crowdin.com/configuration-file/#changed-strings-update

После внесения изменений приостановите и возобновите интеграцию в Crowdin, чтобы применить изменения.

Надеюсь, это именно то, что вам нужно!

Спасибо за ответ!

@Kebap , какой вариант вы бы хотели?

Спасибо, парни. Это круто. Подробно рассмотрю варианты.

Я хотел бы попробовать вариант «update_as_unapproved», это кажется хорошим компромиссом: переводы остаются нетронутыми, но теряют статус утвержденных.

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

Тем не менее, Crowdin, к сожалению, просто заменил строки вместо того, чтобы сохранить их переводы и просто удалить утверждение. Я делаю это неправильно?

Строка ранее имела перевод и одобрение (утверждение кажется невидимым в файле .ts?)

Параметр обновления «update_as_unapproved» был протестирован с коротким и длинным макетом yaml, оба с одинаковым результатом.

После изменения строки (или комментария) Crowdin теперь показывает измененную строку без перевода и одобрения.

Crowdin Diff сообщает, что строки «удалены и добавлены», а не «сохранены, но не одобрены».

-- Пожалуйста, ответьте над этой строкой --

        Hi everyone,

Кажется, проблема в том, что в вашем проекте файлы .html и
.ц. Файлы такого типа не имеют четкой структуры KEY:VALUE ,
поэтому, когда вы обновляете файлы, каждая измененная строка
считаются новыми строками. Это ожидаемое поведение системы,
но я спрошу разработчиков, можно ли что-то сделать в этом
случай, когда они в офисе!

Как бы вы оценили мой ответ?
Отлично [1] Хорошо [2] Плохо [3]

--
Искренне,
Ольга Кухта
Менеджер по работе с клиентами

Ссылки:

[1]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/1/
[2]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/2/
[3]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/3/

    > On Sat, Sep 8, 2018 at 1:34:23 EEST, Mudlet/mudlet <[email protected]> wrote:

Я хотел бы попробовать вариант "update_as_unapproved", это похоже на
хороший компромисс: переводы остаются нетронутыми, но теряют одобренные
положение дел.

Теперь, когда я проверил это, это, похоже, не сработало. Струны все еще потеряны
их переводы. Я даже зашел так далеко, что улучшил автоматический
создал краткий макет файла конфигурации yaml [1], чтобы
в точности отражать пример, приведенный в разделе Базы знаний [2]
ссылка выше.

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

Строка ранее была переведена и одобрена (одобрение кажется
невидим в .ts файле?)
[3]

Вариант обновления «update_as_unapproved» тестировался с короткими и длинными
макет yaml, оба к одному результату
[4]

После изменения строки (или комментария) Crowdin теперь показывает измененные
строка без перевода и утверждения
[5]

Crowdin Diff сообщает, что строки «удалены и добавлены», а не «сохранены, но
потеряли их одобрение»
[6]

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub [7] или отключите звук
резьба [8].

Ссылки:

[1] https://github.com/Kebap/Mudlet/blob/crowdin-test/.crowdin.yml
[2]
https://support.crowdin.com/configuration-file/#changed-strings-update
[3]
https://user-images.githubusercontent.com/117238/45245753-12b3a300-b2fe-11e8-819a-fbc1cab389cd.png
[4]
https://user-images.githubusercontent.com/117238/45245828-632b0080-b2fe-11e8-8457-d16f53e62976.png
[5]
https://user-images.githubusercontent.com/117238/45245723-e7c94f00-b2fd-11e8-831d-14f3c0151aa8.png
[6]
https://user-images.githubusercontent.com/117238/45245651-843f2180-b2fd-11e8-8744-b431244e39e8.png
[7]
https://github.com/Mudlet/Mudlet/issues/1961#issuecomment -419583856
[8]
https://github.com/notifications/unsubscribe-auth/AA0k1tqzDWWwb2qGudFk9ENRg7Hm3D-Hks5uYvRcgaJpZM4WeaRq

Да, Qt IDE использует файлы .ts. Конечно, это не ниша. Любая рекомендация от разработчиков Crowdin?

Отзывы от Qt были неубедительными:

(кебаб) Привет всем! Кто-нибудь когда-нибудь использовал веб-сайт службы для обработки переводов и переводчиков? Мы используем Crowdin, и они, похоже, плохо работают с форматом файлов Qt .ts. Кажется, они думают, что каждая измененная строка является новой строкой и удалит старые переводы. Подробности смотрите в следующей ветке. Как мы можем решить эту проблему? https://github.com/Mudlet/Mudlet/issues/1961
(frkleint) Кебап: я бы порекомендовал отправить сообщение в список рассылки http://lists.qt-project.org/mailman/listinfo/localization .
(Kebap) Похоже, что этот список рассылки посвящен самому проекту перевода Qt. Однако, может быть, есть другие люди, создающие свой собственный проект с Qt и переводящие на другие языки?
(frkleint) Кебап: Да, но правильные сопровождающие/люди его прочитают.

Позвольте мне перепроверить все детали, @Kebap. У меня в голове есть один «план Б», но его нужно проверить.

Можно ли хранить исходный текст/переводы в элемент файла .ts? в например, у вас может быть уникальный идентификатор строки

В настоящее время мы импортируем/загружаем один файл mudlet.ts , который содержит исходный текст, в CrowdIn, и они обрабатывают его для создания mudlet_xx_YY.ts , где xx — двухбуквенный код языка, а YY — это двухбуквенный код страны. Исходный mudlet.ts , я полагаю, сгенерирован/обновлен с помощью утилиты Qt lupdate , которая, как мне кажется, запускается из нашего исходного каталога ./translations как lupdate -locations absolute ../src/mudlet.pro -ts ./mudlet.ts {at по крайней мере, из ОС *nux}.

Есть альтернатива, но я не знаю, может ли CrowdIn работать так, как мы предоставляем отдельные файлы .ts (в настоящее время:

• mudlet_de_DE.ts
• mudlet_el_GR .ts`
• mudlet_en_GB.ts
• mudlet_es_ES.ts
• mudlet_fr_FR.ts
• mudlet_it_IT.ts
• mudlet_nl_NL.ts
• mudlet_pl_PL.ts
• mudlet_ru_RU.ts
• mudlet_zh_CN.ts
• mudlet_zn_TW.ts

) файлы в CrowdIn и поручите им/команде переводчиков работать над ними. Тогда это будет означать, что существующие усилия по переводу сохраняются в каждом файле .ts — на самом деле именно так Qt предусматривает выполнение перевода — потому что lupdate затем обновит каждый отдельный файл перевода с изменениями. из источников кода при запуске, но не будет отбрасывать (если явно не указано с помощью аргумента -no-obsolete ) старые тексты, которые больше не появляются в источниках. Недостатком этого является отсутствие единого исходного файла для всех переводов, который может запутать/не работать с системой CrowdIn. Положительным моментом является то, что # 1963 немедленно становится не проблемой, поскольку мы можем создать файл только для множественного числа mudlet_en_US.ts и просто включить его в загрузку на CrowdIn при выпуске / версии / любом изменении ...

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

Хотя мы могли бы просто назвать входной и выходной файлы по-разному?

Crowdin, безусловно, может обрабатывать несколько входных файлов, например, переводить разные строки. Однако по плану СлайСвена все они должны были иметь одинаковое содержимое. Это означало бы, что даже польская команда переводчиков увидит все файлы, включая мудлет_it_IT.ts и мудлет_ru_RU.ts и т. д. Поэтому мы не пошли дальше по этому пути и вместо этого выбрали один центральный файл перевода.

редактировать: объяснение создания файлов .ts правильное, но настоящая используемая команда: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

Не уверен, что вы имеете в виду, Вадим, но я думаю, что Кебап находится на том же пути - мы могли бы ввести все файлы, но как мы тогда скажем/скажем CrowdId, что только mudlet_ru_RU.ts из набора должны быть показаны пользователю Русские(Россия) переводчики?

@ vadi2 Вы правы, рекомендуется загружать один исходный файл, Crowdin сам сгенерирует переведенные файлы.

Пожалуйста, не загружайте файлы типа mudlet_ru_RU.ts в проект.

Возможно, мы можем организовать звонок, чтобы обсудить это в дальнейшем? Пожалуйста, свяжитесь со мной по адресу andriy(at)crowdin.com

У меня есть одна идея, которая наверняка сработает, но мне нужно услышать, будете ли вы довольны ею. Дело в том, что .ts не имеет уникальных идентификаторов для каждой строки - как в .po, файлах, где msgid является источником и идентификатором одновременно, <source> также является текстом и идентификатором. (наряду с элементами <context> и <name> каждая строка считается уникальной, и если вы изменяете <source> , строка считается новой, и вы не можете сохранять переводы для измененных строки в результате).

В любом случае, есть довольно хорошее решение/обходной путь, который я хотел бы обсудить/продемонстрировать вашей команде;)

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

Насколько я понимаю, схема уникального идентификатора сообщения также допустима в системе Qt, но с ней сложнее работать, а изменение в середине проекта - нетривиальная задача (две системы взаимоисключающие, и вам нужна очень хорошая методология чтобы придумать значимые идентификаторы) - и часть преимущества существующей схемы заключается в том, что повторяющиеся строки действительно объединяются в один общий перевод, просто изменение одного требует изменения и других, если они предназначены быть такой же...

Когда мы переводим все строки на языке на 100%, а затем редактируем некоторые в релизе, не будет ли по-прежнему очень легко просмотреть и снова добавить их обратно благодаря ТМ?

Эта проблема только кажется реальной проблемой, потому что мы еще не достигли 100%.

@ vadi2 , если вы хотите иметь возможность автоматически переводить вновь добавленные строки с помощью TM, вы можете настроить такой рабочий процесс с помощью функции Advanced Workflows (я только что включил ее для вашей учетной записи)
https://support.crowdin.com/advanced-workflows/

Спасибо, оценил :) будем изучать.

@Kebap написал:

редактировать: объяснение создания файлов .ts правильное, но настоящая используемая команда: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

-recursive является аргументом по умолчанию и не является необходимым - как и -locations absolute для новых файлов, по-видимому... :slightly_smiling_face: - Я только что узнал об этом, проверяя, какой эффект проблемы, которые lupdate все еще имеют с необработанными строковыми литералами С++ 11/14 { QTBUG , #1310} и теряются ли строки из файла mudlet.ts в результате их путаницы. .:хмурится:

@Kebap Это все еще проблема?

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

Кроме того, в настоящее время существует небольшая гонка, хотя большинство языков еще не приблизились к 100%, будут ли они переводить строки быстрее, чем они снова теряют переводы?

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

@Andrulko У вас есть какие-нибудь обновления здесь? Вы упоминали план Б выше..

Кроме того, почему Crowdin ведет себя так странно в ТМ сейчас!? Смотрите скриншот ниже для сравнения.

Все, что здесь было изменено нами, это h3 на a . Ни один другой тег не был затронут. Что случилось?

Ожидаете ли вы, что переводчики заменят каждые {[=-lt;-=]}h2{[=-gt;-=]}{[=-lt;-=]}u{[=-gt;-=]} на <h2><u> или, скорее, <0> вручную?

Ссылка на пример: https://crowdin.com/translate/mudlet/137/en-de
Снимок примера:

Я думаю, что это ошибка в ТМ Краудина. Вероятно, лучше сообщить им об этом отдельным вопросом.

Я сообщил им и здесь: https://crowdin.com/contacts

Здравствуйте, мы уже проверили ваш запрос и ответили на вашу электронную почту. Пожалуйста, дайте нам знать, если у вас есть другие вопросы!