0
842 次瀏覽

我對 USFM 為何定義獨立的腳註和交叉引用容器感到有些困惑。這是否僅僅是為了讓它們可以分別追蹤,並在列印時放置在不同的位置?

在我目前參與的專案中,腳註和交叉引用都放在同一個位置(頁面底部),但使用不同的標記。我想知道使用以下標記是否有根本性的錯誤:
\f ‡ \xt MAT 1:1\f*
而不是
\x + \xt MAT 1:1\x*

正如我上面所說,我能想到的使用 \x...\x* 標記的唯一原因是,如果交叉引用最終出現在不同的位置,例如側邊欄而非頁面底部。還有其他我沒想到的原因嗎?

由於這在技術上是關於 USFM 的問題,而不是 Paratext 的問題,是否有更合適的論壇來提出這類問題?

機器翻譯自 English
Paratext (1.9k 點) 提出 | 842 次瀏覽

1 個回答

0
最佳回答

在「早期」,我們曾將這兩種類型的文字都標記為腳註,但隨著新技術的出現,決定將這兩種類型分開。正如你所提到的,有時它們會被放在不同的位置。
預設情況下,交叉引用會作為參考進行驗證——這是將它們分開的一個原因。另一個原因是,在許多專案中,可能有數千個交叉引用,而相對較少的「真正」腳註。如果我想要檢查腳註,我需要將它們與交叉引用區分開來。
對於列印排版來說,將 \x…\x* 更改為 \f…\f* 以讓這兩種類型以相同方式列印出來相當容易。然而,如果這樣做是用於聖經應用程式,交叉引用的連結功能就會喪失,因此最好將其標記為 \x…\x*

在列印時將交叉引用更改為腳註總是比較容易。將實際上是交叉引用的腳註改回 \x…\x* 則非常困難。

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

我以為是 \xt 標記觸發參考驗證,而不是 \x 標記。請注意,在我的腳註範例中我使用了 \xt
\f ‡ \xt MAT 1:1\f*

所以,我疑惑的不是交叉引用的文字——我們當然希望在應用程式中實現熱連結——而是我疑惑的是容器標記。

我考慮回頭將所有交叉引用改為腳註的原因是,有時我們有「純粹」的交叉引用,但其他時候我們有包含交叉引用的腳註。因此,目前我們會有類似
\x + \xt MAT 1:1\x*

\f + \ft blah blah blah. See also \xt MAT 1:1\f*
但這讓我們的團隊——坦白說有時也包括我——感到困惑,為什麼我們在有些地方使用 \x,而在其他地方使用 \f

機器翻譯自 English

在 Paratext 中,就連結目的而言,這是正確的。但 @anon848905 的意思是,其他技術,如聖經應用程式建置工具(或使用完成文本的其他應用程式),可能會查看 \f 與 \x 並對它們進行不同的處理,因為 USFM 對它們的定義不同。

機器翻譯自 English

那麼,SAB 或其他程式在理論上是否不會對以下內容中的參考進行熱連結?
\f + \ft blah blah blah. See also \xt MAT 1:1\f*

機器翻譯自 English

你建議在 \f + …\f* 內部放置 \xt …\xt* 沒有問題。

我們對許多出版物都這樣做,儘管我們更喜歡這種格式:

\f + \fr 1:1 \ft See also: \xt … \xt*.\f*

當然,「See also」部分應使用目標語言。

正如你所說,讓譯員理解並處理單一系統更容易,對讀者來說也更容易。

機器翻譯自 English

\xt … 用於對參考進行熱連結。你的範例是腳註中 \xt 的適當用法。

機器翻譯自 English

Shegnada,我很好奇你為什麼使用 \xt* 標記來關閉參考,因為最終標點符號很容易設定為被 PT 忽略。這是因為其他程式無法處理嗎?我們是否應該嘗試通過所有 PT 參考測試,而不向聖經參考設定中的「額外材料」或「標點符號」區域添加額外資訊?

機器翻譯自 English

是的,這是一個很好的觀點。你可以設定 PT 忽略最終標點符號,然後省略 \xt*。我們的標準是在這不可能或無法正常運作時設定的。但是,在修復那些未在腳註或詞彙表中包含 \xt … \xt* 參考,或偶爾遺漏的專案時,團隊可以通過選取參考並輸入 “\xt ” 來輕鬆修復。Paratext 會自動在末尾包含 \xt*。我們希望盡可能標準化,以便日後可以輕鬆使用正則表達式處理。

機器翻譯自 English

關於將最終標點符號放在 \xt* 之前或之後,是否有最佳實踐?我們的慣例是放在之前。這會導致熱連結問題嗎?

機器翻譯自 English

我不確定最佳實踐是什麼……我很希望有人能寫一本關於 USFM 標記最佳用法的教科書。

但我可以證明,如果你正確定義了聖經參考格式(包含最終標點符號),最終標點符號在內部或外部都沒有關係。我認為,當你甚至不使用關閉標記時,將標點符號留在「內部」是最合適的,例如:
\f + \fr 1:1 \ft See also: \xt ... .\f*
如果你確實打算使用 \xt* 標記(再次強調,是否使用仍有爭議),我個人建議將標點符號放在外部,因為這使實際參考更容易解析。

機器翻譯自 English
我即將在即將到來的譯員工作坊上就這個主題(交叉引用和腳註)進行演講,即使讀完這個討論串,我對「混合」註釋在印刷出版物和電子應用程式中如何運作才更優,仍有些不太確定。
我可以看出上述

\f + \fr 1:1 \ft See also: \xt ... .\f*

可以運作,但鑑於它本質上是一個交叉引用,

\x + \xt 1:1 \xta See also: \xt ... .\x*

不是更好嗎?事實上,如果「See also」在專案的聖經參考設定中定義為補充材料,你甚至不需要 \xta。

但當涉及到更複雜的混合體時,我的困惑更大,例如馬太福音 2:1 中關於「伯利恆」的註釋/交叉引用。哪種方式更好(以確保它正確進入印刷版和電子版)?

\f + \fr 2.1 \ft According to \+xt 1 Sam 16.1\+xt* \fq Bethlehem \ft is David's home town.\f*



\x - \xo 2.1 \xq Bethlehem \xta : according to \xt 1 Sam 16.1\xta Bethlehem is David's home town.\x*
機器翻譯自 English

相關問題

0
1 個回答 183 次瀏覽
I'm having a problem with footnote and cross-reference callers Here's a sample: \f + \fr 2:4 \fk Keyword \ft ... cause the callers to show. I'd appreciate your help with this.
Paul 642 提出 已提問 2月 12, 2016
0
1 個回答 32 次瀏覽
我們在很多地方於交叉引用的關鍵字/引文或腳註文字中使用了 \+nd Here\+nd* 標記檢查(在 Run basic checks 中執行)會將這些標記為「標記不能出現在這裡」 範例: \v 4 \f + \fr 6:4 \ft ... it* 我已拒絕這些錯誤,但 DBL 上傳檢查仍然失敗 在交叉引用和腳註中,正確處理這些樣式的方式是什麼?
gregbac 141 提出 已提問 1月 19
0
1 個回答 244 次瀏覽
在開頭標記後輸入的字符指示了文本中將使用哪種呼叫符號 在「未格式化」視圖中,您可以在初始開頭標記後輸入您選擇的字符(前面加一個空格) 兩個範例: \x - \xo 1:3 \xt 或 \x # \xo 1:3 \xt 在「格式 ... 在您的交叉引用腳註中使用 + 字符 當您在「標準」 「格式化」或「預覽」視圖中查看文本時,將顯示您定義的字符
[Expert]
anon421222
735 提出
已提問 2月 23, 2017
0
1 個回答 57 次瀏覽
由於 USFM 文件中的細節不足,且我無法在此找到答案, 請您說明以下情況的正確語法: - Our Esther Greek uses many publisher verses (\vp) e.g ... -6257-43be-a2b8-dbf3a2359a4a%2D%2D%3E-->|ESG 10:13\xta \+it k\+it*\x*
gregbac 141 提出 已提問 1月 9
0
2 個回答 316 次瀏覽
支援聖經團隊您好, 我在進行一個專案時,發現同一節經文內有多個交叉引用 這些交叉引用可以合併為一個交叉引用嗎?以下提供相同文本供您參考 如果有 ... 4:11\x*మనలనను ప్రేమింపచుచు తన రక్తమువలన మన పాపములనుండి మనలను విడిపించినవానికి. 謝謝,此致 敬上, Thiyagarajan
Thiyagarajan 112 提出 已提問 7月 25, 2023
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
Very truly I tell you, whoever accepts anyone I send accepts me; and whoever accepts me accepts the one who sent me.
John 13:20
3,046 個問題
6,006 個回答
5,671 則評論
2,026 位使用者