本地化的 Scratch 社区
Scratch 是 MIT 的一个开源项目，从功能上讲绝大部分的代码都是开源的（包括官方网站本身），所以任何人都可以从 GitHub 上下载到这些代码，然后再加上自己的修改迅速搭建起一个新的 Scratch 在线社区。开源的魅力似乎就在此，于是我们惊喜地发现越来越多的本地化 Scratch 在线社区不断产生，这其中既有商业性的公司，也有非赢利性的机构。
于是，很多新的 Scratch 用户开始从这类在线社区接触 Scratch 语言，制作和分享自己的作品。这很让人欣喜，但同时也让人有点疑惑——我们在强调本地化的同时，是不是忽略了 Scratch 自身的价值？
在我看来，Scratch 项目有两个重要的维度值得我们仔细思索：
- 语言
- 社区
先来看语言本身，Scratch 是用积木拼接的方式来导入程序设计的各种逻辑结构的，由于借鉴了乐高积木的一些属性，所以对于初学者来讲基本没有什么负担。计算机语言发展的特点就是在语法不断简化的同时，语言能够实现的功能反而会更强，所以即使今天没有 Scratch，相信也会有某种类似语言出现，让 6 岁的小朋友可以在一个小时之内学会编写一个简单的游戏。
当我们在将 Scratch 作为一门正经的计算机语言看待的时候，语法和开发环境这两个属性会立即显现出来。就语法层面上讲，Scratch 从 1.0 到 3.0 其实没有本质上的改变，如果不出意外今后在语法层面上也只会是局部优化和调整，因此国内社区目前对于这部分的态度基本是全盘接受。就开发环境层面上讲，Scratch 将自己的开发环境称为一个编辑器（editor），从最早的 Smalltalk 到如今的 Javascript，用来实现 Scratch 编辑器的技术架构的确更改了好几次，最新的 Scrath 3.0 则主要基于来自 Google 的开源项目 Blockly，对于这一部分国内社区的工作似乎也比较少。
既然在“语言”这一核心技术上一时难有突破，那就换个思路通过构建社区来进行技术运用上的微创新，这样离用户和商业模式都会更近一些，也许这就是目前国内在线社区的底层逻辑。可惜的是，这样的做法很有可能是弊大于利的，Scratch 之所以能成为一个被广泛关注的项目，其创新型的编程方式自然是很重要的原因，但其社区化的运作方式更是其精髓所在。目前 Scratch 官网已经是一个非常完善的社区了，其上汇聚了来自全世各地的参与者，或许在进行社区本地化的同时，我们同时也需要思考如何将 Scratch 用户与全世界的爱好者对接？不断通过本地化的在线社区将国内的 Scratch 用户群不断分隔孤立，彼此缺乏交流和分享，真的会是一个更好的选择吗？
为什么我们热衷于本地化
Scratch 项目非常成功但又并不完美，在全世界拥有众多拥趸，而且背后还闪耀着 MIT 这块金字招牌，再加目前大家对于编程教育的普遍性焦虑，任何一条或者几条原因都可能是导致一个本地化 Scratch 社区萌芽并产生的原因：
1. 借鉴 Scratch 的语言形式进行产品化
Scratch 的可视化编程方式异常直观，对任何初学者来讲都是很好的入门工具，因此对于那些需要涉及到编程的教育类产品来讲，Scratch 这一语言形式无疑是最佳选择，至少对于初学者来讲是如此。一个产品只有入门足够简单，但同时又有足够的深度供用户来挖掘，才能产生足够的影响，在这类产品的背后 Scratch 显然承担了入门简单化的重任。
随着 Scratch 3.0 的上线，这类产品是否可以考虑通过 Scratch 3.0 的插件（extension）系统来连接 Scratch 社区呢？毕竟 Scratch 3.0 已经可以支持 micro:bit 和乐高的 EV3 了。这一路径当然不会太容易，但可能也没有想像的那么困难，特别是对于国内一些已经被广泛接受甚至已经开始走向世界的品牌来讲，主动联系并与 Scratch 组织达成某种程度上的合作，在官方的插件系统里加入对这些产品的支持，其实也将极大扩展自己的社区和用户群体。
2. Scratch 的插件系统目前还缺少社区化机制
对于大多数早期产品的开发者来讲，即便他们愿意去开发甚至开源一个针对于自己产品的 Scratch 插件，在实际操作的过程中也会发现这条路将会被很快堵死，原因在于我们很难要求 Scratch 官方去支持一个他们从来没有听过的某种硬件产品。如此来看，Scratch 目前的确还缺少某种沙箱（sandbox）机制，使得数量尽多的用户可以在这个环境中实验和发布自己的插件，同时还能与所有 Scratch 用户进行分享。
我不认为 Scratch 团队没有考虑过样的问题，有可能只是目前尚未实现罢了，或是因为资源或者精力的问题暂时搁浅。但实现一个完整的插件沙箱机制很可能也会涉及到诸多方面，包括开发、测试、分享、加载、更新等诸多问题，所以即使 Scratch 团队下定决心提供这一机制的话，恐怕也不是一时半会可以上线的。这样一来，许多开发者不得不为了一两个插件而构建一个完整的 Scratch 编辑器，进而主动或者被动地形成了一个小型社区。
3. API 缺失，集成困难
处于长尾部分的用户很可能为了一个 Scratch 缺失的功能，进而构建一个完整的 Scratch 网站或者社区，这种形式上的微创新可能是 Scratch 官网永远无法满足的。例如，将制作好的 Scratch 项目更好地适配到手机，这一点很可能更多只是基于传播到非 Scratch 用户（比如父母）的考虑。
这一点让我想起了十年前的山寨手机，但某种程度上的确也是 Scratch 颇值得诟病的可扩展性导致的。在目前的互联网环境下，提供良好的 API 以便于第三方进行集成基本算得上是标准的做法，但 Scratch 网站在这一点上似乎并不太用心，Scratch 2.0 提供的 API 在 Scratch Wiki 网站上躲在一个很不起眼的地方，而且居然可以看到某个 API 在上线之后由于某些原因又被删除了，所以可用的 API 功能不是在增加而是在减少！
如果 Scratch API 更加完整且易于集成的话，一些功能性的需求其实完全可以基于这些 API 接口来实现，比如通过 OAuth 登录之后，可以检索出用户创建的项目，获得这个项目的内容，在外部网站上查看或者修改，并且修改后的内容包括评价（commnet）等都可以存回 Scratch 网站，从而形成完整的闭环。
4. 官网访问太慢
尽管 Scratch 使用了 fastly 提供的 CDN 服务来提高全球用户的访问体验，但有些时候的确感觉资源加载的速度稍慢，特别是与国内的服务器来进行比较的话。
如果换一种思路，将编辑器的功能缓存在国内的服务器上，或者就直接访问本地的编辑器，这一问题也许能得到解决。从另一个角度来看，如果国内的用户在 Scratch 社区内的人数众多并且积极贡献的话，其实没有道理不引起官方的重视，毕竟在目前的互联网架构下这种全球性的网络访问本质上还是要看资源是否分配到位的。如果国内的用户数量迟迟上不去甚至下降的话，一定不会成为一个需要得到更多支持的地区，而这一切也都取决于国内社区在 Scratch 官网上的活跃程度。
下一步迈向何方？
本地化的 Scratch 社区对于推广 Scratch 这一语言形式来讲无疑是有用的，所以不可能一棒子打死说其毫无意义。我们真正需要思考的可能是从社区的角度来看，如何才能更好地平衡本地化和国际化这一问题。
两者能否更好地连通？
Scratch 官网是否可以提供更好更完备的 API，使得本地化的社区可以将用户的项目同步到 Scratch 网站并进一步与全世界的用户分享和讨论？本地化的社区在保持自身特点的同时，是否可以从 Scratch 社区吸引更多的用户参与？不过这样的结合最终会面临大鱼吃小鱼的问题，所以如何权衡其中的利弊并找到自己的独特优势可能是本地社区亟待解决的问题。但在我看来，即使两者不通过某种形式互通用无，迟早也会面临类似的问题。本地化的 Scratch 社区如果只是照搬 Scratch 的模式而没有自身的独特性的话，迟早也会面临用户的流失。
增强 Scratch 编程器的可扩展性？
作为 Scratch 的开发环境，官方将其称为编辑器而不是集成开发环境的确不无道理，它确实缺乏现代开发环境所需要的一些组件，在可扩展性上也捉襟见肘。虽然官网已经将 scratch-gui 独立出来，并在 3.0 中引入了插件系统，但目前来看都还处于非常早期的阶段，如果有一个像 Atom 或者 VS Code 这类编辑器所类似的插件系统的话，其实很多本地化社区是可以作为一个编辑器插件而独立存在的。
我们认为更加完善和强大的 Scratch 编辑器插件系统是 Scratch 团队未来应该仔细考虑的一个特性，同时开源社区也可以尝试在这一方面投入更多的工作。