项目规划 #1
Description
依然是长篇策划文先行
如能提点意见，非常感谢！
构思
如果你嫌下面太长(4000多字) 只看这一段也可以
用户进入网站，看到目前进行的项目和在线人员(社区的体现)。
登录后自动按照用户喜好的领域过滤项目，发现一个项目很有意思(领域化与推荐功能)。
于是点开该项目主页，通过查看该项目的介绍发现该项目是一个“开放工程”型项目(多类型项目)。
于是进入项目，首先看到的是当前在线的用户，点击头像进行了解和聊天之后开始具体的汉化。
通过按照难度和任务分配的情况进行智能分配，用户很快就找到了适合自己的条目(智能分配)。
于是该用户开始进行翻译，大部分的条目都可使用机器翻译稍作修改得到(机器翻译)。
翻译继续进行，发现有一个词不认识，于是查看文字上面的提示，(自动提示)
发现这是一个自造词，通过一定的猜测和考证之后，他将翻译的结果填到上面的文字提示当中(主动标准化)
用户继续进行翻译，发现有大量条目的相似程度很高，他点了一下“生成模板”按钮将当前文字的相似点和区别填入(相似识别)，
之后再遇到，就使用模板，一般只要改几个字就可以了(模板)。
项目全部翻译完了，这个时候需要校对了，每个人都可以参加投票，还可以修改别人的条目(不定版本)。
用户发现一个条目翻译的不对，但是那个版本已经被锁定(平行版本)，
于是用户点击创建版本选项，在该行上创建一个新的进入候选。
翻译结束，点击生成，刚才所翻译的文件立即被输出，用户发现这些文件中除了一般的文本文件，还包含class等二进制文件(多格式输出)。
多日后，用户收到一份邮件提示该项目的文本已被更新(更新订阅)，
于是用户回到项目，发现除了新增的任务很少，因为之前的工作已经将标准化表维护得很全了，所以新增的条目很快就能完成(二次项目支持)。
但是新增的条目虽然相似但又有很多不同，所以用户切换到对比模式(自适应模式)，多个条目同时呈现在屏幕上，效率高了许多。
工作很快又完成了，结果发现这个项目已经从“开放工程”型转为公有领域型，
于是用户将自己新修改的部分fork到了一个版本到自己的用户空间进行发布，并且给原有的项目提交了合并请求(社区化体现2)。
解释(by craft)
新建项目，添加关键词标签以及自动生成一些关键词标签。
在新建项目的同时自动生成一个带历史管理功能的主分支。
每次新建分支时候按关键词寻找领域然后推荐外部译名标准词库。
然后开始编辑，编辑过程中的新条目也会自动加入到本地译名标准词库中。编辑者也可以手动添加译名标准词汇。
实际编辑使用的就是外部加本地加译名标准词库。
某一个编辑完善的历史版本可以标记为发布状态。
编辑者也可以随时开新的分支。
逻辑关系：
项目（具有多个标签）-不同分支（每个分支具有一套译名标准系统）-分支内有历史管理功能
缘起
1. 主题?
汉化的本质就是本地化，是将一种语言翻译成另一种语言的过程。
但不同于一般的翻译，每一个项目语言做了国际化处理的项目，
在其内部必然有负责本地化的文本，大部分的汉化工作就建立在这之上。
但是也有不带有国际化功能的项目，此时就需要进行技术手段修改，比如修改二进制，外挂注入等。在游戏中可能还要涉及到对游戏的破解；在视频字幕中还要涉及到时间轴等。
因此，我们说汉化是一种具有阶梯难度的复杂工作。
2. 问题?
在现在也存在一些公众的汉化平台或是协作平台(如etherpad crowdin translatewiki 扑家汉化平台等)，但一般都不够开放、功能不全，独立性较强。
没有社区的支持，每个项目都非常孤立，这并不利于项目的长期发展(特别是对于小型项目)。
3. 目的?
在长期实践中已经发现了现有平台的许多劣势，我们想要去改变他。
小到一个微不足道的项目，大到整个汉化界（乃至世界范围的），我们都想去改变它的格局。
将以处处细微的力量汇于一点，化微光为日光，这就是项目的初衷。
4. 手段?
通过建立一个平台来统合各方面的资源，汇集各方面的人才，将真正意义上的带动全民汉化时代。
平台集人才交流、项目合作作品发布等板块为一体。
无论如何，在一个统一有秩序的世界，大家都朝着一个目标努力，带给普通用户的毫无疑问就是优秀的质量，也就是我们的追求。
分析
1. 越来越碎片化的时间
进入现代生活，对于大都数人们来说所能利用的更多的是碎片状的时间。
因此对于用户来说，如何利用好这一点碎片装的时间无意识提升项目执行效率的关键。
在传统的模式中这点是非常难以做到的，因为每个人被分配的任务都是不实时的，对与项目了解的时间也比较有限。
即使完成了任务，一般质量也很低下。
2. 越来越复杂的任务
随着科技的发展，项目的性质几近改变，从最初的单纯汉化演变成了多领域的结合状态。
如上所述，仅仅汉化组的工作就有好几项，这些任务以往都是一人独立完成，但在未来项目规模不断扩大的情况下，
难免会需要一个托管平台来进行统一的托管。(目前WL也在考虑)
另一方面，当项目的工作量变大时。对总体效率的要求就非常的高，也需要借助科技来进行。
3. 越来越开放的网络
网络在慢慢的发展，各类社区如雨后春笋版出现。我们的主题，汉化却很少有一个成熟的平台。这其中的市场是一个庞大的待开发土地。
用户在现代社会的影响下有一份独立自主的行动主义，但用户往往存在一个心有余而力不足的状态，汉化组就是其中的一个表现。
通过一个组织来弥补个人精力和知识的不足，通过协作来完成日益庞大的项目。
可以说，如今的时代就是协作的时代。在这样的一个大背景下正急需这样的一个完全开放的社区。
设计
“自由是一种价值，创造了自由，就创造了价值。”
1. 自动化
如上所述，WL是一个以汉化(本地化)为主题的社交网站。
汉化网站所必备的功能就是自动化，但过度的自动化又会给用户带来一些副作用。
在对总体策略的均衡上，是一个值得反复考量的问题。
而对社交网站来说其社交功能也非常重要，对于一般用户其重要性甚至可比汉化本身(优先性)。
其中，自动化作为翻译类网站最主要的功能，除用户习惯记录之外，还应对项目性质和用户状态等多方面进行考量。
-
多用户同时编辑
为了实现这一点，一是需要对数据进行原子化，并引入平行版本的概念，单独对待每个平行版本，二是要对数据进行实时同步，同时让用户清晰的认识到，当前文件还有多少人在编辑。
但又是非独占式的，用户可以自行选择创建平行版本。 -
数据重用机制
在传统的预翻译表(如crowdin)外加上领域和模式的概念，加强同一领域不同项目的整合，最大限度节约翻译成本。
-
领域
(设计图)
领域和标签都是项目的属性。
领域和标签是对翻译项目的类别概括，精确到文件和项目。
但是领域与标签不同，它是一个用于提供翻译帮助的属性，如果不需要使用可以不加。
其中包括标准化表、预翻译表、字典、模板等。
针对每个领域提供不同的优化策略，多个领域针对情况可以叠加。 -
标签
标记项目的属性，作为用户推荐的依据。
-
预创建
通过管理员，爬虫等方式提前创建项目，但不设项目管理人员（公有领域），可先进行公众翻译，之后进行项目认领。
2. 精益求精
除了效率之外，汉化的质量也非常的重要，为此WL也提供许多机制来进行质量管控。
这其中包括：
-
质量评分
(设计图)
条目的翻译质量可以通过人工，机器等方式来进行评判，可以体现项目整体的翻译质量。
在有多个平行版本的时候，还可以通过投票进行多选一。 -
翻译标准化
标准化的三个阶段
- 红色阶段(检测到但没标准化)
- 黄色阶段(没检测到)
- 绿色阶段(检测到并标准化)
红色是根据生僻词扫描得出的
3. 人文关怀
对用户使用习惯的把握是用户体验的核心体现。
使用下级优先于上级进行优先级匹配，对用户习惯的分析运作一定的容错处理。
忽略少数无意义操作，并按照一定规则删除和撤销习惯。
-
难度优先机制
在项目中难免有难度较高的项目，相对的也存在经验丰富的用户。
通过一定的措施，如难度标记，机器判定等，可以将复杂任务有限分配给熟练人员，一定程度上提高效率。 -
自适应模式
在多种不同的使用情况下，通过表现出多种不同的状态来适应多种多样的项目运作环境。
-
质量优先模式
(设计图)
在此模式下，使用尽可能多的空间来显示提示信息。 -
效率优先模式
(设计图)
在此模式下，尽可能的显示更多的条目，理想的状况下此模式应该与质量优先模式无极调控。 -
自然模式
(设计图)
在此模式下，呈现的就是源文件本身，但不可修改非汉化部分，对于程序等的汉化可以起到更多的参考作用。 -
审核模式
(设计图)
此模式呈现最多的条目并且去除汉化功能，可以进行任意的拖动等操作。
-
-
前端
将编辑不限制于环境。
- 纯键盘友好
- 本地备份(LocalStorage)
- 桌面客户端 (另开贴)
4. 平台扩展
作为一个社区，开放性是很重要的，其中API就是重点一环。
-
对应用API
通过开放如搜索、查询等功能，方便第三方平台进行整合，从而扩大整个WL网络的生态圈。
-
对用户API
开放项目统计图片、文字等挂件以及项目自定义主页等，进一步起到宣传和增加用户粘性的目的。
5. 形式交融
一般汉化工作的展开，主要分为以下几种：
-
离线汉化
即提前分配好任务，在之后进行汉化工作。其优点是在组织良好环境良好的情况效率很高。
但一般情况下，标准化往往都不到位，需要后期进行多次校对。
因此此方法容易引起质量造成的效率问题。而且因为提前分配，时间分配往往不够平均，人力资源利用率较低。 -
在线汉化
即使用etherpad之类的协作编辑软件，其优点是不限时间，且任何人都可以汉化，人力资源可以得到充分利用。
但因其编辑的特性导致其对网络的依赖性较高，所以往往造成一些额外的效率下降，与离线模式完全冲突，所以在线的功能性不高的情况下，会造成非常关键的问题，其中的重点就是对用户使用习惯的违背。 -
改进
以上两种的形式或是割裂用户与项目，或是违背了用户的使用习惯。
在对比以上几种进行归纳总结之后，就出现了WL特色的汉化方式，其将各种方式的优点集于一身，同时给用户非常大的自由。
其主要是对汉化的时间上进行完善，结合在线的高人力和离线的高效率，使用多种技术，如动态分配、后期合并等方式，将任务分为多个部分给离线在线用户。保证两者有机的融合。
同时通过多种方式进行标准化提示来统一风格、提升质量，提高了宏观的效率，同时也给离线用户提供静态的标准化表，尽可能地提高质量。
6. 项目性质
(设计图)
用户的需求往往多种多样。体现在项目化的社区之中，如公众翻译，在不同的情况下有着不同的影响，可好可坏，所以应给予用户一定的选择权，不能一概而论。
其主要形式分为以下几种：
-
公有领域
该类型项目确保了其不能被少数人管理，使用完全民主的管理模型。所有有效用户都可以自已创建版本发布。
-
开放工程
该类型项目与共有领域不同的是有项目的所有者并可以拥有是使用协议。
-
创作共享
该类型项目有一定的管理人员，但公众都可以参与编辑，但由管理人员来最终建立版本和发布。
-
独立协作
该类型项目有一定的管理和编辑人员，其他人员可以查看、评论、提交建议和与编辑人员交流，但不可以查看源文件。可以放置协议。
-
私密项目
该类型项目对一般人不开放，只可见其部分项目信息页。
-
隐藏项目
该类型项目对一般人不可见。
7. 社交网络
(设计图)
在WL的网络架构中以成果交流为主，包括其后期质量跟踪(bug提交等)，以及实时翻译交流为主。通过内嵌在各个子平台中的交流模块充分整合。
同时通过对其他微博、贴吧、即时聊天的集成来进行扩展。
其使用目的主要是：
-
促进项目质量
通过即使聊天的形式对用户体验进行实时性的集成，可以进行多方面的协作。
配合基本的翻译辅助功能，而提高项目的总体质量。 -
辅助软件开发生态
通过多语言的互相协作，建立起一个跨国跨语言的成熟软件开发辅助平台。
-
加速对其他平台的发展
通过建立一个成熟的社区来聚集人气，从而辅助其他平台的发展。因此，建立一个社区是必要的、有价值方案。
在提高社区人气的同时，提升了总体创造力，也有利于项目质量的良性发展，从而创造真正的价值。 -
扩大整合社群
通过一个成熟的平台，可以吸引许多大规模较大的团体(如汉化组)长期进驻，提高平台知名度和生产力。
在实现以上要求的过程中，对平台的功能总结如下：
-
汇集
通过喜好领域，及汉化风格等对用户和项目进行互相推荐，从而提高用户粘性。
-
交流
进行线上的交流，包括独立讨论版、项目实时交流等。
主要突出成果和经验的分享，以及合作事宜等。 -
流动
主要是通过虚拟货币等价形式来提高用户粘性的工作，以用户贡献作为依据，鼓励用户。
8. 组织管理
(设计图)
对一个组织而言，内部的人员调配也是非常关键的。
- 主要用户角色
- 监督
- 管理
- 编辑
- 审核(测试，质量监控)
-
任务分配
(设计图)
除了通过上述方式进行自动分配之外，还可以进行手动分配。
开发时间线
分析比较重要的功能进行优先开发。
主要用户行为
- 编辑 -> 查找简单项并迅速完成→简单项筛选功能
- 编辑 -> 查找复杂项讨论完成→讨论功能
- 评论 -> 观察多个翻译项→列模式切换
- 评分 -> 对翻译项进行评分→评分功能
- 校对 -> 修改不一致的特定词汇翻译→译名标准化
- 发布 -> 编译，转换，打包等
- 其中WL将校对和翻译合成一起 甚至将标准化无限提前 一般翻译没有进行完毕 标准化就进行完毕了
- NOTE:
- 对多种发布方式的自适应方式应对用户粘性做出良性影响
- 对用户的使用方式应作记忆 并对特定用户进行分类
- 在对翻译项的挑选中 对不同的用户采用不同的优先级
- 内容管理 -> 基本项目管理及展示
- 版本控制 -> 轻量级可移植后端支持
- 协作环境 -> 超轻量级翻译环境
- 质量控制 -> 基本评分功能
- 产品化 -> 基本文件格式解析和应用功能
被动考量
版权问题
通过放置服务协定和开源协议限定等可以在一定程度上解决问题，但始终不能彻底解决问题。
作为一个开放的平台来说，在中国的发展可能会受到一些阻力。
但愿只是杞人忧天。
安全问题
除了基本的性能上、逻辑上的防攻击，在一些开放性的功能上应该做好隔离，防止XSS、CSRF等攻击。
资金问题
暂时还没有。但竟然是网站，最基本的费用就是域名、服务器、SSL证书等费用，对长期维持来说必须要有稳定资金来源，也就是广告、战略合作、商业化等的考量。