Моя команда использует MadCap Flare для документации, и у нас есть редактор. Когда писатель готов, мы собираем пакет обзора во Flare и отправляем его редактору, а она вносит изменения и отправляет его обратно писателю для разрешения. (Последнее слово остается за писателем, и он несет ответственность за то, чтобы правки не влияли на техническую точность документации.) Пакет рецензирования, отправляемый автору, содержит размеченные изменения, аналогичные изменениям в режиме «отслеживания изменений» в Word. - зачеркивания для удалений, другой цвет для вставок и аннотации (выноски) для другого общения между редактором и автором.
Это все хорошо, но Flare требует, чтобы каждое изменение принималось или отклонялось отдельно, и проблема, с которой мы сталкиваемся, заключается в том, что редактирование одного абзаца может привести к дюжине отдельных изменений, каждое из которых необходимо обработать. Если бы вы случайно приняли 11 из них и отклонили один, вы бы испортили текст, потому что все изменения связаны между собой. Нам нужны группы атомарных изменений — принимайте все или ничего — в этой ситуации. (Flare поддерживает «принять все» или «отклонить все» на уровне файла, но это слишком грубо.)
Мы попробовали Google, и у нас в команде есть несколько довольно опытных пользователей Flare, и лучшее, что мы придумали, когда блок текста требует множества небольших правок, — это заставить редактора вырезать/вставить текст в новый блок, отредактируйте его , а затем удалите исходный. Но это утомительно, если делать это все время, и трудно предвидеть, если вносить изменения во время редактирования. Редактор не должен делать два прохода: один для чтения, а затем второй для возврата и внесения изменений либо «в строке» (если всего несколько), либо с помощью этой более сложной процедуры вырезания/вставки (если она более обширна).
Есть ли способ заставить Flare сгруппировать выбранный набор изменений вместе для поддержки атомарности? Я предполагаю, что редактор сможет пометить все изменения в абзаце как часть одной и той же группы, а писатель затем сможет сказать «да» или «нет» этой группе.
Мы используем сочетание версий 9 и 10. Если обновление всех до версии 10 поможет, мы можем это сделать.
Это не имеет ничего общего с системой контроля версий, поэтому поддержка GIT в версиях 11 и 12 — отвлекающий маневр.
Нет лучшего способа сделать это, начиная с версии 12 (апрель 2016 г.). То, что вы делаете, и ваша работа — это единственные два известных мне способа делать то, что вы хотите.
В нашей группе мы используем Track Changes для изменений, которые мы хотим, чтобы автор рассмотрел. Мы не используем Отслеживание изменений для изменений, которые мы имеем право вносить без повторной проверки первоначальным автором. Но это имеет нежелательный эффект, требуя, чтобы редактор продолжал нажимать кнопку включения/выключения.
Другим вариантом было бы разрешить рецензенту только аннотировать документ, а не редактировать документ, но это имеет другие болезненные последствия.
Наконец, я укажу, что во Flare 12, когда вы создаете PDF, у Flare теперь есть возможность распечатать содержимое отслеживания изменений и всплывающие подсказки с комментариями в PDF, чтобы люди могли просматривать сам файл PDF и видеть отслеживаемые изменения. Я знаю, что это все еще не отвечает на ваш вопрос напрямую, но это классная новая функция, связанная с тем, о чем мы говорим.
На этом этапе лучше всего отправить запрос функции на веб-сайт MadCap, предоставив им пример и вариант использования. Они довольно восприимчивы к обратной связи.
Джо
Моника Челлио
РДЦК