我將嘗試解釋為什麼這並不像人們想像的那麼簡單。
在 Paratext 內部，這將是相當多的工作——需要更新代碼中的許多地方以適應新行為。大部分更改將是直接的，但需要觸及代碼的許多不同部分（檢查、筆記、導航、視圖佈局、儲存等）。阻止我們這樣做的唯一原因可能是時間和優先級（即，當這意味著推遲其他工作時，花時間做這件事值得嗎？）。
但最大的問題是所有依賴此行為的 非 Paratext 部分。我們的用戶可能沒有意識到，但底層 Paratext 代碼 是共享的，被其他應用程式（主要由 SIL 開發，例如 PTLite、FLEx、HearThis、Glyssen 等）使用，以允許它們讀取和處理 Paratext 專案數據。
我們可能可以避免更改底層代碼，從而不影響其他應用程式，但這可能會導致 Paratext 代碼中出現更多的權宜之計（hack），而不是一個良好的長期解決方案。除非採用權宜之計的方法，否則這些應用程式中的一些（或全部）也必須更新以處理新的數據處理方法。
I’ll try give an explanation as to why this is not quite as simple as people expect.
Inside Paratext itself, this would be a fair bit of work - requiring many places in the code to be updated to the new behavior. For the most part, the changes would be straightforward, but would require touching many different parts of the code (checks, notes, navigation, view layout, saving, etc.). The only thing keeping us from doing this is probably the time and the priority level (i.e. is it worth the time to do it when it means pushing off other work?).
But the biggest problem is everything that is not Paratext that depends on this behavior. Our users may not realize it, but the low-level Paratext code is shared by other applications (Mostly developed by SIL. e.g. PTLite, FLEx, HearThis, Glyssen, etc.) to allow them to read and process Paratext project data.
We could probably avoid changing the low-level code and not affect other applications, but this would probably result in more of a hack in the Paratext code than a good long-term solution. Barring the hack approach, some (or all) of those applications would also have to be updated to handle the new data processing approach.
機器翻譯自 English
