Sublime Text 3 插件的汉化、开发、发布方法教程（2013-12更新）

转载请注明作者和原帖地址。

作者：碧海情天-赵亮（theforever）

前言：这个教程原本是分为三个部分的系列教程，现在合三为一，内容较多，请耐心阅读或根据文章目录挑选感兴趣的部分跳跃阅读。之所以合并和重新编辑，就是为了方便大家一次性观看和保存，在重新编辑过程中，修正了一些格式上的小问题。

Sublime Text（以下简称ST）是一个近年推出的编辑文本和程序代码的优秀工具。只要一打开，你就会意识到它和以往的编辑工具的不同，感觉到它在界面安排上的先进性，更美观也更贴心。如果再通过它的中英文介绍材料简单了解一下它的特性，你就会发现，这是一个在以往的文字和代码编辑器基础上，收集了众多用户最迫切需要的一些实际需求并加以实现的让你惊喜的编辑器。功能贴心，界面时尚，这就是它首先能抓住你的特色，接下来你还会发现它有很多非常有用的插件，包括针对各种编程语言的语法补充和提示、zencode、格式化，以及通用的一些功能插件，而所有这些插件都是开放代码的，可查阅学习，也可根据需要进行修改。而且虽然功能强大，ST本身的安装文件体积还不到十M，在低端机上运行也很流畅。所以这绝对是值得你拥有的编辑工具。
关于使用方法和热键介绍，以及插件安装方法，都有不少专门的文章介绍，可以搜索阅读。

本教程主要讲解：ST3插件的汉化、开发、发布方法。
适用人群：需要实现彻底汉化的普通用户；想要了解插件开发和发布方法脉络的高级用户和编程爱好者。

一、汉化

在汉化方面，几乎其它全部文章都只介绍使用现成的汉化包。这固然方便，但解决不了所有问题。先不提版本更新和汉化包更新的时间差，单说你所安装的一些插件，由于它们常常要额外添加英文菜单项，所以就会导致汉化不完全的现象，不仅是它们添加的菜单自身，还包括ST的顶级菜单都常常会重新覆盖显示为英文。因为汉化包只包括基本的ST功能菜单，它既不知道你还会安装哪些插件，更不可能预先把那些插件产生的菜单项目汉化进去，因为那会生成大量没有实际实现的无用菜单，何况未知的插件还会不断涌现，对于它们可能产生的菜单项目其实是根本无法猜测的。

所以了解插件包的机制，学会手工对插件甚至ST汉化，会让你掌握主动，不需等待靠人，就能解决问题。

1.1 ST主体的汉化

首先从汉化ST主体说起：

1、在ST的安装文件夹下有个 Packages 文件夹，进入这个文件夹，你可以看到里面文件都是以 sublime-package 为扩展名的，这表示的就是ST插件包。其中很多文件以编程语言名称作为文件名，这些是语法文件，是语法高亮和自动补全的参考。但这个文件夹并非只有这些，还包括默认的主题方案(theme)以及更重要的 Default.sublime-package文件，我们要汉化的菜单文件就包含在里面。

2、接下来你自然需要知道怎么把菜单文件弄出来进行翻译然后让它生效了。sublime-package这个扩展名并非一种专门的物理文件格式，而是一种逻辑上的文件分类表示，它的实际文件格式其实是ZIP（如果你的软件经验够多，会在不少软件中看到类似的用法），所以只要你把这个扩展名改成ZIP，就可以用任何支持ZIP的解压软件解压成一个文件夹，内含扩展包中所有文件。

3、在这些文件中找到扩展名为sublime-menu的几个文件，用文本编辑器打开，可以看到所有菜单项都在里面。其中 "caption": "XXXX" 就代表菜单显示的名称。除了 { "caption": "-" } （表示菜单分组间隔线）不要动之外，其余的caption后面的英文用汉语替换即可。

注意：带有"mnemonic": "某字母"的，表示该菜单的键盘访问键，所以在翻译成汉语时，应该把这个字母用括号括起来，加在汉语的前面或后面。

4、保存，并且要注意，必须选择编码为UTF8（可以选择不加UTF头BOM），而不能是GBK或GB2312。因为ST想用UTF8统一全球各种字符集，抛弃了对GBK等字符集的自动识别，所以如果存成GBK，ST就不能正确识别汉字部分，会无法显示或显示不正常。

5、应用。要想生效，需要把解压文件夹再压缩回ZIP（注意，要在文件夹里选择所有文件压缩，而不是在文件夹外选择文件夹压缩，那样就会因为目录层级不对而无法生效），然后改回原来的扩展名，并移到原文件夹中。

建议采用下面的另外一种局部修改方法，更简便且安全：

同上。
在压缩包中只选择扩展名为sublime-menu的几个文件解压出来，放在一个名为Default的文件夹中。
编辑文件并保存，注意事项同上。
剪切 Default文件夹。
在ST中选择“Preferences/偏好”主菜单（右数第二个）->“Browse Packages/浏览扩展包”，系统会打开一个文件夹，按CTRL+V把之前剪切的 Default文件夹粘贴在这里。

这种方法不需要重新打包并改名，而且可以随时更改，最主要的是会保留原始的 Default.sublime-package文件，以防万一改坏不能复原导致只能重新安装软件。同时这种方法还会在保存文件时立即反映出改变。在下面讲解“插件开发”时，可以利用这个方法调试插件。

以上是ST主体的汉化。通过对扩展包 Default.sublime-package文件里的 sublime-menu 文件进行修改。

（2013-12 更新说明：上面讲的是对ST主体的菜单项目进行汉化。但是其中有些开关类型的菜单，由于菜单文件里没有提供设置的办法——按普通设置的话，不会有开关状态时不同的显示内容，而是固定的内容。这时候就需要修改ST的EXE文件里面的内容了，而且有些显示细节，比如“查找替换面板”和状态栏里的行列提示等信息，也要通过这个途径才能汉化。

    这里有两个汉化完成的软件包及其说明，大家可以拿去试用。不仅包括菜单、状态栏、命令面板、侧边栏的汉化，里面还集成了最常用的插件，如GBK自动转换、EMMET和多重插入、格式化等编辑增强插件及我自制的几个常用功能，常用配置设置，并对菜单在汉化基础上又进行了重组。可以说不只是体验和学习汉化方法，也可以对你的学习和工作生活提供较大便利。
    第一版（3056，主菜单为多个字）的说明（附图）： http://my.oschina.net/theforever/blog/185251
    第二版（3059，主菜单为单字）的说明（附图）： http://my.oschina.net/theforever/blog/186730
    第三版（3061）的说明（附图）：http://my.oschina.net/theforever/blog/188155
    每个版本都在前一个基础上有一些额外的增强，所以最好从头到尾把三个版本的文章说明都看一下。其中第二版并没上传软件包，可以到第三版中下载。

）

1.2 对其它插件进行汉化的方法

首先要找到插件的文件，ST3插件有三个存放位置：一个是ST安装文件夹下面的 Packages 文件夹；一个是在上面第5步找到的 Packages 文件夹；还有一个是和第二个 Packages文件夹同级的Installed Packages文件夹（“Browse Packages/浏览扩展包”之后向上一级就可以看到）。

在这三个目录中，第一和第三个目录是放插件包的，不会识别目录形式的插件，第二个目录则只识别目录形式的插件而不识别插件包，适合用来进行插件开发和修改测试，也可作为用户对他人的插件进行自定义修改后的留存（当你在其它机器上重新安装ST和插件后，可以通过恢复对这个目录的备份来应用你之前的修改和扩展）。

插件名称和 sublime-package文件的文件名是对应的，因此很好找到对应的扩展包。找到之后，使用上面汉化ST主体时的两种方法之一进行修改即可。

（在上一节末尾给出的第三版（3061汉化增强版）：http://my.oschina.net/theforever/blog/188155 中，给附带的几个最常用的插件都进行了汉化，可以下载查看学习。）

汉化的方法至此结束。

二、开发插件

2.1 插件介绍

通过上节讲的方法，可以查看所有标准的和扩展的插件内容，为我们继续深入到进行自己的插件开发打开道路。

下面结合我自己写的一个ST插件来讲解一下开发方法。这个插件功能比较简单，实际功能代码部分很少，但已经能够带引你掌握整个插件开发的主要脉络，适合入门。其作用是把当前剪贴板中的所有空行（包括只含有空格和TAB制表符而没有其它有效内容的行）删除，并粘贴到ST当前编辑的文档。这在用浏览器查看网页并想收集文字内容时，比较有用，因为即使在网页中是连续的行，复制粘贴后也会发现中间可能有无用的空行，更不用说有的内容明显有多个不必要的空行了。当一个文件含有多个不同页面的不同内容时，这些多余的空行会使内容显得散乱而不易区分。

虽然用ST的正则替换可以消除空行，但输入还是稍微麻烦点，而且一般还都要选择“替换区域内文本”，否则就会把之前已经处理好的文本中需要保留的空行也一并删除了。

而用ST菜单中的“唯一化”功能，又会消除一些作为分隔线的相同内容行，和其它很多必要的重复行。“唯一化”在别的时候可能很有用，但在这种情况下显然不适合。

而ST2的delete blank line插件还得在粘贴之后选择刚才粘贴完的内容再手工按键操作，有时还要按几次，还是比较麻烦，尤其当粘贴的内容较多，不容易看出全部效果的时候，会让用户感觉比较困扰（借助ST的文档小地图可以了解到情况，但若你和我一样，在处理大文档时关闭小地图以提高性能，就无法借助这一点了）。

用我这个插件，只需要在浏览器或别的地方复制了内容之后，到ST中按一下插件绑定的热键CTRL+ALT+SHIFT+L（虽然看着键子多，但按起来还是挺方便的，也容易理解：SHIFT在功能键的含义中一般表示去除或者反向，L表示空行Lines），就会以去掉多余空行的形式粘贴到你的文档中。被减肥的内容还可以再粘贴到别处使用。比如你在论坛看到有个人提问的问题，你想要回复，并且把这个问题和你的回复都记录到一个文档中。在你回复时，你可能还想要引用他的问题，但是如果他的问题中有一些不必要的空行，就会在你的回答前面占据不必要的空间。这种情况下，你复制他的问题后，在ST里按插件的热键粘贴后，可以再回到浏览器的回复框中，用CTRL+V就能再次粘贴刚才已经减肥过的内容。

下面就开始从头编写它吧：

2.2 建立插件

虽然在ST的Tools(工具)菜单里有一项“new Plugin 新插件"菜单，但我觉得更快捷的方法是你可以选择与Installed Packages文件夹同级的Packages文件夹中一个现成的插件目录（最好里面的内容种类齐全，如果你有意常做，可以制作一个模板——甚至可以编写一个可视化操作软件来生成这些文件），复制粘贴，然后更改其名称，进入里面，选择不想要的文件删除，再对剩下的文件进行修改即可。

介绍一下插件文件夹里面一些主要文件的作用和写法：

2.2.1 菜单文件

Main.sublime-menu：插件的主菜单。里面的内容会添加到ST系统菜单中。
我插件的这部分内容是：

[{
"id": "edit","children":[
{"caption": "清除剪贴板中空行并粘贴","command": "paste_without_blank_lines"}
]
}]

    第一行是JSON的结构定界符，即使不了解，只要照葫芦画瓢保持结构形式就可以了。
    第二行，表示向菜单id为edit的菜单（即“edit/编辑”菜单）中添加项目。要搞清楚id和caption不同，id用于标识真正的身份，caption只作为在菜单中的显示内容。
    注意：这里的ID不仅限于顶级菜单的ID，而是任意有ID的菜单项，根据你的插件用途进行选择即可（但最好不要给带有id而caption是“-”的项目添加子菜单，虽然能加进去，但看着太怪了）
    第三行是所添加命令菜单的显示名称和对应的要执行的指令ID。指令ID是需要你自己起的，要避免与其它已有指令ID重复，最好起一个能表示你插件用途的名字。
    如果要添加多项命令菜单，各项之间要用逗号分开。注意：最后一项的后面就不要再加逗号了。

另外，如果某个家伙写他的插件时这样干了：

[{
"id": "edit",
"caption":"Edit(E)",
"children":[
{"caption": "abc","command": "abc"}
]
}]

就会使你汉化过的“编辑(E)”菜单还是显示英文“Edit(E)”，所以当你看到菜单发生这种现象，就要找到是哪个插件干的。不用急，就在这个菜单下面再看看还有哪一项是英文（即使不只一个也可以这样挨个查看一下），找到后，记住菜单的英文内容，再到我在上一节“一、汉化”中介绍过的三个放置插件的目录中找到有类似名称的插件，用“一、汉化”中介绍的编辑方法打开菜单文件进行编辑然后保存，就又会显示中文了。

2.2.2 键盘热键映射文件

好，结束了菜单文件，下面再给我们的插件增加一个在ST里可以快捷调用的键盘热键，这是通过下面的 Default (Windows).sublime-keymap 文件实现的，内容是：

[
{ "keys": ["ctrl+alt+shift+l"], "command": "paste_without_blank_lines" }
]

command必须对应于菜单文件中的命令ID。
另外还有Default (Linux).sublime-keymap 和 Default (OSX).sublime-keymap 两个文件。如果你的插件能够和想要支持它们，也可以加上。它们的主要区别是由于配置的键盘在功能键数量和命名上有些差异，所以在定义文件中要有针对地设置。

2.2.3 向命令面板中注册命令的文件

我们还可以利用 Default.sublime-commands 文件，在“Ctrl+Shift+P”的命令面板中增加插件所含的指令供调用。虽然会稍微增加点系统开销，但还是值得做的。中文名称在命令面板中同样可以搜索调用。

[
{"caption": "清除剪贴板空行并粘贴","command": "paste_without_blank_lines"}
]

2.2.4 插件主体程序

PasteWithoutBlankLines.py 是本插件命令的实现代码。ST的插件都是用PYTHON写的，PYTHON程序的扩展名是.PY。当一个插件只有一个PY文件时，该文件名和插件的名称可以不同，ST会自动调用这个唯一的PY程序。但当插件内有多个PY时，要么你把其余的PY放在子文件夹中进行调用，要么你就得用插件文件夹的名称作为主程序文件的名称，这样ST会在几个PY中挑选与插件文件夹相同名称的程序作为入口先执行。
在我写这个教程之前，甚至直到现在，其实都没好好看过PYTHON语法，不过PYTHON程序还是比较容易阅读理解的。在汉化过程中顺便看看，结合ST的代码补全提示功能，已经足够用来写个简单的插件了。电脑技术层出不穷，不可能都去涉猎，但通过一个要做的实事，稍微学点东西，也是不错的事情。

下面贴一下源码，关于插件主程序的写法机制和主要语法，我在源码里已经写上了详细的注释：

import sublime, sublime_plugin # 插件主程序必须要引用这两个基础类库。
import re # 本插件需要用到的正则表达式类库。
class PasteWithoutBlankLinesCommand(sublime_plugin.TextCommand):
"""
进行多行注释：每个菜单命令都对应于一个类。注意类名的写法，是把菜单命令的下划线去掉，改成驼峰式写法，并且在末尾加上Command。
括号中 sublime_plugin.TextCommand 是此类的父类，表示此类是一个命令菜单的实际行为类。
如果不是命令菜单引起的而是由于窗口命令引起的实际行为类，父类就要指定为 sublime_plugin.WindowCommand 。
"""
def run(self, edit): # def表示定义一个方法。ST插件机制会自动调用指令类的run方法，所以必须重载实现此方法以供执行。
s = sublime.get_clipboard() # 获取剪切板内容
"""
从ST文件视图配置中读取默认行结束符的类别（用操作系统环境表示）。因为不同的操作系统对硬回车的表示和存储方式不同，而这个插件正是需要对这些进行处理。如果你的插件也涉及操作系统的分别或者是配置的分别，都需要考虑按此方法先读取相应的配置，再根据配置进行不同的处理。
"""
line_ending = self.view.settings().get('default_line_ending')
# 根据不同的操作系统环境进行不同的替换处理。
if line_ending == 'windows':
s = re.compile('\n\r').sub('',s)
s = re.compile('\r\n\s*\r\n').sub('\r\n',s)
elif line_ending == 'mac':
s = re.compile('\r\r').sub('\r',s)
s = re.compile('\r\s*\r').sub('\r',s)
else: # unix / system
s = re.compile('\n\n').sub('\n',s)
s = re.compile('\n\s*\n').sub('\n',s)
sublime.set_clipboard(s) # 修改剪贴板内容，此方法可使减肥过的剪贴板内容在别处也能使用
self.view.run_command('paste') # 调用粘贴命令

其中 sublime.get_clipboard、self.view.settings、sublime.set_clipboard 等都是ST的APIs，要想获得更多资料说明以写出属于你的复杂的插件，可以到ST的官方网站去查看API参考文档，当然，更简单的方法是看看这篇我和另一译者共同翻译的“Sublime Text 插件 API 参考中文版 http://www.oschina.net/translate/sublime-text-plugin-api-reference”。

与Installed Packages文件夹同级的Packages文件夹，可以说是专为调试插件准备的，在其中无论是对菜单还是对命令实现的程序进行更改，都会即时反应到ST中。在写好之后，可以压缩成ZIP然后改扩展名为sublime-package。压缩时要注意：不要选择目录进行压缩，而要在目录中选择所有文件进行压缩。前者会把目录名压进去，增加一层目录深度，导致ST检索时找不到插件文件。

现在，你可以自己使用，也可以把插件打包发给朋友们使用，或放在能够下载的网址上。

到这里你已经可以自己开发和使用并小范围地散发你的插件了，如果你希望在P C面板的安装插件列表中看到你自己的插件，供全世界的朋友使用，可以继续观看本教程的最后一节：“三、ST插件发布”。

三、ST插件发布

首先要避免在你的插件中使用中文，因为ST对GBK的态度已经说明一切，你含有中文的插件是极不可能通过下面提到的审核的。

然后为了帮助你更好理解为什么要进行下面的行为，我介绍一下P C的工作原理。它是利用两个（根据发展，它可能支持更多）流行的源码项目服务器（github和bitbucket）的功能实现的。它在源码服务器上存放着一个插件列表文件，里面含有你在选择“安装插件”时会显示的插件列表。所以你只要提交你的插件地址给那个插件列表文件即可。P C会根据用户的选择自动找到你的插件地址。如果你的插件是已经打包好的插件文件（即URL是以插件包扩展名为结束的），它就会按URL直接下载并存放到插件目录中。如果你的插件是以源码目录的形式存储在源码存储服务器上（只写有源码仓库名称，不是具体的插件包文件），P C会根据存储服务器所提供的打包下载功能将你的插件文件打包下载并还原到用户电脑中的ST插件目录中。ST会自动对插件目录进行扫描和应用新插件。

为了能够向插件列表文件中加入你的插件地址，你需要按照该列表的要求来提供你的插件。

以GITHUB为例（BitBucket大致也相同），你需要先去 www.github.com 注册一个帐号。由于这是源码仓库服务器，所以审查机制非常宽松，即使是随便填的邮箱都可以注册成功。但在之后还是会提醒你至少验证一个邮箱的（你可以设置一个用来登录的私密邮箱，还可以设置一个公开的用于交流的邮箱）。当然，由于你的源码要面对众多的内行，所以也不要琢磨干什么偷偷摸摸的坏事了。

注册完成后，你可以在网站右上方你的帐号旁边找到“建立仓库”按钮，点击后给自己的仓库起个名，也就是你的插件的名称。在这一步要注意，因为这个服务器肯定不只限于你存放ST插件的源码，所以你肯定会想给你的仓库起个“Sublime xxxx“的名字来标识一下。这个时候建议你最好不要加，因为P C觉得这对于它来说完全多余，向它提交的肯定都只是ST插件，而带有这样名称的插件下载到用户电脑里，也会让用户对如此明显冗余的内容感到厌烦，因此P C要求插件名称里不要含有这样的字样。对于那些不幸已经这样起名的，P C推出了名称映射功能。这不仅对你增加一道设置映射的手续，而且使你的实际插件URL与用户们看到和使用的插件名称有所差异，所以最好在建立仓库时就不要添加，只起描述你插件作用的名字即可。而且应该使用驼峰式命名，避免使用下划线。在仓库的描述栏中填写好插件的说明，包括适用的版本号和用途，要简洁明确，然后勾选“生成readme.md”。确定。

比如我的插件源码地址是：https://github.com/Zhao-Liang/PasteWithoutBlankLines
（特意用了中文名——可惜ZhaoLiang被占用了——从P C列表中一看URL就知道是中国人写的）

现在你已经拥有了一个空的代码仓库，你可以使用GIT或GITHUB软件进行同步和版本更新，也可以直接在网页中使用“新建文件”和“编辑文件”功能来建立和修改文件。新手用后者比较容易上手，成手用前者能提高效率。

假设你已经通过这两种方式之一把你的插件内容存到了仓库中，现在在仓库根目录还要建立一个packages.json文件，向其中写入如下内容:

{
     "schema_version": "1.2",
     "packages": [
      {
       "name": "你的插件名称，如PasteWithoutBlankLines",
       "description": "你的插件的描述",
       "author": "作者名称，可以写你真名或是在 github 上的用户名",
       "homepage": "https://github.com/你的用户名/插件名",
       "last_modified": "最后修改的日期时间",
       "platforms": {
        "*": [
         {
          "version": "你的插件版本号",
          "url": "https://nodeload.github.com/你的用户名/插件名/zip/tag名"
         }
        ]
       }
      }
     ]
    }

    确保为上面每个键名设置了你的信息。若插件能工作于所有操作系统平台，则 platforms 键应写为 "*" 。若插件专为某一操作系统而写，应写明是 "osx", "windows" 或是 "linux"，也可以为三种或单独一种平台各自指定不同实现方式和版本的插件URL（尽管这很少使用，因为你在一个版本里就可以通过程序来判断不同的操作系统从而进行不同的操作行为。除非业务确实比较复杂。）。如果你长期只用一种操作系统，可能会觉得忽略另外两者很平常，但如果考虑到P C作者面对的是全球使用不同操作系统的用户，你就会知道他对这一点还是会相当注意的。
    url 键必须指定在 https://nodeload.github.com 上，否则不能对所有机器都正常下载。
    下载 URL 的最后部分是代码的分支名。虽然可以使用主分支，但由于下面将会介绍的“防止不必要的频繁更新”的原因，建议使用一个代码的特定版本。

当升级插件版本后，要记得更改主分支里面的 packages.json 文件中的 version 和 URL。

把P C作者自己的packages.json摘录在下面，看着会更清楚：

{
	"schema_version": "1.1",
	"packages": [
		{
			"name": "Alignment",
			"description": "Easy alignment of multiple selections and multi-line selections",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/alignment",
			"last_modified": "2011-09-18 23:13:00",
			"platforms": {
				"*": [
					{
						"version": "2.0.0",
						"url": "http://sublime.wbond.net/Alignment.sublime-package"
					}
				]
			}
		},
		{
			"name": "Package Control",
			"description": "A full-featured package manager",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/package_control",
			"last_modified": "2013-01-21 20:13:00",
			"platforms": {
				"*": [
					{
						"version": "1.6.3",
						"url": "http://sublime.wbond.net/Package Control.sublime-package"
					}
				]
			}
		},
		{
			"name": "Prefixr",
			"description": "Runs CSS through Prefixr.com API",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/prefixr",
			"last_modified": "2011-11-14 12:40:00",
			"platforms": {
				"*": [
					{
						"version": "1.0.1",
						"url": "http://sublime.wbond.net/Prefixr.sublime-package"
					}
				]
			}
		},
		{
			"name": "SFTP",
			"description": "Commercial SFTP/FTP plugin - upload, sync, browse, remote edit, diff and vcs integration",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/sftp",
			"last_modified": "2012-08-08 08:43:00",
			"platforms": {
				"linux": [
					{
						"version": "1.10.2",
						"url": "http://sublime.wbond.net/SFTP.sublime-package"
					}
				],
				"osx": [
					{
						"version": "1.10.2",
						"url": "http://sublime.wbond.net/SFTP.sublime-package"
					}
				],
				"windows": [
					{
						"version": "1.10.2",
						"url": "http://sublime.wbond.net/win/SFTP.sublime-package"
					}
				]
			}
		},
		{
			"name": "SVN",
			"description": "Full-featured commercial Subversion plugin with a focus on usability",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/svn",
			"last_modified": "2012-08-13 02:07:00",
			"platforms": {
				"linux": [
					{
						"version": "1.5.2",
						"url": "http://sublime.wbond.net/SVN.sublime-package"
					}
				],
				"osx": [
					{
						"version": "1.5.2",
						"url": "http://sublime.wbond.net/SVN.sublime-package"
					}
				],
				"windows": [
					{
						"version": "1.5.2",
						"url": "http://sublime.wbond.net/win/SVN.sublime-package"
					}
				]
			}
		},
		{
			"name": "Terminal",
			"description": "Launch terminals from the current file or the root project folder",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/terminal",
			"last_modified": "2011-11-28 22:49:00",
			"platforms": {
				"*": [
					{
						"version": "1.3.1",
						"url": "http://sublime.wbond.net/Terminal.sublime-package"
					}
				]
			}
		},
		{
			"name": "Tortoise",
			"description": "Keyboard shortcuts and menu entries to execute TortoiseSVN, TortoiseHg and TortoiseGit commands",
			"author": "Will Bond (wbond)",
			"homepage": "http://wbond.net/sublime_packages/tortoise",
			"last_modified": "2011-11-05 23:08:00",
			"platforms": {
				"windows": [
					{
						"version": "1.2.1",
						"url": "http://sublime.wbond.net/Tortoise.sublime-package"
					}
				]
			}
		}
	]
}

从中我们看到针对不同操作系统提供不同插件的例子，还可以看到能够直接指定使用打包好的扩展文件。在你的仓库中放置一个packages.json和一个打好包的插件，很简洁，只是你需要自己进行打包和更名的工作了（我用了一下ST3的自动打包功能，不知是BUG还是我的ST环境被弄得有点混乱了，亦或我没去看打包是否有点需要遵守的规矩，总之是没有成功）。

最后，打开 https://github.com/wbond/package_control_channel，在项目栏右方找到FORK按钮，点击，这就使你的帐号拥有了 package_control_channel 的一个仓库副本。找到你帐号里这个副本，进入，编辑repositories.json，按下面讲的第2点注意事项在合适位置插入一行，内容是：

"https://raw.github.com/你的帐号/你的插件仓库/master/packages.json",

编辑时要注意几点：
1、不要动别的原来内容，包括行结束符和缩进。只添加你自己的行。因为审查者会在版本服务器中对比你所做的改变，如果发现通篇每行都有变化，肯定没耐心看你究竟加了什么，以及是否对别人的内容造成破坏，结果自然会拒绝合并你的修改内容。（我好像就是习惯成自然地不小心改了缩进的设置……呵呵，毁了。话说回来，要不是这种习惯，也不会编写这样的插件了，我觉得很常用，可一直没看到别人有写，我至于这么小众吗——补注：不知什么时候，P C已经收录了我这个插件，名字就是PasteWithoutBlankLines，有需要的朋友可以在ST里安装使用了。我自己在提交时并没有象这个教程这样认真去做——因为教程是要对大家负责的——但也被收录了，说明审查还不是非常挑剔的，可能时间多半花在对你插件代码的实际审查上了，毕竟PYTHON能干的事情比JS和VBS还要多，危险性也更大，P C作为收录和推荐方，肯定要负有责任的。虽然后面这部分篇幅挺多，虽然建议你耐心读完并实际遵守，但也不需要为此过于纠结，大不了随便把插件包上传到某个网盘上，通过宣传也是可以的，只是在可信性和可见性上，肯定不如出现在P C插件列表中那样好）

2、添加时要象原内容那样按照字母大小顺序插入到合适位置，这样会使整个名单保持明了而不是混乱。

3、除非你需要做名称映射，否则不需要管后面的部分。

然后保存。成功后，在项目的正上方有个“PULL REQUEST”（请求推送），即把你刚才所做的改变提交给原始的 package_control_channel 项目，等待作者审批，所以剩下的就是等待了。审批成功之后，你所添加的插件URL就会在全球ST用户安装插件的时候显示出来供下载安装了，而且也会出现在http://wbond.net/sublime_packages/community 页面上，该页面按时序显示了所有提交给P C的插件的信息（即你在packages.json中填的一些信息），比在P C安装面板中缩略显示的要详细。

如果你没有建立和填写packages.json，P C会取你的代码仓库的最后更新日期时间作为版本号。这会造成性能上的浪费。因为P C每次启动都会检查所有插件的版本号，如果你改了一个文件，过会儿又改了另一个文件，这个过程中，全球用户可能会有不少已经安装你的插件的用户由于你的间隔更新而不断来进行插件升级。在你结束所有修改，正式决定升级插件版本之前，这肯定是不必要的浪费。所以前面提到过，建议你建立一个分支作为插件的下载URL，在你的主分支里只需要存放packages.json，在它里面用URL指出你插件的真正地址和版本。这样，只要这个文件内容不变，你的插件仓库无论怎么修改也不会引起频繁的更新。

四、结语

好了，至此关于ST汉化和插件开发及提交的教程就全部结束了。本教程基于ST3进行讲解，对ST2来说，少部分地方可能有所区别，尤其是在插件编程中涉及一些API变化的部分，需要提取ST的版本，然后采用相应的API方法，这个可以参考一些从ST2升级到ST3的插件。也可以查看“延伸阅读”中的“ST插件API参考中文版”来获得更详细的关于ST插件API的信息。