+1 голос
1,8тыс. просмотров

Я только начинаю полноценно настраивать глоссарий в нашем проекте, и у меня возникает много вопросов. Я想知道, не написал ли кто-нибудь документ с «лучшими практиками» или подсказками о том, как заставить всё работать правильно. Я прочитал документацию по разметке USFM и справку PT, но они не отвечают на многие вопросы.

Например, в длинных глоссариях используют ли люди номера глав, чтобы разбить его на более простые разделы? В PT есть 998 глав, но когда я прошёл по своему глоссарию и добавил главы в начале каждой новой алфавитной буквы, инструмент «Biblical Terms» (Библийские термины) для добавления новых терминов глоссария перестал работать, сообщая, что определённые главы не в правильном порядке или отсутствуют.

Если вы вручную добавляете новые элементы глоссария, как инструмент «Biblical Terms» добавляет новые термины глоссария в алфавитном порядке? Перестановит ли он ваши ручные правки, чтобы привести их в порядок?

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

Переведено машиной с языка English
Paratext от (1,9тыс. очков)
снова показан | 1,8тыс. просмотров

10 Ответов

+2 голосов
Лучший ответ

Если вы перейдёте по адресу https://vimeo.com/channels/paratext, вы найдёте два видео о записях глоссария. Я не уверен, что все лучшие практики были описаны, но вот несколько мыслей.

  1. Некоторые люди действительно используют номера глав для большого глоссария, но имейте в виду, что их необходимо удалить перед публикацией. И это может привести к сбою связи с «Biblical Terms». Я бы рекомендовал не использовать номера глав.
  2. Для печатной публикации вам разрешено 20 страниц глоссария (если это издание Wycliffe), поэтому создание огромного глоссария может стать проблемой при печати. Учитывайте то, что разрешено. Очевидно, для других целей (не печатных) вы можете сделать глоссарий любого размера.
  3. Инструмент «Biblical Terms» упорядочивает глоссарий в алфавитном порядке согласно настройкам языка — поэтому имейте это в виду при работе.
  4. Если у вас есть запись в глоссарии, вы можете связать её со словом в инструменте «Biblical Terms» — см. часть 2 видео.
Переведено машиной с языка English
от (9,9тыс. очков)

Я не могу говорить за другие пути публикации, но Publishing Assistant 5.1 больше не требует удаления номеров глав из глоссариев перед публикацией.

PADev.

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

Хорошо знать, поскольку большие книги в периферийных разделах действительно замедляют Paratext. (У меня есть глоссарии, которые были созданы независимо от инструмента «Biblical Terms», поэтому я не беспокоюсь о связях.)

Игнорирует ли PA номера глав в периферийных книгах? Рекомендуете ли вы добавлять метки глав (\cl) к каждой главе?

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

В целом, PA не игнорирует номера глав в периферийных разделах; сейчас это касается только глоссария. PA не игнорирует \cl, поэтому, если они добавлены, их необходимо удалить перед публикацией.

PADev.

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

Позвольте мне поделиться проблемой, которая возникла в одном из проектов. В глоссарии было много примечаний, но не было глав. Файлы с примечаниями стали настолько большими, что это сделало невозможным использование функции Send/Receive (Отправить/Получить) при довольно плохом широкополосном соединении. Причина в том, что каждое примечание привязано ко ВСЕМУ тексту в глоссарии (поскольку в глоссариях нет глав и стихов, ограничивающих текст, к которому привязано примечание, как это обычно бывает в тексте Писания). Поэтому будьте осторожны с этим. Вероятно, лучше не писать много примечаний в глоссарии, а экспортировать текст в файл Word и комментировать текст там.

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

Возможно ли использовать номера глав в периферийных книгах, а затем удалить их через initialChanges.txt, чтобы PA никогда не знал об этих разделах глав?

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

Да, большой глоссарий действительно замедляет Paratext, до такой степени, что в нем почти невозможно выполнять какое-либо редактирование. После набора нескольких слов он просто зависает, и вам приходится ждать довольно долго, пока он снова станет отзывчивым. У меня всего 8 ГБ ОЗУ, но при проверке использования памяти все еще видно, что около 50% свободно.

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

Есть ли решения для решения этой проблемы?

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

У меня 32 ГБ памяти, и я тоже испытывал замедление до такой степени, что глоссарий становился совершенно непригодным для использования.

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

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

Другой, гораздо более сложный вариант — это редактировать базовые файлы Notes (Примечания) с помощью текстового редактора, изменяя номера глав. Если в проекте несколько участников, вы хотите убедиться, что никто не делает примечания, пока вы это делаете. И когда примечания будут перемещены в новую главу, они могут или не могут прикрепиться в правильном месте. Поэтому вам, возможно, придется найти их в начале главы и прикрепить их позже. Преимущество в том, что вы будете видеть исходные примечания, а не резюме, которые вы написали сами.

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

У меня есть «лучшая практика», которой я хотел бы поделиться. Будьте внимательны к тому, как вы используете маркер ключевого слова \k в глоссарии.

Не используйте более одного \k на запись глоссария.

Изначально мы использовали более одного \k на запись, что мы унаследовали от нашего предыдущего перевода, и это, казалось, работало нормально в 7.5. Но в PT8 это вызвало большие проблемы. Например, в записи о Пасхе у нас могла быть дополнительная информация о других праздниках или связанных ключевых терминах. Таким образом, эти подзаписи были помечены \k. Но Paratext воспринимал их как новые записи глоссария, и поскольку глоссарий автоматически сортирует записи по алфавиту, информация была пересортирована таким образом, что стало очень трудно понять, что произошло. Позже нам сказали, что для этих подзаписей следует использовать какой-то другой маркер, например \bdit (жирный, курсив). Я не уверен, правильно ли это, но это помогло нам избежать проблем, с которыми мы сталкивались.

Переведено машиной с языка English
от (1,3тыс. очков)
+1 голос

Спасибо всем за ответы.

@Stephen+Katt, я вижу в документации USFM, что есть маркер \pi# для «Подзаписей или вторичных абзацев (если предпочтительно отступ)». Вы когда-нибудь рассматривали возможность использования его для ваших подзаписей? Если нет, была ли причина, по которой вы не хотели использовать этот маркер?

Файлы на Vimeo содержали ту же информацию, что и встроенные документы справки PT.

  • Добавление элементов глоссария через окно «Biblical Terms Renderings» абсолютно не работает с маркерами глав?
    • Кто-нибудь знает какие-нибудь хитрости, чтобы обойти это?
    • Если я буду использовать внешний редактор, чтобы изменить маркеры \c на \s, когда я хочу использовать инструмент Renderings, и обратно на \c, когда я хочу просматривать глоссарий, есть ли какие-либо потенциальные проблемы, которые кто-нибудь может предвидеть?
    • Как указал @CrazyRocky, наличие чрезвычайно длинного глоссария значительно замедляет PT.
  • Как и когда глоссарий применяет алфавитную сортировку?
    • Я установил порядок в диалоговом окне «Language Setting» (Настройки языка) –> «Alphabetic Characters» (Алфавитные символы).
      • Но глоссарий переставляет себя в неправильном порядке. Он назначает какой-то порядок, просто не тот, который я определил.
    • Я вручную создал запись в глоссарии в неправильном месте, и она никогда не перемещается в правильное место.
      • Затем я привязал её к «Biblical Term Renderings», и она перемещается в алфавитное место.
      • Так работает ли алфавитная сортировка только через окно BT/Renderings?
Переведено машиной с языка English
от (1,9тыс. очков)

В нашем случае мы не искали отдельных абзацев с отступом. Эти «подключевые слова» были встроены в текст, поэтому мы действительно хотели, чтобы они имели форматирование жирным шрифтом, как и другие ключевые слова, чтобы выделяться. Это произошло в основном потому, что мы адаптировали существующий предыдущий перевод и разбирались в вещах по ходу дела. Маркер \pi# мог бы сработать, если бы мы решили дать этим другим терминам своего рода официальную подзапись. Но я не изучал, как это выглядело бы для читателя.

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

Я только что провёл быстрый тест с двумя главами в глоссарии и смог добавлять новые термины как из инструмента «Biblical Terms», так и непосредственно в глоссарий.

Иногда я добавлял некоторые номера стихов (которые затем необходимо удалить перед публикацией), чтобы обеспечить лучший поиск в глоссарии.

Записи не переставляются, пока вы фактически не отрегулируете запись глоссария в инструменте «Biblical Terms».

Обратите внимание, что \pi \k…\k* всё равно будет сортировать запись, поскольку сортировка происходит по \k…\k*, независимо от маркера перед \k. И \pi будет изменён на \pi nl \p, чтобы запись начиналась с \p.

Я также заметил, что если я использую какой-то другой маркер для записи (например, \li или \q1), когда инструмент «Biblical Terms» редактирует эту запись или связывается с ней, она меняется на \p. Поэтому моя рекомендация — оставить их как \p, а затем изменить их, если это необходимо, когда глоссарий будет завершён.

Если вы хотите иметь подзаписи, одним из вариантов было бы использовать что-то вроде \pi \bdit…\bdit*, чтобы запись была отформатирована правильно, но не переставлялась.

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

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

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

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

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

Я хочу поддержать предложение anon848905 посмотреть два видео о глоссариях. Хотя обсуждение USFM очень базовое, они охватывают некоторые менее известные функции глоссария. Две, которые приходят на ум, — это работа со словами, имеющими много аффиксов, и восстановление связи между инструментом «Biblical Terms» и глоссарием после того, как она была нарушена чем-то таким, как изменение орфографии в тексте.

Я также рекомендую прочитать короткую статью Кэти Барнвелл о создании глоссариев, доступную в Translator’s Workplace. У неё есть хорошие советы о том, как решить, что должно и не должно входить в глоссарий. Я начал расширять её работу и добавил в неё сторону Paratext в глоссариях, но я не завершил этот проект. На самом деле, если кто-нибудь знает другие статьи или материалы по лексикографической стороне библейских глоссариев, я буду благодарен за информацию о них.

Переведено машиной с языка English
от [Expert]
(2,9тыс. очков)
0 голосов

Как люди делят свой глоссарий, чтобы его было легче читать и находить вещи? Используете ли вы маркеры \s, чтобы объявлять каждую новую букву? Например, \s A, \s B, \s C и т. д.

Если да, то как это работает с автоматической алфавитной сортировкой? Я задаюсь этим вопросом, потому что в какой-то момент, когда была применена алфавитная сортировка, порядок многих моих маркеров \s изменился.

Переведено машиной с языка English
от (1,9тыс. очков)

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

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

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

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

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

Хороший глоссарий — это ключ к пониманию Писания для многих читателей, впервые сталкивающихся с текстом в изолированных условиях.
Спасибо всем. Я рад этому обсуждению, полному сочувствия («мне тоже так») и уже содержащему много ценных предложений.

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

Дорогие коллеги, эти вопросы о структурировании глоссария действительно очень важны. Почему?

Подумайте обо всех тех непубличных проектах, у которых редко есть представители на форуме. Типичный современный читатель может быть из другой религии. Он или она мог найти приложение с Писанием в Play Store и читает впервые в жизни, как исследователь.

Поэтому нам нужен полный и удобный для пользователя глоссарий:

  • нам нужны кликабельные ссылки из основного текста на наиболее релевантные статьи глоссария

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

В PT8 уже есть отличные инструменты и прочные структуры, а именно главы, стихи и перекрёстные ссылки. Но глоссарий не использует их должным образом, и некоторые другие пользователи пытались использовать хаки с главами и стихами.

Я сам пробовал создавать главы и получал сообщения об ошибках: главы могут содержать только цифры и номера. Почему? Если вы снимете это ограничение (пожалуйста), тогда мы могли бы использовать самую прочную структуру «глава» и назначить их буквам нашего алфавита. Существует большая опасность: если вы позволите эту идею, то другие пользователи могут назвать главу ЛУК «5», главу ЛУК «пять». Это было бы очень плохо. Я не знаю почему, но, вероятно, плохо, это может сломать инструменты навигации. Тогда возникнет потребность в ещё одном инструменте проверки «недопустимых номеров глав во всех книгах, кроме глоссария».

Почему нам срочно нужно связывать статьи глоссария между собой:

В нашей грамматике есть маркеры класса для наших существительных в начальном положении слова. Поэтому единственное и множественное число одной статьи находятся очень далеко друг от друга: S_priest (ед. ч. «священник») не находится рядом с P_priest (мн. ч. «священники»).

Мы пишем наш глоссарий так, что наиболее типичное написание слова, требующего объяснения, в тексте является ключевым термином для нашего глоссария. Так, например, «фарисеи» чаще всего встречаются читателем во множественном числе, поэтому наше описание перечислено под «P_pharisee» (мн. ч. «фарисеи»). Но некоторые читатели могут вручную перейти к «S_pharisee» (ед. ч. «фарисей»), и тогда нам нужна ссылка. Поскольку наша система классов настолько богата, что даже носитель языка не может сказать по единственному числу, как образуется множественное число, есть несколько вариантов. Пока я просто пишу специальный символ-стрелку и другой термин глоссария, на который хочу сослаться, и пользователю приходится самостоятельно навигировать, чтобы найти основную статью.

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

Наш глоссарий становится большим. Ограничение в 20 напечатанных страниц не применимо к нашим приложениям для чтения. Нам также нужна помощь в навигации по нашему глоссарию для нашей обычной работы, просто прокрутка вверх и вниз занимает вечность. Ещё одна причина использовать существующие структуры глав и стихов, потому что для них у нас есть стабильные инструменты навигации вверху каждого окна PT8, и некоторые пользователи знают их горячие клавиши.

Другая функция, которая нам нужна, — это способ отслеживать работу над каждой статьёй глоссария. Я думаю, вы называете это project-progress (прогресс проекта). Пожалуйста, рассмотрите наш способ работы:

Мы не сажемся в определённые дни и не говорим: «давайте сделаем все статьи глоссария для буквы K». Скорее, мы переводим основной текст, и после каждой главы, пока у нас ещё есть наши исследования и заметки под рукой, мы выбираем все те слова, которые вызвали проблемы при переводе и/или при проверке и чтении с другими людьми. И тогда мы пишем эти статьи глоссария. Поскольку это ранние дни, у нас обычно пять-десять статей на главу текста, и это медленно уменьшается, так как мы всё чаще можем сказать: «мы уже сделали это».

Так что статьи глоссария должны иметь что-то вроде виртуальных номеров партий или виртуальных административных глав для целей применения project-progress и инструментов проверки. Поскольку мы не пишем их в алфавитном порядке, и новые статьи постоянно добавляются, в настоящее время нет ничего, чтобы отслеживать. Если ничего не появится в ближайшее время, мне придётся создать ещё один частный маркер и придумать строку статуса, основанную на наших проверенных «стадиях» и «задачах» из инструментов project-progress, но применённую к отдельным статьям глоссария.

Глоссарий — это не Писание, но это очень важный ключ для любого нового читателя, который позволяет получить доступ к основному тексту и понять его. Вы были бы удивлены, сколько «базовых» терминов неизвестны в нашей части мира. Поэтому мы хотим создать тот же уровень качества и применить существующие инструменты контроля качества и отслеживания.

Пожалуйста, радуйтесь этой обратной связи: мой коллега по команде вернулся очень довольным на прошлой неделе с сессии создания статей глоссария. Местный переводчик должен был много работать и разобраться с POSS_head (главным словом) вокруг нескольких новых концепций. Но в конце PRO (переводчик) сказал что-то вроде: «это так удивительно, мы так много учимся, и вещи становятся ещё более осмысленными». Смешно (или грустно), что эта рабочая сессия была после того, как глава основного текста уже была переведена, так что все термины и концепции должны были быть объяснены ранее. Похоже, работа над глоссарием превращается в мини-библейскую школу для всей нашей команды.

Я бы предположил, что — если мы посмотрим на существующие структуры, а не будем изобретать отдельную систему — большая часть работы для более функционального глоссария уже сделана. Это может быть так просто, как разрешение использовать главы и стихи с альфа-числовым, а не только числовым форматом (и, конечно, проверка нежелательных побочных эффектов). Мы готовы помочь в качестве тестировщиков, потому что это важно.

Спасибо за все идеи и обработку в этом обсуждении, буду следить за этим с нетерпением.

Переведено машиной с языка English
от (934 очков)

Тим,

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

Многие задачи перевода должны проверяться и пересматриваться периодически, а не только глоссарии. Функция Project Plan (План проекта) имеет тенденцию быть очень линейной, но циклические задачи могут быть включены в план с использованием тщательной формулировки, такой как черновик, ревизия 1, ревизия 2 и так далее. Если вам важно управлять различными этапами создания глоссария, тогда вы можете добавить несколько явных шагов в свой план. Например, на стадии Drafting (Черновик) имейте задачу «идентифицировать и пометить слова, которые могут потребовать статьи в глоссарии». В поле описания вы можете дать более подробные инструкции, такие как «пометьте ключевые слова в тексте маркерами \w…\w* или создайте статью глоссария из инструмента Biblical Terms (Библейские термины), но не составляйте определение».

На стадии Team Checking (Командная проверка) вы можете добавить задачу, такую как «команда пересматривает термины, помеченные для глоссария», и в описании сказать: «команда принимает или отклоняет термины, помеченные составителем для глоссария, и может добавить термины, которые были пропущены составителем».

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

Вы правы в том, что нет автоматических проверок, как в инструменте Parallel Passages (Параллельные отрывки) или глоссах для интерлинеатора. Если это важно для вас, тогда вы можете сделать запрос на функцию с флажком статуса, как в инструменте Parallel Passages. Как только команда считает, что оцениваемые параллельные отрывки достаточно параллельны, член команды отмечает маленький флажок, говорящий о том, что работа выполнена. Аналогично, для того, чтобы сказать, завершена ли статья глоссария или нет, требуется суждение носителя языка, поэтому флажок «пройден/не пройден» — это единственная система, которую я могу придумать для использования в этом случае.

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

Джесс, спасибо за ваш вклад в это обсуждение.

Только то, что вы описываете для Project Plan (Плана проекта), пока не работает в PT8 (или я что-то упускаю). Project Plan структурирован по главам. И наши статьи глоссария не имеют ничего (например, тега статуса), куда мы могли бы «привязать» их к конкретной главе. Мы могли бы сказать что-то вроде «горчичное зерно было впервые встречено и затем описано в контексте ЛУК 15». Но при работе по нашему Project Plan нет способа даже вывести все те статьи глоссария, которые «принадлежат» определённой главе.

В отличие от этого, в окне Biblical Terms (Библейские термины) я легко могу вывести все греческие термины для определённого стиха, главы или книги и т. д. Так что мы согласны с вами, но нам не хватает инструментов. Или, скорее, кажется, что это обсуждение превращается в сборник идей — которые могут позже трансформироваться в запрос на функцию для нескольких пользователей. Пока рано, я всё ещё собираю идеи и смотрю, что делают другие пользователи. Спасибо ещё раз.

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

В другом обсуждении поднялась тема использования Paratext и Fieldworks вместе. Я хотел бы видеть в будущем инструмент для создания глоссария, где пользователь мог бы помечать статьи в базе данных Fieldworks, которые будут импортированы в Глоссарий Paratext. Он мог бы быть динамическим, так что по мере уточнения данных для этих слов в Fieldworks статьи глоссария будут обновляться. Fieldworks уже позволяет вам брать подмножества ваших данных для создания разных словарей; почему бы не иметь категорию «Bible Glossary» (Библейский глоссарий) и не связать эту категорию с Paratext. Fieldworks — это очень хорошая программа для создания словарей, мы должны использовать эту мощь для создания лучших глоссариев, а не дублировать все эти функции в Paratext.

Переведено машиной с языка English
от [Expert]
(2,9тыс. очков)
0 голосов

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

Мы создали собственный маркер и протестировали, как можно отслеживать статус прогресса каждой статьи глоссария, используя наши внутренние коды из нашего Project Plan (Плана проекта).

Позже мы хотим попробовать идею присвоения виртуальных глав или номеров партий нашим статьям глоссария для отслеживания прогресса.

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

Текущая книга (GLO) не входит в план проекта. Поскольку это не библейская книга, ее нельзя добавить в план прогресса.

Так что последние несколько дней мы обсуждали здесь, как лучше работать над Глоссарием, а теперь PT8 говорит мне, что мы даже не можем проводить контроль качества и отслеживать прогресс. Это, конечно, не ошибка, но, пожалуйста, пересмотрите это решение.

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

Переведено машиной с языка English
от (934 очков)

Просто чтобы вы знали, почему было принято это решение:
Глоссарий, дополнительные книги и т. д. обычно проходят через другой (иногда совершенно другой) набор этапов, чем книги Писания. Поскольку Assignments and Progress (Назначения и Прогресс) позволяет задавать план только для всего проекта (т. е. для того, что вы делаете для каждой книги), чтобы вы могли добавить разные этапы для книг, не относящихся к Писанию, это загромодило бы остальные этапы для книг Писания, и вам, вероятно, пришлось бы отмечать выполнение задач в книгах, которые никогда не будут выполнены.

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

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

Спасибо @anon291708 за объяснение причин и контекста. Я согласен, что глоссарий требует других этапов проверки.

Я был просто шокирован тем, что PT8 не позволяет проводить никакую проверку через Project Plan (План проекта), он даже отказывается открывать окно проверки (так что мы даже не можем посмотреть наши ссылки для ручного отслеживания статуса, пока курсор находится внутри «книги» глоссария).

Инструмент Project Plan (План проекта) мощный, и мы могли бы легко потратить время, чтобы написать собственный этап с необходимыми пользовательскими задачами. Но поскольку инструмент полностью заблокирован, мы не можем использовать его вообще.

Инструмент отслеживания прогресса совершенно новый. И нам он очень нравится для обычных книг: Мы ведем учет на бумаге для всех задач, которые охватывают менее целой главы. А затем мы отмечаем галочки в PT, когда целая глава завершена. (В этом офисе в основном работают фрилансеры, которые приходят, когда находят время.) Поэтому мы используем систему нумерации ссылок, чтобы легко знать на бумаге, какая задача есть какая.

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

Я помню, что в старом PT7 у нас было только три или четыре задачи, определенных в Project Progress (Прогресс проекта), и я обнаружил, что мы могли настроить его, чтобы иметь максимум 8 задач. Но нам так и не удалось уместить отчетность по всем нашим локальным задачам всего в 8 шагов, поэтому отчетность была хаосом. Снова: мы ценим новый инструмент, у него есть весь этот потенциал, поэтому мы хотим лучше адаптировать его к нашей реальности.

Когда мы перешли на PT8 и впервые посмотрели на инструмент Project Plan (План проекта), нам понравилась его полнота, и мы нервничали из-за жесткости концепции и предложенных примеров планов. Как вы говорите, «позволяет задавать план только для всего проекта». Поэтому мы потратили почти час, чтобы снять все эти «эта задача nnnn может быть начата только после завершения задачи mmmm». Потому что это было совершенно нереально для наших локальных ситуаций, команды и того, как нам нужно учитывать болезни, отсутствия, отключения электроэнергии и прочее. Проект, над которым я работаю в PT, не является идеальным проектом, и мы скорее сообщаем и записываем уродливую правду, чем вынуждены не сообщать из-за идеального плана, потому что какой-то флажок был «заблокирован».

Я не забыл, что эта тема о глоссарии. Поэтому первое предложение — пожалуйста, разблокируйте инструмент отчетности, чтобы хотя бы окно можно было открыть из книги глоссария (для просмотра). Еще более полезным было бы позволить пользователям писать собственные этапы и задачи для того, что вы называете дополнительными книгами, пока не будет реализована более прекрасная идея. Мы работаем над глоссарием каждую неделю по мере продвижения основного перевода. И поскольку новые записи глоссария постоянно добавляются в разных местах, согласно алфавиту, нам нужны некоторые умные пользовательские способы отслеживания наших задач глоссария.

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

Далее я хочу поэкспериментировать с виртуальными главами или номерами партий, чтобы отслеживать наборы записей глоссария, над которыми работают в один рабочий день. Поэтому, пожалуйста, держите нас в курсе официального плана развития PT, чтобы, когда «настоящие инструменты» для отслеживания дополнительных книг будут готовы, мы могли перейти на них.

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

Свидетельство: Я преобразовал один Глоссарий из «без структуры» в «33 главы», для языка с 33 буквами в его алфавите. Некоторые из этих букв никогда не могут появляться в начале слова, поэтому эти главы останутся пустыми.

PT8, кажется, работает очень хорошо с этой новой настройкой. Новые записи глоссария — созданные из окна Key Terms (Ключевые термины) — по-прежнему сортируются точно там, где они должны быть по алфавиту. Не наблюдал никаких плохих побочных эффектов, и команда пока не жаловалась.

Это еще один печальный пример того, когда человек должен адаптироваться к своему компьютерному инструменту; PT8 не принимает ничего, кроме чисто числовых цифр после \c - поэтому я сделал алфавитную таблицу для команды, чтобы быстро находить записи глоссария: Хотите термин, начинающийся с «sh»? Идите в главу 28. Тем не менее, это гораздо лучше, чем старый многостраничный неструктурированный глоссарий.

Спасибо @anon848905, который, по-моему, первым поделился информацией о создании фиктивных «глав» в этой теме.

Переведено машиной с языка English
от (934 очков)
0 голосов

@anon716631 @mnjames

Вы подали обратную связь в Paratext по поводу этой проблемы с замедлением? Возможно, когда вы это сделаете, вы могли бы подробно описать вашу потребность в изменениях в том, как работает Глоссарий (и Project Notes (Примечания проекта) в Глоссарии).

Переведено машиной с языка English
от [Moderator]
(2,1тыс. очков)

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

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

Похожие вопросы

0 голосов
6 ответов 998 просмотров
У нас есть небольшой глоссарий (на данный момент 1 страница), и мы используем инструмент интерлинеаризации для создания ... принимал его? Какова лучшая практика в этом случае?
anon542642 294 задал вопрос фев 21, 2022
0 голосов
6 ответов 867 просмотров
Учитывая, что любые вставленные иллюстрации будут отправляться через Send/Receive, каковы лучшие практики работы с иллюстрациями ... в данном месте. Есть ли лучший способ?
drwww 448 задал вопрос окт 1, 2018
0 голосов
0 ответов 135 просмотров
I'd like to suggest that it's best practice to make a snapshot of a project by either making a back up, or (preferably ... doesn't fint the aims of this site, then please tell me!)
wdavidhj 1,4тыс. задал вопрос дек 6, 2017
0 голосов
1 ответ 104 просмотров
Я пытался найти библейские термины с записями в глоссарии в инструменте Библейские термины (Biblical Renderings Tool ... в глоссарии (например, добавить столбец для отображения)?
KR 151 задал вопрос мар 12
0 голосов
1 ответ 20 просмотров
Я прочитал Лучшие практики для глоссария (https://support.bible/3952/glossary-best-practices?show=3952#q3952). Информация там ... не так , я буду очень признателен! Спасибо, Пол
Paul 642 задал вопрос окт 21, 2025
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
They all joined together constantly in prayer, along with the women and Mary the mother of Jesus, and with his brothers.
Acts 1:14
3,045 вопросов
6,005 ответов
5,671 комментариев
2,026 пользователей