Andy AO
> 好像是因为你这本刚好把目录放在内容里面了： > > 哦哦，那就开开。
@theowenyoung 借个楼问问，本项目自己训练的GPT测试名额还有吗？
> epub后缀难道不是必须的嘛？ 是也不是。 你可以试着上传 epub 文件到 GitHub 评论区，然后你会发现不能上传，这就是现在它的后缀为 zip 的原因，我使用的时候是 epub。 对于上传而言 epub 后缀不仅不是必须的，而且是多余的。 对于翻译来说可能是必须。
> 这个文件似乎在 苹果的 ibooks 中也打不开。 猜文件的格式可能出现了一些问题，但是在windows上我的两个阅读器都可以打开，比如SumatraPDF和Calibre。 所以我在想是否应该增加一些容错空间？HTML 的设计好像就在这方面有很多的考虑。 目前的解决方案是用Calibre转mobi，然后再转epub，之后就可以了。
我也想要此功能，暂时可以用脚本语言，正则表达式替换后粘贴回去。
谢谢@Fxiao1 的热心，的确，8年已经过去了，我早已换用Obsidian，不再受此困扰。
This problem has not been solved in 2024...
对于行的合并来说，可以使用LLM对于这些行进行预处理。 对于没有以标点符号结尾的行，把前文和后文摘录出来问LLM是一个句子可能性有多大，超过阈值判定为一个句子。 如果是的话那么就合并，如果不是就不合并。 通用的模型加提示工程估计就可以起到比较好的效果。
@bookfere 准备实现这个功能。 还有就是，不仅是字数跟随引擎，其他的潜在合并翻译设置也跟随引擎。 之前提过一些自动解决对齐问题的方案， 1. https://github.com/bookfere/Ebook-Translator-Calibre-Plugin/issues/241 改成逐段翻译，GPT翻译后未对齐，如果用户认为自动化处理更重要，不想去手动编辑，那么就可以提前设置，自动转成逐段翻译，这样就避免了合并翻译的错误。 2. 调用其他引擎，比如OpenAI的GPT由于不是专门用于翻译的，因此不太会遵守格式，所以不对齐的情况是司空见惯的，可是DeepL基本上没有这种情况，如果GPT基本上没有这种情况次选择DeepL可以实现自动化 实现过程中的考虑会发到这里
@bookfere 我对之前的承诺表示歉意，说想要实现它，因为生活上有变故暂时没法搞了，感觉不说一声可能会让人困惑，怎么突然没下文了？哈哈。所以在这里说明下。