Intentaré dar una explicación de por qué esto no es tan simple como la gente espera.
Dentro de Paratext mismo, esto sería bastante trabajo: requeriría actualizar muchos lugares en el código para adaptarse al nuevo comportamiento. En su mayor parte, los cambios serían directos, pero requerirían tocar muchas partes diferentes del código (verificaciones, notas, navegación, diseño de la vista, guardado, etc.). Lo único que nos impide hacer esto es probablemente el tiempo y el nivel de prioridad (es decir, ¿vale la pena dedicar tiempo a ello si significa posponer otro trabajo?).
Pero el mayor problema es todo lo que no es Paratext y que depende de este comportamiento. Es posible que nuestros usuarios no se den cuenta, pero el código de bajo nivel de Paratext se comparte con otras aplicaciones (desarrolladas en su mayoría por SIL, p. ej., PTLite, FLEx, HearThis, Glyssen, etc.) para permitirles leer y procesar los datos del proyecto de Paratext.
Probablemente podríamos evitar cambiar el código de bajo nivel y no afectar a otras aplicaciones, pero esto probablemente resultaría en más un parche en el código de Paratext que en una buena solución a largo plazo. Aparte del enfoque de parche, algunas (o todas) de esas aplicaciones también tendrían que actualizarse para manejar el nuevo enfoque de procesamiento de datos.
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.
Traducción automática desde English