我将尝试解释为什么这并不像人们预期的那么简单。
在 Paratext 内部，这将是一项相当多的工作——需要更新代码中的许多地方以符合新行为。大部分更改将是直接的，但需要触及代码的许多不同部分（检查、笔记、导航、视图布局、保存等）。阻止我们这样做的唯一因素可能是时间和优先级（即，当这意味着推迟其他工作时，这样做值得花费时间吗？）。
但最大的问题是所有非 Paratext 但依赖于此行为的内容。我们的用户可能没有意识到，但低级别的 Paratext 代码是共享的，被其他应用程序（主要由 SIL 开发，例如 PTLite、FLEx、HearThis、Glyssen 等）使用，以允许它们读取和处理 Paratext 项目数据。
我们可能可以避免更改低级代码，从而不影响其他应用程序，但这可能会导致 Paratext 代码中更多的临时修补，而不是一个好的长期解决方案。除了临时修补方法外，其中一些（或所有）应用程序也必须更新以处理新的数据处理方法。
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
