Хитрый трюк, чтобы конвертер кодировок пропускал определённый текст

Question

Я долго бился над этой проблемой и только что нашёл решение, поэтому делюсь им здесь, на случай, если кто-то ещё пытается предотвратить автоматическую транслитерацию определённого текста. Это решение и нелогично, и сомнительно.

Кратко:

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

Да, именно свойство nonpublishable, а не nonvernacular, как могло бы показаться уместным. Свойство nonvernacular на самом деле не влияет на то, что транслитерируется, а свойство nonpublishable в настоящее время не влияет на то, что публикуется, по крайней мере, не через Publishing Assistant.

Подробный контекст:

Я вот-вот буду вёрстать проект, прошедший автоматическую транслитерацию. Проект содержит определённые слова на национальном языке. Их можно найти в словарных статьях, во вступительных материалах и в сносках, и они помечены маркерами \znp …\znp*, которые я определил в custom.sty как стиль символов nonvernacular, publishable, потому что именно таким он и был.

В основном/исходном проекте текст на языке перевода и текст на национальном языке находятся в одной и той же системе письма. В проекте, прошедшем автоматическую транслитерацию, текст на языке перевода должен быть преобразован в традиционный алфавит, используемый только для этого языка, но текст на национальном языке должен остаться в его исходном алфавите. (Традиционный алфавит не может передавать ретрофлексные звуки, встречающиеся в национальном языке, и в любом случае было бы странно видеть национальный язык в традиционном алфавите языка перевода.)

Но пометка такого текста как nonvernacular не повлияла на предотвращение его транслитерации.

Также нельзя было указать TECkit map игнорировать текст, заключённый в маркеры \znp …\znp*, потому что сами маркеры не передаются в map для обработки. (Предположительно, раньше так было, потому что документация Paratext Help всё ещё говорит: «Убедитесь, что файл TECkit.map, который вы используете, сохраняет маркеры USFM, чтобы они не были преобразованы.»)

Хитрым решением было изменить свойство publishable на nonpublishable. Это не помешало Publishing Assistant опубликовать его.

Я не знаю, не создаст ли это проблем с другими путями вывода (SAB / Print Draft / PtxPrint / YouVersion via DBL), сейчас или в будущем они могут молча отбрасывать непубликуемый текст, поэтому это определённо вызывает беспокойство в отношении этого обходного решения.

Помимо того, что nonpublishable освобождает текст от автоматической транслитерации, мне неясно, какие другие эффекты могут иметь эти два свойства. Где-нибудь есть документация, которая это объясняет?

Переведено машиной с языка English Показать оригинал

Answer 1

PTXprint (или, точнее, макросы TeX ptx2pdf, которые он использует) будет рассматривать всё, что помечено как nonpublishable, как почти-комментарий. Python-программа также может применять свои собственные модификации; я не знаю.

Абзацные и символьные стили nonpublishable не будут производить вывод, и, в самом деле, это один из способов подавления номеров стихов и т. д.
Я сказал почти комментарий, потому что он не рассматривает ничего как настоящий комментарий: всё всё равно читается и интерпретируется, просто в конце абзаца/стиля символов материал отбрасывается.
Таким образом, вы не можете поместить туда \invalid USFM, и диапазонные контрольные точки (milestones), которые начинаются в непубликуемом тексте и не заканчиваются, всё ещё будут действовать после этого.

Однако, учитывая последовательность загрузки таблиц стилей в PTXprint, вы можете установить что-то как nonpublishable в custom.sty, а затем переопределить эту настройку в более поздней таблице стилей.

Переведено машиной с языка English Показать оригинал

Comments

Ах, хорошо это знать. Спасибо!

Переведено машиной с языка English Показать оригинал

Answer 2

Это действительно нелогично, и в прошлом это работало не так. Поэтому я считаю, что это должен быть баг. В прошлых проектах я довольно успешно использовал \tl…\tl* (Transliterated Word) для блокировки преобразования, которое имеет характеристики publishable nonvernacular. Я также использовал эти характеристики для пользовательских абзацных стилей в переднем и заднем материале через таблицу стилей frtback.sty. И nonpublishable НЕ должно проходить через Publishing Assistant в InDesign.

Надеюсь, мы сможем исправить это поведение, поэтому до тех пор вам следует быть гибким с вашей разметкой…

Благословений,

Переведено машиной с языка English Показать оригинал

Comments

Спасибо, Shegnada. Исходная разметка действительно была \tl ...\tl*, что может отражать тот факт, что в какой-то момент в прошлом это работало в этом проекте для предотвращения автоматической транслитерации. (Новый Завет был опубликован несколько лет назад, и теперь мы делаем всю Библию.) В этом случае этот баг является регрессией, чем-то, что сломалось, когда решалась другая проблема. Я сообщил об этом как PTXS-31555. Как только он будет исправлен, это будет просто вопросом обновления определения \znp, которое у меня есть в custom.sty и frtbak.sty, чтобы заменить nonpublishable на publishable.

Но теперь я задаюсь вопросом, не было ли функциональность намеренно изменена на основании рассуждений кого-то о том, что текст \tl должен проходить через конвертер. Этот проект с тех пор использует маркер \tl в Ветхом Завете для пометки слов, транслитерированных с исходных языков, таких как purim и mene, tekel, parsin. Намерение переводческой группы состоит в том, что эти слова будут обработаны конвертером, чтобы быть в том же алфавите, что и проект, но курсивом в том алфавите, который будет использован. Так что, я думаю, когда этот баг будет исправлен, нам также нужно будет помнить, чтобы переопределить \tl как vernacular в этом проекте, чтобы убедиться, что он действительно обрабатывается конвертером. Звучит ли это как правильный способ сделать это?

Я всё ещё очень хотел бы найти документацию о том, какие именно эффекты предполагается иметь у свойств publishable/nonpublishable и vernacular/nonvernacular. Пока я знаю только, что nonpublishable должно приводить к тому, что текст избегает преобразования кодировки и также избегает видимости в публикациях. Я считаю, что nonvernacular предназначено для избегания преобразования кодировки (хотя это сломано), и мне не известно о каких-либо других предполагаемых эффектах. Я задаюсь вопросом, влияют ли какие-либо из них на список слов для проверки орфографии, набор символов и т. д.?

Переведено машиной с языка English Показать оригинал

---

Я думаю, что, пока вы используете пользовательскую таблицу стилей, например, custom.sty в вашем случае, и документируете с помощью хэштегов, что вы делаете и почему, И добавляете заметку Paratext в первом месте \tl, поведение, которое вы ищете, должно быть в порядке на вашем пути PubAssist/InDesign.

Но ответы, которые вы получили на ваш исходный пост, указывают на то, что если у вас есть на уме другие выводы, вы должны протестировать и их, и, возможно, пользовательский маркер послужит вам лучше. Я не знаю точно.

Вы должны учитывать, что у вас задействованы два, или, возможно, как у меня обычно, три проекта. Исходный проект, автоматически преобразованный проект (не редактируемый) и (я рекомендую) третий проект, используемый для публикации, который получает свой текст из импорта из преобразованного проекта. Каждый из этих проектов может иметь разные пользовательские таблицы стилей, и хотя важно, чтобы в первом проекте были характеристики стилей, которые заставят конвертер работать правильно, таблицы стилей проекта, из которого вы публикуете, могут отличаться от них, и именно они влияют на опубликованный вывод. Таким образом, у вас есть некоторая гибкость, особенно если вы используете этот третий проект. Я могу поговорить с вами подробнее вне списка, если хотите, о других преимуществах третьего проекта, но я бы рассматривал второй и третий проекты как чисто выходные, и документация и т. д. всегда должна находиться в исходном проекте.

Благословений,

Переведено машиной с языка English Показать оригинал