浮動註釋難以處理

Question

我對其他人如何評價我視為 Paratext 處理註釋功能中缺陷的看法很感興趣。我已將我的意見作為錯誤報告和改進建議發送出去，但似乎無人理會。有人告訴我，該程式只是按照其設計來運作。這沒問題，但我的重點在於，這種設計對使用者來說並無助益。

當註釋附著在某個詞上，而該詞隨後被刪除或替換為另一個詞時，註釋就會失去錨點，並移動到同一個詞的另一個實例上；如果找不到這樣的詞，則會移動到節的開頭。我看不出這種行為有何合理性。有人認為這是個好方法嗎？

當我在有節號的聖經書卷中工作時，情況還不算太糟。但如果我在像 XXA 這樣的附加書卷中工作，那裡有六本基於聖經的 Easy Readers，卻沒有節號。我為每個故事分配了獨立的章，並為每個段落/部分添加了節號。這些節號僅是為了緩解浮動註釋的不穩定行為而添加的，之後必須移除。

如果註釋很多，我可能會在節號處看到一連串十幾條註釋，很難弄清楚它們來自哪裡。我通常必須從註釋內部保存的上下文中取一個詞，進行搜尋，找到正確的上下文，然後雙擊該結果。我將嘗試附上截圖來說明這一點。

現在，如果將程式改為將註釋附著在前一個詞上，而不是目前的兩個選項，這個問題就可以輕鬆解決。這樣，註釋就與其上下文綁定，處理起來也更容易。如果需要，我也可以輕鬆地將其重新附著到新的詞上，以防我不滿意那個新詞。

2020-10-291280×720 180 KB

機器翻譯自 English 顯示原文

Answer 1

我猜測 Paratext 未按照您的建議設計的原因，是因為 Paratext 可能需要回溯很遠才能找到前一個上下文來附著註釋，這本身可能會造成很大的混淆。我同意，大多數情況下，將註釋放在其原始位置附近是理想的，但如果節的內容發生重大變化，那麼將其放在節的開頭可能更有助於人們知道它是未附著的。[附加書卷除外，見下文]

相關問題 1：我認為他們希望避免的一件事是註釋檔案中包含巨大的上下文，因為這會使檔案膨脹，並可能導致 Send/Receive 出現問題。在我們的地區，有些專案在附加書卷（沒有節號）中有數百條註釋，我相信註釋檔案包含了該節的完整文本，因此每個註釋檔案都包含了整章的完整文本，導致專案體積巨大（如果我錯了請指正）。

相關問題 2：您在附加書卷中的經歷與我類似。為了避免您提到的奇怪註釋問題，我們必須添加章和節號，這些通常是任意指定的。但如果這樣做，Interlinearizer 在回譯時無法正常運作。只有第一節會顯示，且無法核准其他節。目前附加書卷的實現對於註釋或您會使用 Interlinearizer 執行的任何任務來說都並不理想。

機器翻譯自 English 顯示原文

Comments

感謝您提供這些資訊。
關於第一段，我不認為這是一個問題。我們很少完全更改整節或整行，即使我們這樣做了，前往最近未變動的詞也可能不會跨越節的邊界。如果確實跨越了，那麼註釋可以放在該節號處。
我沒有考慮到您的問題 1，但我可以看出這可能是一個挑戰。
就目前而言，我同意唯一的變通方法是添加章和節。我目前正在處理的 Easy Readers 使用 \q 標記，如果註釋可以附著在其中一個標記上，問題就解決了。或者，可以實現並插入一個像 \note 這樣的特殊標記。它甚至可以自動在給定數量的詞之後插入。對我來說，之後刪除所有名為 \note（或類似名稱）的標記，比刪除由字母（c 或 v）和數字組成的標記要容易得多。（我不熟悉 RegEdit。）

機器翻譯自 English 顯示原文

Answer 2

我始終建議將註釋附著在短語上，而不是單個詞上。如果您這樣做，Paratext 在分析上下文並將註釋重新附著到適當的上下文方面做得非常好。但如果您將其附著在單個詞上，最大的危險在於，如果該詞被刪除，註釋可能會重新附著到節中不同位置的同一個詞上。但註釋很可能並不適用於該詞的該個實例。因此，我總是將註釋附著在短語上，並鼓勵我的團隊成員這樣做。

機器翻譯自 English 顯示原文

Comments

感謝您提供變通方法的建議。問題在於這違反直覺。如果註釋指的是子句，能夠選擇子句；如果指的是短語，能夠選擇短語；如果指的是詞，能夠選擇詞，這樣會很好。因此，我仍然希望程式能修復為：如果註釋原本附著在一個丟失的詞上，則將其附著在前一個詞上。

機器翻譯自 English 顯示原文