+1
1.8k 次瀏覽

我剛開始在我們的專案中真正設定術語表(Glossary),因此遇到了很多問題。我想知道是否有人曾撰寫過「最佳實務」文件或提示,說明如何讓一切正常運作。我已經閱讀了 USFM 標記文件以及 PT 的說明,但這些文件並未解答許多問題。

例如,在長篇術語表中,人們是否使用章節編號來將其劃分為更簡單的區塊?PT 有 998 個章節,但當我瀏覽我的術語表並在每個新字母開頭處添加章節時,用於添加新術語條目的「Biblical Terms」工具停止運作,並提示某些章節順序錯誤或缺失。

如果您手動添加新的術語項目,「Biblical Term」工具如何按字母順序添加新的術語項目?它會重新排列您的手動編輯以使其按順序排列嗎?

我相信隨著我使用時間越長,我會有更多問題,我也想知道我是否遺漏了某些能解答所有這些問題的良好資源。

機器翻譯自 English
Paratext (1.9k 點) 提出
已重新顯示 | 1.8k 次瀏覽

10 個回答

+2
最佳回答

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.
舊文章 - 以原文顯示
(9.9k 點) 提出

我無法代表其他出版路徑,但 Publishing Assistant 5.1 不再要求在出版前從術語表中移除章節編號。

PADev.

機器翻譯自 English

這很好,因為周邊書籍中的大型書籍確實會減慢 Paratext 的速度。(我有獨立於「Biblical Terms」工具創建的術語表,因此我不擔心連結問題。)

PA 是否忽略周邊書籍中的章節編號?您建議為每個章節添加章節標籤(\cl)嗎?

機器翻譯自 English

一般而言,PA 不會忽略附錄中的章節編號;目前它只出現在詞彙表中。PA 不會忽略 \cl,因此如果添加了這些標記,則必須在出版前將其移除。

PADev.

機器翻譯自 English

讓我分享一個在專案中出現的問題。該專案的詞彙表中有很多註釋,但沒有章節。註釋檔案變得非常大,導致在相當差的寬頻連線下,傳送/接收(send and receive)變得不可能。原因是每個註釋都附著在詞彙表中的所有文本上(因為詞彙表沒有章節和節來限制註釋附著的文本範圍,這與聖經文本通常的情況不同)。所以請務必注意這一點。最好不要在詞彙表中寫太多註釋,而是將文本匯出到 Word 檔案,並在那裡對文本進行註釋。

機器翻譯自 English

是否可以在周邊書籍中使用章節編號,然後透過 initialChanges.txt 移除它們,以便 PA 永遠不知道這些章節劃分?

機器翻譯自 English

是的,一個大型詞彙表確實會減慢 Paratext 的速度,甚至到幾乎無法在其中進行任何編輯的程度。輸入幾個字後,它就會凍結,你必須等待相當長的時間它才能恢復響應。我只有 8GB 的 RAM,但檢查記憶體使用量時,仍顯示大約 50% 是空閒的。

對我來說,將詞彙表分為章節也不是一個選項,因為我在其中的所有註釋都會被移動到書籍的開頭。

有什麼解決方案可以解決這個問題嗎?

機器翻譯自 English

我有 32GB 的記憶體,也經歷了減慢到詞彙表完全無法使用的程度。

註釋問題也影響了我們。最終,減慢問題如此嚴重,我不得不移動註釋。這花了相當多的時間,但最終是值得的。

我想我只是查看了開啟的旗標(flags),並將重要資訊複製/粘貼到新的旗標中。這失去了一些歷史和團隊成員的討論,但我在製作新旗標時對其進行了總結。

另一個更困難的選項是使用文字編輯器編輯底層的註釋檔案,更改章節編號。如果專案中有多個成員,你希望在這樣做時確保沒有人正在製作註釋。而且當註釋移動到新章節時,它們可能或不正確地附著在正確的位置。因此,你可能需要在章節頂部找到它們,稍後再重新附著。優點是你將看到的是原始註釋——而不是你自己撰寫的總結。

機器翻譯自 English
0

我有一個「最佳實務」要分享。請注意您在術語表中如何使用 \k 關鍵字標記。

每個術語表條目不要使用超過一個 \k。

我們最初每個條目使用了多個 \k,這是我們從前譯本繼承過來的,在 7.5 版本中似乎運作良好。但在 PT8 中,這造成了很大的麻煩。例如,在關於逾越節的條目中,我們可能還有關於其他節日或相關關鍵詞的額外資訊。因此,這些子條目被標記為 \k。但 Paratext 將這些視為新的術語表條目,並且由於術語表會自動按字母順序排序,資訊被重新按字母順序排列,使得很難弄清楚發生了什麼。後來我們被告知應該使用其他標記來標記這些子條目,例如 \bdit(粗體、斜體)。我不確定這是否正確,但它確實幫助我們避免了之前遇到的問題。

機器翻譯自 English
(1.3k 點) 提出
+1

感謝大家的回覆。

@Stephen+Katt,我在 USFM 文件中看到有一個 \pi# 標記,用於「子條目,或次要段落(如果偏好縮進)」。您是否曾考慮過將它用於您的子條目?如果沒有,是否有原因讓您不想使用該標記?

Vimeo 上的影片涵蓋了與內建 PT 說明文件相同的資訊。

  • 透過「Biblical Terms Renderings」視窗添加術語表項目是否絕對無法與章節標記一起使用?
    • 有人知道任何繞過此問題的技巧嗎?
    • 如果我使用外部編輯器,在想要使用 Renderings 工具時將 \c 標記更改為 \s,在想要瀏覽術語表時再改回 \c,是否有任何潛在問題是大家能預見的?
    • 正如 @CrazyRocky 所指出的,極長的術語表會顯著減慢 PT 的速度。
  • 術語表何時以及如何應用字母排序?
    • 我已在「Language Setting–>Alphabetic Characters」對話方塊中設定了順序。
      • 但術語表重新排列自己的順序是不正確的。它分配了某種順序,只是不是我定義的那個。
    • 我在術語表中手動創建了一個條目,位置錯誤,但它從未移動到正確的位置。
      • 然後我將其附加到「Biblical Term Renderings」,它就移動到了字母順序的位置。
      • 那麼,字母排序是否只透過 BT/Renderings 視窗起作用?
機器翻譯自 English
(1.9k 點) 提出

在我們的情況下,我們不是在尋找單獨的縮進段落。這些「子關鍵字」與文本並列,因此我們真的只是希望它們像其他關鍵字一樣具有粗體格式,以便突出顯示。這主要是因為我們是從現有的前譯本改編過來的,並且是一邊摸索一邊進行。如果我們決定給這些其他術語它們自己的某種正式子條目,\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」工具與術語表之間的連結。

我也鼓勵大家閱讀 Katie Barnwell 關於製作術語表的短篇文章,該文章可在 Translator’s Workplace 中找到。她對於決定什麼應該和不應該放入術語表有很好的建議。我開始擴展她的工作並混合了 Paratext 方面的術語表,但我還沒有完成該專案。事實上,如果有人知道其他關於聖經術語表詞典學方面的文章或材料,我很樂意聽到。

機器翻譯自 English
[Expert]
(2.9k 點) 提出
0

人們如何拆分他們的術語表以使其更容易閱讀和查找?您是否使用 \s 標記來宣布每個新字母?例如 \s A, \s B, \s C 等。

如果是這樣,它如何與自動字母排序協同工作?我之所以這麼問,是因為我的許多 \s 標記在應用字母排序時在某个時候改變了順序。

機器翻譯自 English
(1.9k 點) 提出

我的理解是,最好在列印前添加章節標題。它們會干擾新條目的字母排序。

機器翻譯自 English

我參與的一個專案正在將部分內容(例如一次一冊聖經書籍)作為閱讀應用程式(reading apps)出版。因此,當我們討論最佳實踐時,我們希望找到不需要為每本書的出版進行大量手動調整的工作流程(假設我們可以篩選詞彙表,並確保每個閱讀應用程式都有一個相關的詞彙表)。

如果能有一種方法來實現永久的章節標題或章節,以及新條目的穩定字母排序,那將是一個很有幫助的改進。

機器翻譯自 English
0

一份良好的術語表是許多首次接觸聖經的孤立讀者理解經文的關鍵。
感謝大家。我很高興看到這個討論串,裡面充滿了「我也是這樣」的擔憂,並且已經有了許多好的建議。

我原本計畫寫一些關於操作方法的問題,可能還有一些功能請求,但這件事發生得太早了。

各位好,這些關於術語表結構的問題確實非常重要。為什麼呢?

請考慮那些非公開的專案,它們很少在論壇上有發言人。一位典型的現代讀者可能來自其他宗教。他或她可能在 Play Store 上找到了一個聖經應用程式,並作為探索者第一次閱讀聖經。

因此,我們需要一份完整且易於使用的術語表:

  • 我們需要從主文本到最相關術語表條目的可點擊連結

  • 我們需要一個選項,允許從一個術語表條目引用另一個條目,同樣透過可點擊的連結

PT8 已經擁有強大的工具和穩固的結構,即章節和經節以及交叉引用。但術語表並未妥善利用這些功能,一些其他使用者嘗試過使用章節和經節的變通方法。

我自己嘗試建立章節時遇到了錯誤訊息:章節只能包含數字。為什麼?如果解除這個限制(請),我們就可以使用最穩固的結構「章節」,並將其分配給我們字母表中的字母。這存在很大的危險:如果允許這個想法,其他使用者可能會將路加福音(LUK)的章節稱為「5」或「五」。這將非常糟糕。我不知道為什麼,但可能很糟糕,它可能會破壞導航工具。因此,將需要另一個檢查工具來檢查「所有非術語表書籍中的非法章節編號」。

為什麼我們迫切需要連結術語表條目之間:

我們的語法在詞首位置有名词的類標記。因此,同一條目的單數和複數形式相距甚遠:S_priest(單數祭司)不在 P_priest(複數祭司)旁邊。

我們編寫術語表的方式是,將文本中最典型的「需要解釋的詞」作為術語表的關鍵詞。例如,讀者最常以複數形式遇到「法利賽人」,所以我們的描述列在「P_pharisee」下。但有些讀者可能會手動前往「S_pharisee」,然後我們需要一個連結。因為我們的類系統非常豐富,即使是母語者也不確定單數如何構成複數,有幾種選項。目前我只是寫一個特殊的箭頭符號和我想要引用的其他術語表詞彙,使用者必須自己導航以找到主要條目。

因此,章節(針對每個字母或甚至字母組合)將非常有用。並且每個術語表條目都可以具有經節的狀態。這樣交叉引用和連結就成為可能。在 PT8 中進行變通操作從不感覺完全安全。所以我懇請開發人員考慮這一點並正式實現它。

我們的術語表變得很大。20 頁印刷頁的限制不適用於我們的閱讀應用程式。我們也需要幫助來導航我們的術語表以進行日常工作,僅僅上下滾動就花費了永遠的時間。另一個使用現有章節和經節結構的理由,因為對於這些,我們在每個 PT8 視窗頂部都有穩定的導航工具,一些使用者也知道他們的鍵盤快捷鍵。

我們需要的另一個功能是進行每個術語表項目工作後續處理的方法。我想你們稱之為專案進度。請考慮我們的工作方式:

我們不會在特定的日子坐下來說「讓我們為字母 K 製作所有術語表條目。」我們更傾向於翻譯主文本,並在每個章節之後,當我們的研究和筆記還容易獲取時,選擇所有那些在翻譯和/或與他人檢查和閱讀時造成問題的詞彙。然後我們編寫這些術語表條目。由於是早期階段,我們通常每個文本章節有五到十個條目,並且隨著我們更頻繁地說「我們已經完成那個了」,它正在慢慢減少。

因此,術語表條目應該具有某種虛擬批次編號或虛擬管理章節,用於應用專案進度和檢查工具。由於我們不是按字母順序編寫它們,並且新條目不斷被添加,目前沒有東西可以追蹤。如果很快沒有進展,我將需要創建另一個私人標記並發明一行狀態,基於我們經驗證的專案進度工具中的「階段」和「任務」,但應用於個別術語表條目。

術語表不是聖經,但它是任何新讀者訪問和理解主文本的一個非常重要的關鍵。你會驚訝於我們世界這個地區有多少「基本」詞彙是未知的。因此,我們希望創建相同水平的質量並應用現有的質量控制和後續處理工具。

請為這個反饋歡喜:我的團隊同事上週從一次製作術語表條目的會議回來時非常高興。當地翻譯人員必須努力工作,並圍繞幾個新概念處理 POSS_head。但最後 PRO 說了一些像「這太驚人了,我們學到了很多,現在事情更有意義了」的話。有趣的是(或可悲的是),這次工作會議是在主文本章節已經翻譯之後進行的,所以所有詞彙和概念應該在此之前已經解釋過。似乎術語表工作正在變成我們整個團隊的迷你聖經學校。

我猜測,如果我們查看現有結構而不是發明一個單獨的系統,大多數使術語表更具功能性的工作已經完成。它可能簡單到允許章節和經節是字母數字而不是僅數字(當然要檢查不想要的副作用)。我們願意作為測試者提供幫助,因為這很重要。

感謝這個討論串中的所有想法和處理,我會熱切關注。

機器翻譯自 English
(934 點) 提出

Tim,

如果你閱讀 Kathie Barnwel 關於術語表的論文,你會發現她描述的過程更像你描述的。她說團隊應該始終關注哪些詞彙應該包含在術語表中,並追蹤它們,隨著來自社區測試或顧問訪問的反饋不斷修訂術語表及其條目。團隊對某個詞彙的理解隨時間改變或深化並不完全異常。隨著理解加深並變得更加細緻,團隊應該尋找更新他們的術語表。

許多翻譯任務應該定期檢查和修訂,不僅僅是術語表。專案計畫功能(Project Plan Feature)傾向於非常線性,但可以使用如草稿、修訂 1、修訂 2 等謹慎措辭將循環任務放入計畫中。如果你認為管理製作術語表的不同步驟很重要,那麼你可以在計畫中添加幾個明確的步驟。例如,在起草階段(Drafting stage)有一個任務「識別並標記可能需要術語表條目的詞彙」。在描述欄位中,你可以給出更詳細的指示,如「使用標記 \w…\w* 標記文本中的主詞,或從聖經詞彙工具(Bible terms tool)創建術語表條目,但不要起草定義。」

在團隊檢查階段(Team Checking stage),你可以添加一個像「團隊審查標記為術語表的詞彙」的任務,並在描述中說「團隊接受或拒絕起草者標記為術語表的詞彙,並可能添加起草者遺漏的詞彙。」

然後你可以有一個單獨的任務來起草術語表條目,然後稍後再有一個任務來審查和修訂它們。我希望你明白這個想法。如果你希望在專案計畫中獲得關於術語表的更多細節,那麼你應該將它們添加到計畫中,計畫將幫助你不錯過任何步驟。

你是正確的,沒有像平行經文工具(parallel passage tool)或互換式(interlinearizer)的註釋那樣自動檢查。如果這對你很重要,你可以為一個狀態複選框提出功能請求,就像平行經文工具那樣。一旦團隊認為正在評估的平行經文是適當平行的,團隊成員就會勾選小方框表示工作已完成。同樣,這需要語言使用者的判斷來決定術語表條目是否完成,因此通過/失敗複選框是我能想到的唯一可以用於這種情況的系統。

機器翻譯自 English

Jess,感謝你對此的輸入。

只是你描述的專案計畫(Project Plan)在 PT8 中還不起作用(或者我漏掉了什麼)。專案計畫是根據章節結構化的。而我們的術語表條目沒有任何東西(像狀態標籤)可以讓我們將它們「分配」給特定章節。我們可以說一些像「芥菜種(mustard-seed)是在路加福音 15 章的語境中首次遇到並撰寫的」。但在執行我們的專案計畫時,沒有辦法甚至調出所有那些「屬於」特定章節的術語表條目。

相比之下,在聖經詞彙(Biblical Terms)視窗中,我可以輕鬆調出特定經節、章節或書籍的所有希臘語詞彙。所以我們同意你的觀點,但我們缺少工具。或者更準確地說,這個討論串似乎正在變成一個想法的集合——這可能後來會轉化為多使用者功能請求。還太早了,我還在收集想法並觀察其他使用者在做什麼。再次感謝。

機器翻譯自 English
0

在另一個討論串中,提到了同時使用 Paratext 和 Fieldworks 的話題。我希望未來能看到一個術語表製作工具,使用者可以在 Fieldworks 資料庫中標記條目,這些條目將被導入 Paratext 術語表。它可以是動態的,隨著這些詞彙的數據在 Fieldworks 中精煉,術語表條目也會更新。Fieldworks 已經允許你提取數據子集來製作不同的字典;為什麼不設有一個「聖經術語表」(Bible Glossary)類別並將其連結到 Paratext。Fieldworks 是一個非常好的字典製作程式,我們應該利用其力量來製作更好的術語表,而不是在 Paratext 中重複所有這些功能。

機器翻譯自 English
[Expert]
(2.9k 點) 提出
0

這裡今天是國定假日,所以辦公室裡很安靜,我們可以利用這段時間做一些研究和開發:

我們建立了一個自訂標記(custom marker),並測試了如何使用專案計畫(Project Plan)中的內部代碼來追蹤每個詞彙表(glossary)條目的進度狀態。

稍後,我們想嘗試為詞彙表條目分配虛擬章節或批次編號,以便進行進度追蹤。

不幸的是,在詞彙表中工作時,藍色的「進度」圖示不會顯示出來。更糟糕的是,當我試圖開啟視窗(以查詢代碼)時,我只收到了這條相當嚴厲的訊息:

目前書籍(GLO)不在專案計畫中。由於它不是聖經書籍,因此無法加入進度計畫。

因此,過去幾天我們在這裡討論了處理詞彙表的最好方法,現在 PT8 卻告訴我,我們甚至無法進行品質控制和進度追蹤。這當然不是錯誤(bug),但請重新考慮。

我知道有些專案的顧問會在出版前檢查詞彙表(雖然不像聖經文本,但性質相似),因為詞彙表會包含在同一本書中出版,並對讀者理解主文本產生重大影響(無論是好是壞)。那麼,為什麼要在技術層面阻擋進度追蹤和品質追蹤呢?請制定政策的各位重新考慮。

機器翻譯自 English
(934 點) 提出

為了讓你知道這個決定背後的理由:
詞彙表、附加書籍等通常有一套與聖經書籍不同(有時差異巨大)的步驟。由於「指派與進度」(Assignments and Progress)只允許為整個專案指定計畫(即你對每一本書所做的步驟),如果你要為非聖經書籍加入不同的步驟,會使聖經書籍的其他步驟變得雜亂,而且你很可能被迫在那些永遠不會執行的書籍中勾選項目。

我認為有一個功能請求,允許按書籍指定計畫,這樣檢查非聖經書籍時就不會令人煩躁了。然而,這尚未成為高優先級事項。

機器翻譯自 English

感謝 @anon291708 提供理由和背景。我同意詞彙表需要不同的檢查步驟。

我只是對 PT8 不允許任何類型的檢查 感到震驚,透過專案計畫(Project Plan)它甚至拒絕開啟檢查視窗(因此當游標在詞彙表「書籍」內時,我們甚至無法查詢我們進行手動狀態追蹤所需的參考資料)。

專案計畫工具功能強大,我們很容易花些時間寫一個包含所需自訂任務的自訂階段。但由於該工具完全被鎖定,我們根本無法使用它。

進度工具是全新的。我們非常喜歡它在普通書籍中的表現:我們用紙張追蹤所有覆蓋範圍小於整個章節的任務。然後,當整個章節完成時,我們在 PT 中勾選方塊。(這個辦公室主要由自由工作者組成,他們有空時才會來。)因此,我們使用參考資料編號系統,以便在紙上輕鬆知道哪個任務是哪個。

所以,當我給你們回饋時,請記住我們喜歡並感激這個工具。不過,如果減少鎖定,它可能會有更多用途——這取決於其他使用者確認或聲明對其他專案無關緊要的內容。

我記得在舊版的 PT7 中,專案進度(Project Progress)中只定義了三或四個任務,我發現我們可以自訂它,最多有 8 個任務。但我們從未成功將我們所有本地任務的報告壓縮到僅 8 個步驟中,因此報告是一團糟。再次強調:我們感激這個新工具,它具有所有這些潛力,這就是為什麼我們希望它更好地符合我們的現實。

當我們遷移到 PT8 並第一次看到專案計畫工具時,我們喜歡其完整性,但對其概念的僵化以及建議的範例計畫感到緊張。正如你所說,「只允許為整個專案指定計畫」。因此,我們花了近一個小時取消勾選所有那些「只能在任務 mmmm 完成之後才能開始任務 nnnn」的選項。因為這對我們的本地情況、團隊以及我們需要允許生病、缺席、停電等情況來說,完全不切實際。我手頭正在處理 PT 的專案並不是一個完美的專案,我們寧願報告和記錄醜陋的真相,也不願被一個完美的計畫強迫不報告,因為某個方框被「鎖定」了。

我沒有忘記這個討論串是關於詞彙表的。因此,第一個請求請解鎖報告工具,至少讓視窗可以從詞彙表書籍中開啟(以便查看)。更有帮助的是,允許使用者為你所謂的附加書籍撰寫自訂階段和任務,直到一個更美好的想法得以實現為止。我們每週都在處理詞彙表,隨著主要翻譯的進行。由於新的詞彙表條目不斷根據字母順序被推送到不同位置,我們需要一些聰明的自訂方法來追蹤我們的詞彙表任務。

昨天我為每個詞彙表條目建立了狀態列的原型。使用與我們正常文本工作(拼寫檢查、多輪校對、特定檢查等)相同的本地參考編號。而一些沒有意義的任務(例如為詞彙表解釋中的每個字分配希臘語術語)我們就跳過。

接下來,我想實驗使用虛擬章節或批次編號來追蹤在一個工作日內一起處理的詞彙表條目集合。因此,請隨時告知我們官方的 PT 路線圖,這樣當追蹤附加書籍的「真正工具」準備好時,我們就可以遷移過去。

機器翻譯自 English
0

見證:我將一個詞彙表從「無結構」轉換為「33 個章節」,用於一種字母表中有 33 個字符的語言。其中一些字符永遠不能出現在詞首,因此這些章節將保持為空。

PT8 似乎與這個新設定運作得非常好。新的詞彙表條目——從關鍵術語(Key Terms)視窗建立的——仍然會精確地排序到它們在字母順序中需要的位置。尚未觀察到任何不良副作用,團隊目前也沒有抱怨。

這是另一個令人難過的例子,人類必須適應他的電腦工具;PT8 不接受 \c 之後的任何純數字以外的內容——所以我為團隊製作了一個字母表圖表,以便快速查詢詞彙表條目:你想要以「sh」開頭的術語嗎?去第 28 章。即便如此,這仍然比舊的長達多屏的無結構詞彙表好得多。

感謝 @anon848905,我相信他/她是第一個在這個討論串中分享製作虛假「章節」的人。

機器翻譯自 English
(934 點) 提出
0

@anon716631 @mnjames

你們是否已向 Paratext 提交關於此減慢問題的回饋?也許在這樣做時,你可以詳細說明你對詞彙表(以及詞彙表中的專案註釋)功能變化的需求。

機器翻譯自 English
[Moderator]
(2.1k 點) 提出

我以為這個問題開發人員已經知道了,但我現在已經發送了一個錯誤報告。

機器翻譯自 English

相關問題

0
6 個回答 998 次瀏覽
我們有一個小型術語表(目前只有 1 頁),我們正在使用對照表工具(interlineariser)來提供回譯(back translations) 為了在最近的顧問檢查中進行列印輸出,並方便導航,我瀏覽了整個術語表並添加了節號,使用 \vp 來在出版時將 ... 工具完全停擺 有沒有什麼方法可以將術語表分段,讓對照表工具能夠接受?這方面的最佳實務是什麼?
anon542642 294 提出 已提問 2月 21, 2022
0
6 個回答 868 次瀏覽
既然插入的任何插圖都會透過 Send/Receive 傳送,那麼在進行過程中處理插圖的最佳實務是什麼?特別是在頻寬較低的環境中,我們不希望增加 Send/Receive 的負擔。 目前,例如某個團隊只是插入註記,以表示希望在該位置添加特定的插圖。有沒有更好的方法?
drwww 448 提出 已提問 10月 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.4k 提出 已提問 12月 6, 2017
0
1 個回答 104 次瀏覽
我嘗試在「聖經譯法工具」(Biblical Renderings Tool)中搜尋具有詞條的聖經術語,但在我正在處理的所有專案中,只顯示出一個。我猜這表示曾執行過「將所有譯法與詞條取消連結...」(Unlink all renderings from glossary...)。有沒有辦法找到已定義詞條的譯法(例如顯示一欄)?
KR 151 提出 已提問 3月 12
0
1 個回答 20 次瀏覽
I have read through "Glossary Best Practices" (https://support.bible/3952/glossary-best-practices?show=3952#q3952). The information ... 'off', I'd sure appreciate it! Thanks, Paul
Paul 642 提出 已提問 10月 21, 2025
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
How good and pleasant it is when God’s people live together in unity!
Psalm 133:1
3,045 個問題
6,005 個回答
5,671 則評論
2,026 位使用者