ethanlin-twer / translation-spring-mvc-4-documentation

Spring MVC 4.2.4 RELEASE 中文文档完整翻译稿

Spring MVC 4.2.4.RELEASE 中文文档

本项目翻译的是Spring MVC官方4.2.4.RELEASE版本的文档，包含原文档第21章Spring MVC部分的全部内容。译文尽力于准确传达原意，其次兼顾译文的流畅自然。至于风格和质感，则仍在努力。希望它能为读者带来查阅、学习的价值，自己时不时翻之，仍有收获。

目前多数章节的翻译已完成，剩余部分章节仍在进行。文档仍在维护状态，主要还有译文细化、术语定义、翻译规范、内容、主页修缮、自动化部署等工作可做，issues这里有一些有意思的idea。翻译过程中遇到值得探讨的翻译问题、取舍及最终解决方案，读者可见翻译注记。

本翻译初始只是自我学习需要，逐渐完善后才有坚持完成的执念。陈丹青在《木心谈木心》的后记中，讲到他犹豫于出版木心先生这本私房话的心境。为本译文做推广、宣传伊始，我也开始面对我的读者，读之，感觉真挚感动。不敢自比木心，我在我的风中等消息。

——2016年6月28 交房租日，8月28日 完成自动化部署后补稿

中文文档地址

• 主站：https://spring-mvc.linesh.tw/
• 国外Gitbook原站

原文地址

Spring MVC 4.2.4.RELEASE Documentation

其他相关翻译项目

为了对目前Spring MVC部分文档翻译现状有个大致的了解，可以“Spring MVC 中文 文档 翻译”作为关键词，浏览其在google和baidu上前6页的搜索结果。其中以下项目值得留意，前两个均或完全或部分地翻译了Spring MVC部的内容，可供参考；后面三个项目未涉及Spring MVC部分的翻译。

项目	作者	项目Github	描述
Spring框架参考文档	一个团队	Github	该项目规模较大、参与人数较多。翻译内容是Spring 4.1.3.RELEASE版本全部文档，其中MVC部分的文档也翻译了一大半。其项目主页保留了与原生Spring文档较一致的样式，很不错
Spring Framework 2.5翻译计划	满江红机构	-	感谢dsliu在gitbook上给我提供此版译本链接。译本是整个MVC 2.5.2版的全部文档，其中MVC的部分同样齐全
Spring Framework 4.x参考文档	waylau	Github	翻译了Spring文档的简介、新特性和容器IOC部分
Spring Framework 4.x中文翻译	sunrh	Github	翻译了Spring文档的简介、新特性和容器IOC部分
Spring 中文文档3.1	wizardforcel	-	主页已标记废弃的项目。楼主BIO是专注单身二十年，言语间竟有一种大学宿友不是说我的宿友的即视感

友情链接

这个译本我在国内的多个站点均发表过一篇相同的推广文章，如OSC/CSDN/Iteye/博客园/掘金/v2ex/segmentfault/Githuber等。除了交付的译文本身外，还聊瞎扯了一些其他的东西。同时，关于这个翻译文档的创始、管理及自动化部署等方面，我也已将其总结成为文章。此二篇文章是对这个项目的完整记录，均发布在我的博客上，有兴趣的读者可以前往阅读。后来我又做了一些主页样式上的迁移、自动化了一些构建前文档预处理的工作，还有一些代码的重构。这部分未做记录，但代码和部署构架方面我十分满意，其精华在package.json和构建脚本中。

• Spring MVC官方文档翻译稿发布
• 我是如何进行Spring MVC文档翻译项目的环境搭建、项目管理及自动化构建工作的

联系方式

阅读过程中的任何想法、建议、吐槽、强迫症不给译者狂点100个赞就浑身不舒服、觉得赞、觉得不赞，无论关于翻译、技术、样式等，对我来说很有意义啊我这文风竟有一种安妮宝贝般的性冷淡感！你可以通过以下的方式联系作者我：

• 来Github点赞 被消费一个
• 在Gitbook讨论里 给我留言
• 给这个项目提 issue
• 给这个项目提 pull request
• 邮箱：[email protected]

License

MIT License

贡献者 Contributor

感谢那些让这个项目变得更好的人们。

吕立青 Sun SongWang 易枭寒 xcatliu HeartUnchange HeartUnchange

translation-spring-mvc-4-documentation's Issues

404 Page

• Goggle: 404 examples

---

• https://designschool.canva.com/blog/404-page-design/
• http://www.hongkiat.com/blog/60-really-cool-and-creative-error-404-pages/

spring web flow特性第三条的建议

翻译的很好，从头开始看，流畅不反感。
文章开始 spring web flow特性的第三条，我看没有完整翻译，以下是我的一点建议，供参考。

web flow是mvc的一个扩展，有点类似于工作流，用以实现类似向导来完成一个web事务。那么这一段这样翻译如何？投票。

原文：
SWF allows you to capture logical page flows as self-contained modules that are reusable in different situations, and as such is ideal for building web application modules that guide the user through controlled navigations that drive business processes.

译文：
SWF 允许你将一些有逻辑的页面流抓取为一些独立的模块，在不同的情况下重用，这在构建引导用户凭借导航来推动业务处理的情形下是完美的解决方案。

中文支持 - GLOSSARY表

目前，GLOSSARY是以

## Term
Definition

这样的语法来定义一个GLOSSARY。但是Term的这个地方不支持中文。

尝试找插件解决，或自己撸代码解决。

参考：

• Gitbook glossary定义：http://toolchain.gitbook.com/lexicon.html
• gitbook仓库的issues：https://github.com/GitbookIO/gitbook/issues

如何为后续版本提供支持

今天午休上厕所的时候脑门一拍，既然版本之间的变更不一定会很大，那么说明4.2.4这个基准版本变动每次版本升级变动的内容并不会很多。

• 一个diff工具，能可视化地给我指出两个版本之间不同的内容，最好是能像git diff那样，红删绿加。能够定位到哪章哪节就更好了
• 主页的改动
  • 增加一个tab切换不同的版本
  • url改動，publish文件夹的结构，可能需要增加一个版本层，比如v4.2.4，current，v4.3.1等

主站挂了嘤嘤嘤

主站不能访问，有其他访问地址没

typo: 'Spring' -> 'String'

http://www.v2ex.com/t/288717#reply13
http://www.v2ex.com/t/288717#reply17

Heart of doing this 翻译的初心

今日发现Spring 4.1.x的官方文档已有志愿者进行了自组织，投入了许多精力有组织地对其进行翻译。感受冲突，一方面敬佩为此无私奉献的人，一方面也很期望市面上能有质地醇厚且较为权威的译本出现；另一方面，又希望自己做的不是重复工作有其意义，希望坚持自己翻译的风格，同时使译本能得到承认。

一个译本的生命不仅在技术层面的翻译，也有风格和市场接受度方面的影响。考虑后者让我觉得分心和功利。……觉得归根结底是功底不扎实，努力不够，期望不相符的结果。注意时刻反省自己的急躁和功利心。

真是冷淡的文字。

上周六在一些平台为这份译本做了一些推广，一开始希望它得到肯定的心似乎已满足。看完上面两段，我都觉得累。想这么多干啥，爱翻翻，爱干啥干啥。想好做什么事，就去做不是更重要吗。扯这些没用的。太high就没注意到周围人的感受，真是作死。对于我来说，不缺想法和理解，缺行动。就此，憋哔哔。

MultiPart的内置支持与插件支持

Gitbook v3支持了一本书多个part的玩法，这很好，不过numeration挂掉了，章节号会变得及其难看。那么现在有两个方案：

• 使用Gitbook builder v2.6.7，多part功能由插件来支持
• 依然使用Gitbook builder v3.1.1，这个numeration的功能就坐等修复

自己去修复这个numeration暂时没考虑。同时，gitbook有很多好的特性都没在文档里面说明，需要自己去看issue，还有很多好的插件，可以发掘一下

中文支持 - 搜索

Gitbook支持搜索，但也不支持中文。要么找插件，要么自己撸代码解决。

GLOSSARY表的完善

翻译到第十几章的时候才发现可以使用GLOSSARY表来解决一部分词汇翻译困难的问题。整理的时候需要把各个章节里面的一些词汇整理到GLOSSARY表里去

开发体验：本地调试

目前与七牛相关的代码都必须提到travis才能调试，也不是说本地不行，是设施要适配比较麻烦。这个对于开发体验来说是非常糟糕的，需要本地起一个类似moco的东西。我想要的是，做到本地与真实环境一样的调试，并且做到最简单。相当于mock掉集成测试吧。

细化前3章的翻译，移除原文

• 第1章
• 第2章
• 第3章
  • 3.1
  • 3.2
  • 3.3
  • 3.4
  • 3.5

Documentation translation style 文档的翻译风格

阅读一些官方文档的翻译者及翻译风格，寻找合适的表达方式和脉络。吸收好的精华，与自己的表达方式结合。

可配置化，为其他项目提供API

本项目写了一个css样式、处理markdown header的脚本、各种开发笔记，这部分是可重用的，最重要的是要把其中的变化点抽取出来，形成 可配置 的config。像吕靖一开始在提他的博客一样。

像这个Spring boot仓库也是使用gitbook发布的，写作/发布环境（gitbook）、写作工具（markdown）、主页样式、markdown预处理（header调整、link调整、tooltip调整）等阶段与本仓库都是一致的，只不过发布平台可以不一致。这个我自己在用七牛，如果要数out-of-the-box的支持，我觉得gh-page可以说是最快的。

再想疯狂一些，这个过程，我们想变的是 发布环境gitbook 这个变量，写作工具（markdown）是一样的，整个流程是 以某种形式组织的markdown -> 一个有主页文档样式的网站 这样一个输入输出，是否可能把项目做成许多翻译项目都能一键即用的样式转换器？甚至样式都可以考虑自动从原网站抓取，版权问题使用者自己注意。这样去解放样式对翻译者带来的困扰，让你只需要专注在内容的翻译上。

当然我作为一个捣鼓者。

= = 就在我要开工的时候，Atom的字体挂了，变得奇丑无比…然后我就又不想干活了…

考察一下Travis

Steps

• Have basic environment setup(npm, node, etc)
  • basically just specify node version in .travis.yml file and npm is provided by travis by default
• Install dependencies through npm command line
  • install gitbook-cli globally in the travis before_install stage
• Build deployable book structure using gitbook build
• Setup encrypted AK/SK into Travis and access in scripts
• Upload built book directories to Qiniu

Pros

• 界面更美腻
• 刚好学习一下其他的CI
• 在线pipeline

Cons

• PK&SK放到网上似乎不安全

自动化构建 - 建立pipeline，自动化构建及七牛-gitbook站点的同步，实现一键推送，持续集成

在本地翻译是一回事，翻译完push到github由Gitbook提供hook自动构建也是一回事，不过现在想把博客托管到七牛上，就有意思了。当我push以后，有一些事情需要自动化：

• 使用Gitbook v3引擎gitbook build出一个可访问的站点_book来
• 将_book文件夹自动同步到七牛空间./qrsync ./conf.json

这个，好做。但，我想要这些事在一台远端服务器（嗯也许我可以用自己的travis-ci或jenkins）上去跑，而不需要在githook里面做，不然我push一次就得2分钟，这只会让我自发减少push的次数。那么在我push时，流程可能就变成：

• 代码提交到github
• gitbook的hook收到通知，主动拉取github的文章并执行站点的build
• pipeline(travis/jenkins)收到通知，主动拉取github仓库的内容并使用Gitbook v3引擎进行站点的build
• 将build出来的_book文件夹同步到七牛空间

form-backing object术语的翻译

原讨论见这里：https://www.gitbook.com/book/linesh/spring-mvc-documentation-linesh-translation/discussions/4 。

查了一下form-backing object的定义，大概的理解是，当你在表单上提交了一个POST请求以后，需要把一些数据渲染回form中，此时返回这个对象。那么“表单后退对象”确实不是很表意，可能表单返回对象，或者表单返回对象（form-backing object）这样的翻译会更好一些。

待全部翻译完回来fix。

参考资料：

• formBackingObject API: https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/web/servlet/mvc/AbstractFormController.html#formBackingObject%28javax.servlet.http.HttpServletRequest%29

Translation guideline aware and introspection 翻译理念总结与提炼

• 翻译的基本元素是什么？（语法？句式的使用？）
• 个人翻译风格（简洁/文艺/理性）的总结、形成？
• 翻译理念是什么？

英语翻译的学习

真想不到为什么也放到这里来了，又有博客材料了。主要是出于兴趣，看了一些翻译学习的资料，觉得非常之赞，又有脑洞。

定语篇

I admire her coolness under pressure.
译：我佩服她在压力下能保持冷静。

He was the only one to speak out against the decision.
译：只有他站出来反对那项决定。

上面两个翻译十分漂亮！由于英语本身特点，长点的句子可能就前面一个名词，后面一坨连续展开。上面两个例子提供了很好的思路，第一句中under pressure本来是做定语修饰coolness这个名词，译文中直接将保持冷静翻成谓语动词；第二句中如果翻“他是唯一一个站出来反对那项决定的人”，译迹明显，中文句主语在最后面的“人”，前面全是定语，句子的轻重感失衡了。有此对比再看译文，美感跃然纸上，原定语部分变成谓语“站出来反对...”，成为句子中重要的成分，而非仅为修饰语，轻重与字数比例匹配。完美。

简洁是美德

简言之，话说的越自然前提下，越短就越好、越简洁、真诚。可以说「问题很多」，就不说「存在着很多的问题」；可以说「这个问题」，就不说「这样的一些问题」。这两个句法是我观察发现的，说出这话的人，马上就无缘我的朋友圈（不是微信的朋友圈）。为什么？这样的语言存在后退和不真诚，存在「着」、很多「的」，这些词把当下的讨论中的事情，后退了，说成是常态、一直存在着的，避免了讨论和主观表达，所摆出正是一副「世界万事万物，有其利的一面，也有其弊的一面」的官腔；这样「的」一「些」，把对单一特定问题的讨论回避掉，进而泛化成一类问题，还要摆出一副我知道这种问题是普遍存在的姿态。人一不真诚，便失去趣味。很多人长大了就无趣了。

关于语言之简洁，可以参考：

「余光中：怎样改进英式中文」（ http://tieba.baidu.com/p/2238313382 ）
「思果：翻译与国文教学」（ http://tieba.baidu.com/p/4174732401 ）

Chinglish & English

经我感觉，最大区别在于，英语先说重要之物，中文先说与己无关之物。这种核心差异下，可能表现为，英语多被动语态、英语重名词，汉语重动词（请回顾「问题很大」与「很大的问题」之别）等，但背后核心是对客观事物的认定、对个体表达的自信。

木心：问题很大，大到好像没有什么问题似的。

对比中英腔调

坏 Chinglish	好 Chin ese
他的收入的减少改变了他的生活方式	他收入减少，乃改变生活方式
横贯公路的再度坍方，是今日的头条新闻	横贯公路再度坍方，是今日的头条新闻
书籍的选购，只好委托你了	选购书籍，只好委托你了
国语的推行，要靠大家的努力	推行国语，要靠大家努力

对比简明的动词与性冷淡的弱动词-名词拆分：

性冷淡	简明
本校的校友对社会作出了重大的贡献	本校校友对社会贡献极大
昨晚的听众对访问教授作出了十分热烈的反应	昨晚的听众对访问教授反应十分热烈
我们对国际贸易的问题已经进行了详细的研究	我们对国际贸易的问题已经详加研究
心理学家在老鼠的身上进行试验	心理学家用老鼠来做试验
apply pressure	press
give authorization	permit
send a communication	write
take appropriate action	act

真·-性·之冷淡

虚伪	真诚	例子
具有很高的 知名度	很有名	这位作家具有很高的 知名度
可读性 很高	很好看	这本传记具有很好的 可读性
很有 可听性	很好听	这场演唱会的 可听性 相当高
很有 前瞻性	很有远见	这位国家领导人很有前瞻性（似乎也还行，很有远见听起来就比较确定，很明显领导人希望自己除了远见外还有其他的东西，故曰前瞻性）

你的冷淡性很高啊。

在大陆地区无法访问

在大陆地区无法访问，主站，使用VPN也不行，解析不到这个域名，是不是换地址了？

README 中的即时评论链接有问题

在文档上进行即时评论：在gitbook文档上，鼠标划过任何段落右侧，浮现+号时点击即可评论

这个链接链到了 qiniu 的页面里，which donot have the feature.

BTW，我觉得这个即时评论功能有些鸡肋，而且设计得很不人性化，对一句话的评论，居然可以有很多个主题，每个主题里面又有很多评论。这样的二级评论在这里太重了。

更新README内容

• 总结文档的基本内容、框架提纲到README，可能有益于SEO
• 更新散落于各处的书本总结，如Gitbook、Github的一句话介绍等

七牛API——上传前删除bucket现有内容

如题。这样我就不需要每次手动去删了。核心功能已经实现

Todolist:

• bucket删除与文件上传最后做成同步（sync）的，做成异步的在pipeline上跑还是可能有意想不到的情况出现
  • 现在解决方案是：在npm run deploy时，它其实是跑npm run build，现在在build前后加上了npm run qiniuclean和npm run qiniusync的task，一开始就发起remove请求，虽然不治本，但是降低了时序上先添后删的概率。另外，本地在调试的时候，可以放心地使用npm run build而不用担心真正与七牛发生交互
• 七牛代码重构：
  • remove部分的代码对于gitbook的deploy也使用，可能应该放在公用文件夹
  • 使用qiniu.js的多个方法都需要重复传入accessKey和secretKey，应该有其他方法消除重复，减少维护地点
    • 解决方案：使用ES6的class，ak和sk作为参数传入。爽。

参考：

• 官方remove文档：http://developer.qiniu.com/code/v6/sdk/nodejs.html#rs-delete
• 官方remove API文档：http://developer.qiniu.com/code/v6/api/kodo-api/rs/delete.html
• 官方列举（list）资源API文档：http://developer.qiniu.com/code/v6/api/kodo-api/rs/list.html
• list API源代码：https://github.com/qiniu/nodejs-sdk.v6/blob/199342c4a77aa55bd522005cc7cd451478593123/qiniu/rsf.js 这块由于不包含在文档里，我先是自己用list做关键词搜索了代码库里找到，然后又到这个issue里面看到这个链接确认了的，按照function所需的参数传入即可

主页样式

我猜我是想表达，文档最好能与原文档一样的样式。这个对于品牌和一致性而言非常重要，参考以下链接：

• OSC的同学们已经构建好的站点
• Spring-project 的 README.md
• Spring-projects的WIKI

直接对着官网首页样式就是撸！正好练CSS。

• 使用简单数据先调整个body、正文、有序列表、无序列表的样式
• 使用脚本将文档：
  • 从markdown转成html
  • 做header调整，因为从前多页整成一页，header层级要变
  • 将转完html插入到index.html中去
• 整体样式再微调
• 部署到七牛，考虑如何与gitbook页面整合

撸完了擦真是爽。一些扫尾的工作：

• css/js资源路径的优化
• figures目录下的图片转成jpg
• 404
• 缩短log信息长度，精简log内容
• dist目录不用上传了
• 七牛代码重构与复用
• favicon

今天是8月28，离这个issue提出已有两月不止，而这个样式这两天就撸出来了。虽然我撸的疯狂了一些。不过起因是因为若然在share一些css的东西，我刚好觉得这个事情能干就把它干了。长而久之，进步还是有，不过在看到之前也要不懈努力。

完美开发+部署完毕。

Technical terms translation 术语翻译问题

比如，关于controller这样的词要不要翻译成控制器？也不是不行，只是它在中文里的语义辨识度不是很高，尚无法承载它作为英文时所能承载的含义和形态。

类似的还有theme resolver, handler mapping, handler adapter, handler, request, response等等专业词汇，以及map等词做动词的翻译，“映射”，没见过这么说中文的。目前，-er都译为“xx器”，which sounds really 挫。。

目前的翻译风格是，在第一次（我记得的第一次……）出现的地方中英都标注，以后的都统一使用中文。

可能的solution：

• 可以在译文首部添加这样的声明；
• 可以在出现这类词语的时候加一个问号或者引用，在网页底部为全文做统一引用；
• 做css，让鼠标划过的时候它会弹出提示它的英文原文与简要解释。Gitbook的GLOSSARY正正好就是提供这种支持，戳这里，并且还有一个npm插件禁用代码块中的glossary提醒。目测提供了80%的支持。但经使用，GLOSSARY功能目前还不支持中文entry，看能不能贡献一个fix或plugin，翻译完书目以后

主页样式修缮（二）

已完成工作参考这里，撸了一个周末，代码写太多都有点干呕了…

目前还有一些遗留的问题：

• favicon没正常工作
• html头的viewport，在手机端工作
• 代码高亮
• 文档内含的markdown链接还不work，要转成html。又因为变成了一页，那其实就变成一个指向该小节的href。但每个小节的id都是自动生成的（目前是由marked转过去的），并且对中文的支持还不好，所以估计还有巨坑
• 原文档tooltip的样式写好了，但是必须以特定的格式书写markdown以便自己的markdown引擎做特殊处理，然后才能生成符合格式的html