#128 楼 @dorentus 谢谢，涨姿势了。

#5 楼 @xiaoronglv 700 600 亦可

最简单的原因，less sass 等都支持变量，bootstrap 大量依赖预定义的一些变量，使用 less 或 sass 会减少重复代码的产生，无论是写新的还是修改旧的都会变得很简单。

编译好的 css，如果你想改一个颜色，或是一些重复较多的片段会累死你。

当然，除了变量之外还有很多特性，基本上都是为了便于代码重用，便于模块化的编写和修改。你做前端的出身不应该不懂这些，即便你不熟悉 sass 至少也应该了解 less，毕竟 less 是不依赖 ruby 的。

bootstrap 的 gem 有 v3 的分支，你可以这样用：

gem 'bootstrap-sass', :git => 'git://github.com/thomas-mcdonald/bootstrap-sass.git', :branch => '3'

图画的很萌

#35 楼 @yedingding 你要坚持这么说，我也就只能当你赌气了，问题出在哪儿大家心里都清楚。

#15 楼 @zhibin_ 别抓着这种细节不放，翻译不是一个人的事情，每一位译者有每一位的习惯。有些人认为简单方便的方法，有些人还就是不会，不要因为这种技术原因给翻译制造障碍。

#28 楼 @yedingding 1:5……

其实国家队大家一直都是支持的，中国足球的问题，哎，说多了都是泪。

第一句话已经很明显了……

啥意思？你自己做的网站样式表找不到？

啊哈哈哈，3:1 赢了，好过瘾~~~

@leomayleomay 身体不适，可能没有首发，说不定会给垃圾时间露露脸。不过不管上不上直播不能错过。 @TsingHan 你魔领先了啊，又是范大将军……

#7 楼 @small_fish__ 厄齐尔转会阿森纳了啊，今天第一次亮相，对阵桑德兰，英超。

#5 楼 @small_fish__ 呵呵，今天很高兴，关键字就是德国哦，厄齐尔来了，还有可能上场。

#3 楼 @wormful 哪里，不用客气，无论多少年这个只是经历而已，只要喜欢足球运动的都是球迷啊。

#1 楼 @Saito 哈哈，好，外星人我也好喜欢，就是他去的队都不怎么喜欢，那个年代意甲比较喜欢尤文图斯，因为巴乔。

#12 楼 @xiaoniuniu 你这不是求解的问题了，这个是很基本的插入数据的事情。你现在的数据库里的数据都是通过你的应用界面插入进去的对吗？但是你换了地方以后这些数据就不复存在了。要么你写一个 seed 把这些数据再生成一遍，要么你把本地数据库导出，再导入到服务器的数据库里去。

#10 楼 @ytwman Rails 官方曾经做出的答复：

There are no stablished practices regarding guides transalations. There have been a few attempts by different communities, but no complete set that I am aware of by now. The practical problem of translations is mainly maintenance. It is a non-trivial effort to keep them up to date in English itself! :)

此前并未有针对手册翻译的成型的实践方法，很多社区都作出过相应的尝试，但目前为止我没有看到一个完整的范例。实际当中的问题主要是在维护方面，即使保持英文文档本身的更新也需要付出很大的努力。

@zhibin_ 你是要牵头做这个事情吗？如果是的话那很好，我建议可以：

1. 联系一下 @huacnlee @lgn21st，依托在 Github/Ruby-China 组织下，请他们建立一个 Team；
2. 把文档项目指派给这个 Team，你做 Leader；
3. 在社区召集志愿者担任翻译、审阅、维护代码更新等工作，在 github 上把他们加进 Team 去；
4. 商量目标、策略、步骤、规范、进度等事项，形成文档放在 github 上；
5. 更新代码，开工。

#9 楼 @xiaoniuniu rails console 里面怎么向数据库插入数据你会吧？

#8 楼 @zhibin_ 问题就在这里了，如果我是译者的话，我宁愿你告诉我“每六个月来 diff 一次，统一修改”，而不是“每隔三天来 diff 一次，频繁更新”。

这是时间成本的问题。另外，这两种修改的代价并不是一样的，不仅仅是繁琐的问题，更重要的是在 edge 文档里会出现那种反复修改反复校对的部分（有些地方是要跟随代码的变更而变更的）。你如果要求译者保持进度同步，那就意味着译者也得经历和作者同样的一个过程。

这是其一，还有一点，edge 对应的代码是 master 分支上的，是未来的变化，而不是现在的状况。你得考虑真正看文档的人用的是什么版本？万一在未来的版本有个很大的变化，edge 文档也跟随这个变化做出了修改，但是这个版本尚未发布，那么你这个文档发布出去就会对很多人造成困惑了啊。

为了解决这个问题，那么你还得保留一份 stable 版本以适应目前正在广泛使用的版本。这样一来就变成了译者需要维护两个版本，以后能不能做到我不知道，但初期能吗？有这个必要吗？

所以我建议先集中精力把 stable 完成，若此后还有余力的话，再去追 edge，能够追到和 5.0 同步那是最理想的，那得看我们有没有足够的人力和精力来做到这一点。

#6 楼 @zhibin_ 你这个太理想主义了，假设有一个人翻译了当前 edge 的一篇，然后一篇的原文不停在更新、更新、更新……你怎么保证原来的译者可以一直跟踪这个进度？人家更新是往里面填东西，不需要考虑差别，我们这翻译你一样 diff head 和 head~1，因为万一原文有改变，你译文不也得跟着改？这个变化是相当频繁的，你看一下官方库的更新日志就知道了。

所以，理想的办法还是跟踪 stable，因为一旦 stable 了，除非明显的错误，否则 rails 是不会去改动原文的，这样就给了译者一个相对稳定的原文，翻译起来才流畅，不至于缺漏。到了下一个 stable 发布的时候，召集原来的译者做一次统一的查漏补缺就好了。

如果你的目标是为了时刻保持更新，这其实不是翻译手册的目标。你要想想翻译手册主要是给谁看的？对于你的目标人群来说有必要保持这种频繁不确定的更新吗？他们跟的过来吗？到头来还要抱怨你翻译质量不好，三天两头变化。而且 edge 版还要保持频繁发布……反正这个过程是很多麻烦的。

对了，还有一个建议。在翻译的时候要求提交者提供两个版本，一个是纯中文版，另外一个是英中对照版。对照版按段落分隔，原文在前，译文在后。两个版本走两个路径分支，可以都发布，也可以只发布纯中文版，对照版做别的用处。

这个别的用处主要有两个：第一，如果有人做审阅工作的话会比较方便；第二，对那些希望同时学习英文的人来讲是个福音。

而对译者来说其实也不难，翻译的时候保留一份副本不要去掉原文就可以了。

#3 楼 @zhibin_ diff 4.0 and 5.0，然后查漏补缺吧，貌似也只能这样了。

#18 楼 @fengkuok 把你要说的话拆成片段，拆成各种只需要最基本的“主谓宾”就可以表达的片段，然后写出来。你不用怕别人看不懂，真有看不懂的地方可以再商议，往往对方会问你是不是 xxx 的意思；但是如果你担心别人看不懂就不好意思写了，那你永远都写不出来。

#20 楼 @Kabie 问题是有很多人会骂你，难道你没体验过？

1. 不要 rails/docrails。这是一个 Public Commit 的库，用于 Quick Fix，所有的改变在合并到 rails/rails 之前还要重新审阅。所以只有 rails/rails 才是最终的版本。

2. 建议一开始只专注于一个版本，而且应该是 4.0，因为炒冷饭很痛苦。

3. 就像 @Ray 说的那样，不要 edge，要 stable。edge 留给有能力读原文的人去看足矣。

1. ~/.vim 目录改名或删掉；
2. .vimrc 改名或删掉；
3. set all& 命令重置所有选项为缺省值；

#10 楼 @fengkuok 如果我们把学习英语当成一个任务，或是一个需要量化的指标，那就很容易让自己半途而废，这种挫折感是很让人难过的；如果我们把学习英语当成一种习惯，而且不需要是受迫性的习惯，那就会变得容易得多。因为习惯这种东西是很随意的，根本没有“半途而废”这么一回事。

我见过一些人学英语喜欢给自己订计划，比如说每天多少个单词，每周读几篇新闻，每个月翻译几篇文档……这真的是应试教育的流毒啊。学英语干嘛要如此折磨自己呢？关键在于，每当我们看到不认识的单词，短语，词句的时候，有没有那个习惯去查阅一下？这就好像编程要养成习惯查 API 一样，用不着每天几个方法，每周几篇文档的搞自己吧？

没有针对你的意思，只是看到你说“半途而废”有感。

http://scurker.com/projects/particles/