[Feature]: 统一所有翻译器的源语言代码和目标语言代码

[Touch-Night]

Expect to happened

在很多不同的翻译器中，相同的语言可能使用了不同的语言代码，例如对于苗语，阿里巴巴和百度翻译的语言代码是hmn，而必应的语言代码则是mww。这个问题在中文上更加严重，但是我注意到你使用了zh_pool和auto_pool来规避这个问题。但这终究不能解决所有的存在此类问题的语言。 为了能够在编写程序的时候不需要考虑翻译器切换带来的影响，统一语言代码是必要的。我查看了 #139 ，并且使用get_language_map制作了此模块支持的大部分翻译器的完整语言支持表，包含了各个翻译器支持的语言与其对应的语言代码，希望能对这项改进起到帮助。 supported_language_map.csv 另外，此模块中已经实现了获取某个翻译器支持的语言列表（包括to_language和from_language）的功能，并将对应结果以字典返回的功能，能否把这些相关功能的使用方法写在Readme里呢？ #27 和 #62 中提到的方法已经过时，且不再有用。但这就应该放在另一个Feature Request里了，这里仅仅提一嘴。

Expected APP Version

next newest version

Expected Python Version

=3.8 (Default)

Expected Runtime Environment

Windows 10

Country/Region

Qatar(example)

Expected Output

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[UlionTse]

@Touch-Night 我已经感受到了浓浓的论文论述气息，哈哈哈，respect。 一共三段，那我一段一段回复你哈。 第一段，“终究不能解决所有的存在此类问题”，说的对，偷懒只解决了主要矛盾，嘿嘿。但不好维护也是现实情况。 第二段，从 #139 获得 get_language_map 这个方法，辛苦了。其实后来增加了ts.get_language()，可以更方便获取语言列表。 第三段，同第二段的回答。那我们就讨论一下怎么改进吧。 1、更新readme，之前是以google为标准，相同则为Y，有但有差异Y(xxx)，无则`。你可以去PR它，并成为此仓库的贡献者。 2、你可以独立构建一个库，类似于[chinesecalendar](https://pypi.org/project/chinesecalendar/), 你的库将会成为我的依赖库。 3、直接优化PR此库，成为贡献者。方法：你可以将CSV转化为dict，并且要在代码内函数实现一键更新维护。且最后在翻译接口函数增加参数alias_lang_if_detect=True`。

总之，感谢。期待你的回复。当然对于我的建议，你也可以对我说，“让我干？村口的驴子都不敢这么闲着！”

[Touch-Night]

此模块是我为text-generation-webui所写的插件more_translators所使用的。因此，我没有在supported_language_map.csv中包含所有的翻译器，而是仅仅包含了在我的设备和网络条件上可用的翻译器。此外，为了偷懒，我没有核对MyMemory的支持语言列表。

核对语言代码是费时费力的工作，它不能使用程序自动化完成。有不少翻译器没有使用ISO639，或是使用了ISO639的不同版本。不过好在大部分翻译器都在它们的翻译页面的html中包含了语言代码，我因此得以使用浏览器的审查元素功能核对。对于没有包含语言代码的翻译器，有时可以在其官方api文档里找到语言代码与语言名称的映射。以上都没有时，我只能查阅ISO639或是借助GPT。值得一提的是，必应为了保护濒危语言，支持了几个没有正式中文名的语言，对于这些语言，我在表格中自行翻译了它们的名称。

总之，supported_language_map.csv当前并不完整，这个表格最初是为了我的插件所制作的。放在这里仅能起到抛砖引玉的作用。因此目前直接把这个表格的内容放到此模块中应用，是不应该的。

关于Readme的更新，我相信除了获得支持语言代码字典的方法，还可能有其他的功能没有被添加到Readme中，我没有完整地阅读过源代码，因此也无法在Readme中写出所有新用法。