你看能不能把这个LocalizedMenu合并到你这个项目中？
zam1024t opened this issue · comments
https://github.com/zam1024t/LocalizedMenu
与您当前的功能相比，我增加了以下功能：
1, 支持添加任意种语言，可以不需要提交上来就直接工作，也就是说支持本地添加。
2, 支持任意版本的Sublime Text同时使用。
3, 可以自动修正中文翻译中热键大写小问题。
4, 可以支持多版本中的公共菜单共用。
5, 首次运行会自动备份本地菜单。
请看一下我的代码，您看方不方便合并，或者就让@wbond直接合并到插件库中。
wbond/package_control_channel#5665
我的貌似也是支持全部版本的，而且据我所知，目前3118之后的版本，设置子菜单有一个巨大的变化的，你那个的貌似还没支持。热键大小写暂时没有管它，因为一些插件很杂乱。
我这个也是可以本地修改的，只是我目前的设置是如果我强制升级版本号，会覆盖掉。大体上 差异的功能就是 不要覆盖本地翻译数据吗？这个功能貌似很容易实现。
我考虑的是仅仅一个Sublime Text自带的菜单的话，本地自定义没啥意义的。 我这个插件的名字是开始就这么起的 所以就一直用这个了 后来也懒得换了。这种插件py代码本身没啥价值，重点在于翻译上。
我有几点不大懂的地方 2 4 这两个啥意思？
你的这个是现场翻译做菜单啊！ 我懂了
之前考虑过用正则表达式来玩，不过太坑爹就没采用。不过现场翻译无法应对Sublime Text官方出现巨大变化的情况。
我和你在设计思路上有本质的区别，我希望它成为一个好用的多语言化工具，终端用户可以很自由地用，而你关注地在翻译质量上。
还有一点你可能没考虑到就是菜单共用的问题，还有向下兼容的问题，我已经实现了。
共用问题：
其它除了Main.sublime-menu其它基本在各人版本中都没有明显变化，所以可以共用。
向下兼容问题：
比如我安装了3119,那么这时我还可以用3114的汉化菜单。
对于Sublime来说既然选择了升级为何要用老版本的兼容呢？何不安装老版本？这个要兼容的话，我一要加一行代码就可以了，只是我当时否决了。
翻译而言根本不需要工具，而且你这个对于正真的翻译工作，貌似没啥实质性的帮助
嗯 我刚刚发布了一个新版本，现在可以自定义一个语言。
可能我上面回复得太唐突了，我下面逐一回复：
我的貌似也是支持全部版本的，而且据我所知，目前3118之后的版本，设置子菜单有一个巨大的变化的，你那个的貌似还没支持。热键大小写暂时没有管它，因为一些插件很杂乱。
我没有太关注开发版，刚才对比了一下3114，发现3118也只是Main.sublime-menu有改动,我不知道你是怎么支持多sublime版本共用一个多语言插件的，至少到现在我还没看懂。
我这个也是可以本地修改的，只是我目前的设置是如果我强制升级版本号，会覆盖掉。大体上 差异的功能就是 不要覆盖本地翻译数据吗？这个功能貌似很容易实现。
我想说如果一个不懂python的人，他怎么可能去改你的代码。
我考虑的是仅仅一个Sublime Text自带的菜单的话，本地自定义没啥意义的。 我这个插件的名字是开始就这么起的 所以就一直用这个了 后来也懒得换了。
我觉得既然你还在维护这个插件，我觉得你有必要和义务去改个更合理的名字，也方便使用包含的其它语言的用户去找到它。
这种插件py代码本身没啥价值，重点在于翻译上。
我写这个插件的时候是经过深思熟虑的，这是我的第一个python程序，我觉得它很有意义和价值。倒是对翻译我不是太在行，只是觉得符合自己的习惯就行。
我有几点不大懂的地方 2 4 这两个啥意思？
你的这个是现场翻译做菜单啊！ 我懂了
你可能只懂了第2点, 我还是解释一下，2就是可以在本地翻译本地用，不用再提交到github发布后才能用，4就是可以共同使用重复的菜单，我不知道你看出来没有，比如：现在的3114和3118版本，除了Main.sublime-menu其它的菜单是可以共用了，不用重复出现两份。
之前考虑过用正则表达式来玩，不过太坑爹就没采用。不过现场翻译无法应对Sublime Text官方出现巨大变化的情况。
主要是为了处理sublime内置的menu中有注释的问题，比如：用户可以直接从3119中解压出来_.sublime-menu命名为_.sublime-menu.json就可以放到英文目录中翻译成别的语言了。
对于Sublime来说既然选择了升级为何要用老版本的兼容呢？何不安装老版本？这个要兼容的话，我一要加一行代码就可以了，只是我当时否决了。
还是上面我之前那个例子，比如，我是一个网站编辑，我只写html代码,我安装了一个3114，今天有兴致想用一下3119，但发现3119的汉化版压根没出来，那么没关系它在3119中还可以使用3114的汉化菜单。
翻译而言根本不需要工具，而且你这个对于正真的翻译工作，貌似没啥实质性的帮助
开发者是这么认为的，因为你不需要，你问一个网站编辑，你看他知道怎么汉化sublime吗？
嗯 我刚刚发布了一个新版本，现在可以自定义一个语言。
挺好的，但我们俩写的东西还是有很多不同。
3119出来的话我不需要该一行代码啊！ 我关注着SBT的每一次改动，目前兼容的有三个版本，你应该注意到了我有一个patch目录。
普通的不懂代码的用户有心情闲到翻译SBT吗？为啥一个网站编辑需要汉化Sublime。
3119出来的话我不需要该一行代码啊！ 我关注着SBT的每一次改动，目前兼容的有三个版本，你应该注意到了我有一个patch目录。
我还是不懂，等我深入看懂了你的代码再讨论吧。
普通的不懂代码的用户有心情闲到翻译SBT吗？为啥一个网站编辑需要汉化Sublime。
比如：德国人是很着尊重自己的文化的，一般德国人都懂英语，但他们的windows什么的都是德语的，翻译一个sublime菜单也是有合情合理的。
用SBT，一般不都是程序员吗？那些快捷键都背得下来，json翻译理解得了，为啥py代码改开头常量定义几行代码有啥难处。
你还是在站在开发者的角度在考虑问题！
可以让一个网站编辑去改一个ini/json配置文件，一般你很难让他们去改一个python源代码。
我想我们的插件还是保持相互独立吧，毕竟设计**和实现方式都有很大不同。
先不讨论备份机制，这个我也可以很容易实现。实际上要较真我可以把那个头文件提取出来做成json文件也是很容易的。
你的是在线做翻译，只是我觉得没啥必要。因为直接编辑Main.sublime-menu也是很容易的，而且速度要快。你那个遍历json比较不节能。
SBT推崇的就是直接编辑.sublime-*文件。
只是点重复造轮子的感觉呢 毕竟是同一件事情
重复的地方多少是有的, 不同的是实现思路和设计理念。
用你的话说，这是从程序员看的不同的理念。用户才不管这些，实现的功能一样就是一样的喽
我觉得合并比较好，要不你来个合作者？增加特性。
实际上我有一个比较大的想法，想做一个类似Packagecontrol的翻译东西，用户可以提交翻译。
你这项目名字明显埋没了你的志向呀！！！
实际上我有一个比较大的想法，想做一个类似Packagecontrol的翻译东西。
我已经知道了，你在考虑汉化其它插件的问题，对这个还没什么思路呀。
目前我的插件里面用的技术已经可以翻译任意插件了，然后我就在考虑怎么做公共API接口的问题。
啊，这就有点深奥了。