术语表最佳实践

Question

我刚开始在我们的项目中真正设置术语表（Glossary），因此遇到了很多问题。我想知道是否有人编写过“最佳实践”文档，或者分享过一些让一切正常运行的技巧。我读过 USFM 标记文档和 PT 帮助，但它们并没有回答很多问题。

例如，在很长的术语表中，人们是否使用章节号将其划分为更简单的部分？PT 有 998 个章节，但当我浏览术语表并在每个新字母开头添加章节时，用于添加新术语表条目的“Biblical Terms”（圣经术语）工具停止工作，提示某些章节顺序不正确或缺失。

如果您手动添加新的术语表条目，“Biblical Terms”（圣经术语）工具如何按字母顺序添加新条目？它会重新排列您的手动编辑以使其按顺序排列吗？

我相信随着我使用它的时间越长，我会产生更多的问题，我想知道我是否遗漏了某个能回答所有这些问题的优质资源。

机器翻译自 English 显示原文

Answer 1

If you go to https://vimeo.com/channels/paratext you will find two videos on Glossary entries. I’m not sure that all the best practices have been specified, but here are some thoughts.

1. Some folks do use chapter numbers for a large glossary, but be aware that these will need to be removed for publishing. AND this may cause the linkage to the Biblical Terms to fail. I’d recommend not using chapter numbers.
2. For print publication you are allowed 20 pages of glossary (if it is a Wycliffe publication) so building a huge glossary could be a problem at print time. Keep in mind what is permitted. Obviously for other uses (non-print) you can make the glossary as big as you want.
3. The Biblical Terms tool will alphabetize the glossary according to the order of the language settings - so keep this in mind as you work.
4. If you have an entry in the glossary you can link this to a word in the Biblical Terms tool - see video part 2.

较早的帖子 - 以原始语言显示

Comments

我无法代表其他出版路径，但 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 的速度，甚至到了几乎无法在其中进行任何编辑的程度。输入几个单词后，它会完全冻结，你必须等待相当长一段时间它才能再次响应。我只有 8GB 内存，但检查内存使用情况时，仍然显示大约 50% 是空闲的。

对我来说，将术语表划分为章节也不是一个选项，因为我所有的注释都会移动到书的开头。

有什么解决方案可以解决这个问题吗？

机器翻译自 English 显示原文

---

我有 32GB 内存，也遇到了速度减慢的问题，直到术语表完全无法使用。

注释问题也影响了我们。最终，速度减慢的问题如此严重，以至于我不得不移动注释。这花了不少时间，但最终是值得的。

我想我只是查看了打开的标志（flags），并将重要信息复制/粘贴到了新的标志中。这丢失了一些团队成员的历史和讨论，但我在创建新标志时对此进行了总结。

另一个更困难的选项是使用文本编辑器编辑底层的注释文件，更改章节编号。如果项目中有多个成员，你需要确保在你这样做时没有人正在做注释。而且当注释移动到新的章节时，它们可能不会附加在正确的位置。因此，你可能需要在章节顶部找到它们，稍后再重新附加。优点是你可以看到原始注释——而不是你自己写的摘要。

机器翻译自 English 显示原文

Answer 2

我有一个“最佳实践”可以分享。请注意您在术语表中使用 \k 关键词标记的方式。

每个术语表条目不要使用超过一个 \k。

我们最初每个条目使用了多个 \k，这是我们从前置翻译中继承的，在 7.5 版本中似乎运行良好。但在 PT8 中，这造成了很大的麻烦。例如，在一个关于逾越节的条目中，我们可能还有关于其他节日或相关关键词的额外信息。因此，这些子条目用 \k 标记。但 Paratext 将这些视为新的术语表条目，并且由于术语表会自动按字母顺序排序，信息被重新按字母顺序排列，这使得很难弄清楚发生了什么。后来我们被告知应该使用其他标记来标记这些子条目，例如 \bdit（粗体、斜体）。我不确定这是否正确，但它确实帮助我们避免了之前遇到的问题。

机器翻译自 English 显示原文

Answer 3

感谢大家的回复。

@Stephen+Katt，我在 USFM 文档中看到有一个 \pi# 标记，用于“子条目，或次要段落（如果偏好缩进）。”您是否曾考虑过将其用于您的子条目？如果没有，是否有原因不想使用该标记？

Vimeo 文件涵盖的信息与内置的 PT 帮助文档相同。

• 通过“Biblical Terms Renderings”（圣经术语渲染）窗口添加术语表条目是否绝对无法与章节标记一起工作？
  • 有人知道任何绕过此问题的技巧吗？
  • 如果我使用外部编辑器在想要使用渲染工具时将 \c 标记更改为 \s，在想要浏览术语表时再改回 \c，有没有任何人能预见到的潜在问题？
  • 正如 @CrazyRocky 指出的那样，极长的术语表会显著减慢 PT 的速度。
• 术语表何时以及如何应用字母排序？
  • 我已在“Language Setting–>Alphabetic Characters”（语言设置–>字母字符）对话框中设置了顺序。
    • 但术语表会重新排序自己，导致顺序不正确。它分配了某种顺序，只是不是我定义的那个。
  • 我在术语表中手动创建了一个位于错误位置的条目，它从未移动到正确的位置。
    • 然后我将其附加到“Biblical Term Renderings”（圣经术语渲染），它确实移动到了字母顺序的位置。
    • 那么，字母排序是否仅通过 BT/Renderings 窗口起作用？

机器翻译自 English 显示原文

Comments

mnjames:

我在 USFM 文档中看到有一个 \pi# 标记，用于“子条目，或次要段落（如果偏好缩进）。”您是否曾考虑过将其用于您的子条目？如果没有，是否有原因不想使用该标记？

在我们的情况下，我们并不是在寻找单独的缩进段落。这些“子关键词”与文本内联，所以我们真的只是希望它们像其他关键词一样具有粗体格式，以便突出显示。这主要是因为我们是基于现有的前置翻译进行改编，并在过程中摸索。如果我们决定给这些其他术语一个正式的子条目，\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 显示原文

Answer 4

我想支持 anon848905 观看两个关于术语表视频的建议。虽然对 USFM 的讨论非常基础，但它们确实涵盖了一些不太为人知的术语表功能。我想到的两个功能是处理具有许多词缀的单词，以及在文本中的拼写更改等因素断开“Biblical Terms”（圣经术语）工具与术语表之间的链接后重新建立该链接。

我还鼓励大家阅读 Katie Barnwell 关于制作术语表的短文，该文章可在《Translator’s Workplace》（译者工作场所）中找到。她有关于决定什么应该和不应该放入术语表的好建议。我开始扩展她的工作并混合了 Paratext 方面的术语表内容，但我还没有完成该项目。事实上，如果任何人知道其他关于圣经术语表辞书学方面的文章或材料，我将很高兴听到。

机器翻译自 English 显示原文

Answer 5

人们如何拆分他们的术语表以使其更易于阅读和查找？您是否使用 \s 标记来宣布每个新字母？例如 \s A, \s B, \s C 等。

如果是这样，这与自动字母排序如何配合？我在想这个问题，因为我的许多 \s 标记在应用字母排序时的某个时刻改变了顺序。

机器翻译自 English 显示原文

Comments

据我理解，最好在打印前添加节标题。它们会干扰新条目的字母排序。

机器翻译自 English 显示原文

---

我参与的一个项目正在将部分内容（例如每次一本圣经书）作为阅读应用发布。因此，在我们讨论最佳实践的同时，我们希望找到不需要大量手动调整即可发布每本书的工作流程（假设我们可以过滤术语表，并且每个阅读应用都始终包含相关的术语表）。

如果能有永久性的章节标题或章节，并且新条目也能保持稳定的字母排序，那将是一个很有帮助的改进。

机器翻译自 English 显示原文

Answer 6

一个好的术语表是许多初次接触圣经的孤立读者理解经文的关键。
谢谢大家。我很高兴看到这个帖子，里面充满了“我也是”的担忧，并且已经有很多好的建议。

我原本计划写一些关于操作方法的问题，可能还有一些功能请求，但这发生得太早了几天。

各位好，这些关于术语表结构的问题确实非常重要。为什么？

请考虑那些非公开的项目，它们很少在论坛上拥有发言人。典型的现代读者可能来自其他宗教。他或她可能在 Play Store 上发现了一个圣经应用，并作为探索者第一次阅读。

因此，我们需要一个完整且用户友好的术语表：

• 我们需要从正文到最相关术语表条目的可点击链接

• 我们需要一个选项，通过可点击链接从一个术语表条目引用到另一个

PT8 已经拥有出色的工具和坚实的结构，即章节、经文和交叉引用。但术语表并没有正确使用这些，一些其他用户尝试了使用章节和经文的变通方法。

我自己尝试创建章节时遇到了错误消息：章节只能包含数字。为什么？如果你们解除这个限制（请），我们就可以使用最坚实的结构“章节”，并将它们分配给我们字母表中的字母。这里有一个很大的危险：如果允许这个想法，其他用户可能会将 LUK 章节称为“5”，LUK 章节称为“five”。这将非常糟糕。我不知道为什么，但可能很糟糕，它可能会破坏导航工具。因此，将需要另一个检查工具，用于检查“所有非术语表书籍中的非法章节号”。

为什么我们需要紧急地在术语表条目之间建立链接：

我们的语法在词首位置有名词的类别标记。因此，一个条目的单数和复数相距甚远：S_priest 不在 P_priest 旁边。

我们编写术语表的方式是，每个“需要解释的词”在文本中最典型的译法是我们术语表的关键术语。因此，例如读者最常以复数形式遇到“pharisees”，所以我们的描述列在“P_pharisee”下。但一些读者可能会手动转到“S_pharisee”，然后我们需要一个链接。因为我们的类别系统非常丰富，即使是母语使用者也无法从单数判断复数是如何形成的，有几种选项。到目前为止，我只是写一个特殊的箭头符号和我要引用的其他术语表术语，用户必须自己导航以找到主要条目。

因此，章节（针对每个字母甚至字母组合）将非常有帮助。并且每个术语表条目都可以具有经文的地位。这样交叉引用和链接就成为可能。在 PT8 上进行变通操作从未感觉完全安全。所以我恳请开发人员考虑这一点并正式实现它。

我们的术语表正在变大。20 页印刷页的限制不适用于我们的阅读应用。我们还需要帮助来导航我们的术语表以进行日常工作，仅仅上下滚动就花费了永远的时间。使用现有的章节和经文结构的另一个原因，因为对于这些，我们在每个 PT8 窗口顶部都有稳定的导航工具，一些用户也知道他们的键盘快捷键。

我们需要的另一个功能是一种方法来跟踪每个术语表条目的工作后续。我想你们称之为项目进度。请考虑我们的工作方式：

我们不会在特定的日子坐下来说“让我们为字母 K 制作所有术语表条目。”我们更倾向于翻译正文，并在每个章节之后，当我们仍然手头有研究和笔记时，选择所有那些在翻译和/或与他人一起检查和阅读时造成问题的词。然后我们编写那些术语表条目。由于是早期阶段，我们通常每章文本有五到十个条目，并且随着我们更经常可以说“我们已经做过那个了”，它正在慢慢减少。

因此，术语表条目应该具有某种虚拟批次号或虚拟管理章节，用于应用项目进度和检查工具。由于我们没有按字母顺序编写，并且新条目不断被添加，目前没有任何东西可以跟踪。如果很快没有进展，我将需要创建另一个私有标记，并发明一个状态行，基于我们经过验证的项目进度工具中的“阶段”和“任务”，但应用于单个术语表条目。

术语表不是圣经，但对于任何新读者来说都是非常重要的关键，允许访问和理解正文。你会惊讶于在我们世界的一部分有多少“基本”术语是未知的。因此，我们希望创建相同的质量水平并应用现有的质量控制和后续工具。

请为这个反馈感到高兴：我的团队同事上周从制作术语表条目的会议回来时非常高兴。当地翻译者不得不努力工作，让 POSS_head 围绕几个新概念。但最终 PRO 说了一些像“这太神奇了，我们学到了很多东西，现在事情更有意义了”的话。有趣的是（或可悲的是）这次工作会议是在正文章节已经翻译之后，所以所有术语和概念应该在此之前解释。似乎术语表工作正在变成我们整个团队的迷你圣经学校。

我猜测，如果我们看现有的结构而不是发明一个单独的系统，大多数用于更功能性术语表的工作已经完成。它可能简单到允许章节和经文是字母数字的而不是仅数字的（当然检查不需要的副作用）。我们愿意作为测试者提供帮助，因为这很重要。

感谢所有在这个帖子中的想法和处理，我会急切地关注。

机器翻译自 English 显示原文

Comments

Tim，

如果你阅读 Kathie Barnwel 关于术语表的论文，你会看到她描述的过程更像你描述的。她说团队应该始终查看哪些术语应该在术语表中，并跟踪它们，随着从社区测试或顾问访问中收到反馈而不断修订术语表及其条目。团队对术语的理解随时间变化或深化并不罕见。团队应该随着理解的深化和变得更加细致而更新他们的术语表。

许多翻译任务应该定期检查和修订，不仅仅是术语表。项目计划功能（Project Plan Feature）往往非常线性，但可以使用诸如草稿、修订 1、修订 2 等仔细措辞将循环任务放入计划中。如果你认为管理制作术语表的不同步骤很重要，那么你可以在计划中添加几个明确的步骤。例如，在起草阶段（Drafting stage）有一个任务“识别并标记可能需要术语表条目的词”。在描述字段中，你可以给出更详细的说明，如“用标记 \w…\w* 标记文本中的主词，或从圣经术语工具（Bible terms tool）创建术语表条目，但不要起草定义。”

在团队检查阶段（Team Checking stage），你可以添加一个任务，如“团队审查标记为术语表的术语”，并在描述中说“团队接受或拒绝起草者标记为术语表的术语，并可能添加起草者遗漏的术语。”

然后你可以有一个单独的任务来起草术语表条目，然后稍后有一个任务来审查和修订它们。我希望你明白这个想法。如果你想在项目计划中关于术语表有更多细节，那么你应该将它们添加到你的计划中，计划将帮助你不会遗漏任何步骤。

你说得对，没有像平行经文工具（parallel passage tool）或互译器（interlinearizer）的注释那样的自动检查。如果这对你很重要，那么你可以为像平行经文工具那样的状态复选框提出功能请求。一旦团队认为正在评估的平行经文是适当平行的，团队成员就会勾选一个小框，表示工作已完成。同样，这需要语言使用者的判断力来说一个术语表条目是否完成，所以通过/失败复选框是我能想到的在这种情况下可以使用的唯一系统。

机器翻译自 English 显示原文

---

anon044949:

在团队检查阶段（Team Checking stage），你可以添加一个任务，如“团队审查标记为术语表的术语”，并在描述中说“团队接受或拒绝起草者标记为术语表的术语，并可能添加起草者遗漏的术语。”

然后你可以有一个单独的任务来起草术语表条目，然后稍后有一个任务来审查和修订它们。我希望你明白这个想法。如果你想在项目计划中关于术语表有更多细节，那么你应该将它们添加到你的计划中，计划将帮助你不会遗漏任何步骤。

Jess，感谢你对此的输入。

除了你描述的项目计划（Project Plan）在 PT8 中尚未起作用（或者我遗漏了什么）。项目计划是按章节结构的。而我们的术语表条目没有任何东西（如状态标签）可以让我们将它们“分配”到特定章节。我们可以说一些像“芥菜种（mustard-seed）首次遇到并在 LUK 15 的背景下编写”。但在处理我们的项目计划时，没有办法甚至调出所有那些“属于”特定章节的术语表条目。

相比之下，在圣经术语窗口（Biblical Terms window）中，我可以轻松调出特定经文、章节或书籍的所有希腊术语。所以我们同意你的观点，但我们缺少工具。或者更确切地说，这个帖子似乎正在变成一个想法的集合——这可能后来会变成多用户功能请求。现在还为时过早，我仍在收集想法并查看其他用户在做什么。再次感谢。

机器翻译自 English 显示原文

Answer 7

在另一个帖子中，提到了 Paratext 和 Fieldworks 一起使用的话题。我希望在未来看到一个术语表制作工具，用户可以在 Fieldworks 数据库中为条目打标签，这些标签将被导入到 Paratext 术语表中。它可能是动态的，因此随着 Fieldworks 中这些词的数据被细化，术语表条目也会更新。Fieldworks 已经允许你获取数据子集以制作不同的词典；为什么不设一个“圣经术语表”（Bible Glossary）类别并将该类别链接到 Paratext。Fieldworks 是一个非常优秀的词典制作程序，我们应该利用其力量来制作更好的术语表，而不是在 Paratext 中重复所有这些功能。

机器翻译自 English 显示原文

Answer 8

今天是这里的公共假日，所以办公室里很安静，我们可以做一些研发工作：

我们创建了一个自定义标记，并测试了如何使用项目计划（Project Plan）中的内部代码来跟踪每个术语表条目的进度状态。

稍后，我们想尝试为术语表条目分配虚拟章节或批次编号，以便进行进度跟踪。

遗憾的是，在处理术语表时，蓝色的“进度”图标并没有显示出来。更糟糕的是，当我试图打开窗口（以查找代码）时，我收到了这样一条相当严厉的信息：

当前书籍（GLO）不在项目计划中。由于它不是圣经书籍，因此无法添加到进度计划中。

因此，过去几天我们在这里讨论如何最好地处理术语表，而现在 PT8 告诉我，我们甚至无法进行质量控制和进度跟踪。这当然不是 bug，但请重新考虑。

我知道有些项目在出版前会让顾问检查术语表（虽然不像圣经文本那样，但类似），因为它包含在同一本书中，并对读者理解正文有重大影响（无论好坏）。那么，为什么要在技术层面阻止进度和质量跟踪呢？请制定政策的各位重新考虑一下。

机器翻译自 English 显示原文

Comments

Tim：

那么，为什么要在技术层面阻止进度和质量跟踪呢？请制定政策的各位重新考虑一下。

只是为了让大家了解这一决定背后的原因：
术语表、额外书籍等通常需要经过与圣经书籍不同（有时甚至大不相同）的步骤。由于“分配和进度”（Assignments and Progress）只允许为整个项目指定一个计划（即对每一本书都要做的事情），如果您要为非圣经书籍添加不同的步骤，就会使圣经书籍的其他步骤变得杂乱无章，而且您很可能被迫在那些永远不会完成的事情上打勾。

我认为有一个功能请求，允许按书籍指定计划，这样检查非圣经书籍时就不会那么烦人了。然而，这目前尚未成为高优先级事项。

机器翻译自 English 显示原文

---

感谢 @anon291708 提供理由和背景。我同意术语表需要不同阶段的检查。

令我震惊的是，PT8 竟然不允许通过项目计划进行任何形式的检查，它甚至拒绝打开检查窗口（因此，即使光标位于术语表“书籍”内，我们甚至无法查阅参考资料来进行手动状态跟踪。）

项目计划工具功能强大，我们可以轻松花些时间编写包含所需自定义任务的自定义阶段。但由于该工具完全被锁定，我们根本无法使用它。

进度工具是全新的。我们非常喜欢它用于常规书籍：我们在纸上跟踪所有覆盖不到整章的任务。然后，当整章完成后，我们在 PT 中勾选复选框。（这个办公室大多是自由职业者，他们有空时才会来。）因此，我们使用参考编号系统，以便在纸上轻松知道哪个任务对应哪个。

所以，当我给你反馈时，请记住我们喜欢并感激它。尽管如此，如果减少锁定功能，它可能更有用 - 这取决于其他用户确认或声明对其他项目无关紧要的内容。

我记得在旧的 PT7 中，项目进度中只定义了三个或四个任务，我发现我们可以自定义它，最多有 8 个任务。但我们从未设法将所有本地任务的报告压缩到仅 8 个步骤中，因此报告一团糟。再次强调：我们感激新工具，它具有所有这些潜力，这就是为什么我们希望让它更好地适应我们的现实。

当我们迁移到 PT8 并第一次查看项目计划工具时，我们喜欢其完整性，并对概念的僵化性和建议的示例计划感到紧张。正如你所说，“只允许为整个项目指定一个计划”。因此，我们花了将近一个小时取消勾选所有那些“只能在任务 mmmm 完成后才能开始任务 nnnn”的选项。因为这对于我们的本地情况、团队以及我们需要允许生病、缺席、停电等任何情况来说，完全是不可行的。我插手 PT 的项目并不是一个完美的项目，我们宁愿报告和记录丑陋的真相，也不愿被一个完美的计划强迫不报告，因为某个复选框被“锁定”了。

我没有忘记这个线程是关于术语表的。因此，第一个请求是请解锁报告工具，以便至少可以从术语表书籍打开窗口（用于查看）。更有帮助的是，允许用户为你所称的额外书籍编写自定义阶段和任务，直到更美好的想法得以实现。我们每周都在处理术语表，随着主要翻译的进行。由于新的术语表条目不断根据字母顺序推送到不同位置，我们需要一些聪明的自定义方法来跟踪我们的术语表任务。

昨天我为每个术语表条目创建了状态行的原型。使用与我们常规文本工作（拼写检查、多轮校对、特定检查等）相同的本地参考编号。对于一些没有意义的任务（例如为术语表解释中的每个单词分配希腊语术语），我们只是跳过。

接下来，我想尝试使用虚拟章节或批次编号来跟踪在一个工作日中一起处理的一组术语表条目。因此，请随时告知我们关于官方 PT 路线图的消息，以便当用于跟踪额外书籍的“真正工具”准备好时，我们可以迁移过去。

机器翻译自 English 显示原文

Answer 9

见证：我将一个术语表从“无结构”转换为“33 个章节”，用于一种字母表中有 33 个字符的语言。其中一些字符永远不能出现在单词开头，因此这些章节将保持为空。

PT8 在这种新设置下似乎运行得非常良好。从关键术语（Key Terms）窗口创建的新术语表条目仍然会精确地按字母顺序排序到它们需要的位置。尚未观察到任何不良副作用，团队到目前为止也没有抱怨。

这是人类不得不适应其计算机工具的又一个令人遗憾的例子；PT8 不接受 \c 后面的任何非纯数字字符——因此我为团队制作了一张字母表图表，以便快速查找术语表条目：你想找以“sh”开头的术语吗？去第 28 章。尽管如此，这仍然比旧的长达多屏的无结构术语表要好得多。

感谢 @anon848905，我相信是他/她首先在这个帖子中分享了创建虚拟“章节”的方法。

机器翻译自 English 显示原文

Answer 10

@anon716631 @mnjames

你们是否就这个速度问题向 Paratext 提交了反馈？也许当你这样做时，你可以详细说明你对术语表（以及术语表中的项目注释）功能变更的需求。

机器翻译自 English 显示原文

Comments

我原本以为开发者已经知道这个问题，但我现在提交了一个 bug 报告。

机器翻译自 English 显示原文