Next.js 项目的话，一般是用 json 文件管理多语言的。像 zh.json, en.json, ru.json 等等，有多少种语言就会有多少个 json 文件。
之前一般是用 gpt 翻译这些 json 的，文件不多还好，一多就会受限于 gpt 的长度限制了。如果我发 zh.json 让他连续翻译成 en.json, ru.json...到后面它就忘记原来的 zh.json 文件的内容，开始胡编乱造了。如果每次都带 zh.json 原文去翻译，用不了几轮对话就受限了，也挺麻烦。
时不时还有新增几个页面需要新增 zh.json 的内容，然后又要重新翻译，太痛苦了，所以就想做个 json.cn 那样的工具，直接复制 json 进去，然后直接翻译，带了 json 格式化，看着也舒服。
另外底层实现原理不是拿着整个 json 让 gpt 翻译，而是分段再翻译，所以也不用怕一个 json 就超长的问题。
感兴趣的朋友可以试试json 翻译器
Markdown 同样也有这样的困扰，而且 Markdown 文本超长的情况更严重，无论是 gpt 还是机翻。机翻更离谱，无法识别 Markdown 格式，一些符号在翻译小语种的时候会翻车。
我做的这个Markdown 翻译器考虑了一下长度问题，虽然底下有长度的提示，但那只是建议长度，你超长了还是可以翻译的，那个建议长度是我自己实际使用下来的 markdown 长度均值，一般来说够大家用。也有在 markdown 语法上做识别，常用的符号翻译结果一般不会翻车，如果翻车了欢迎反馈，我做改进哈哈。
底层用的 gpt 也给了本土化的要求，尽可能做到比机器翻译更优秀的本土化翻译结果。
最后的最后，考虑到这个工具的使用者可能会面临的一些问题，我也会在里面写一些博客，比如说Next.js 项目 App 目录如何简单实现 i18n 国际化，后面可能会出一些关于 Next 项目 App 目录结构怎么搭多语言博客，当时这块查阅资料的时候发现比较成熟的目前还只支持 Pages 结构的，这块的实现上当时花了不少时间。
希望自己遇到的一些坑总结出来的工具和经验对大家有帮助吧，感谢～
