Code Monkey home page Code Monkey logo

progit2-zh's Introduction

progit2 zh

Pro Git,第二版,简体中文

翻译、校对、修改前请阅读 翻译规范

欢迎阅读 Pro Git 第二版。

你可以访问 https://git-scm.com/book 在线阅读本书。

与第一版类似,Pro Git 第二版以知识共享协议开源。

自第一版开源以来,许多事情都发生了变化。 首先,我们将本书的文本由 Markdown 迁移至 Asciidoc。

我们还在独立的仓库中进行翻译,而不是在英文仓库的子目录中。 查看 贡献文档 了解更多信息。

如何生成本书

你可以用 Asciidoctor 手动生成电子书文件。 如果你运行下面的命令,你 可能 实际上获得 HTML、Epub、Mobi 和 PDF 输出文件:

$ bundle install
$ asciidoctor-pdf-cjk-kai_gen_gothic-install
$ bundle exec rake book:build
Converting to HTML...
 -- HTML output at progit.html
Converting to EPub...
 -- Epub output at progit.epub
Converting to Mobi (kf8)...
 -- Mobi output at progit.mobi
Converting to PDF...
 -- PDF output at progit.pdf

发起一个 Issue

在发起一个 Issue 前,请在 bug 跟踪系统中搜索是否已有类似的问题。

此外,如果该问题是在 git-scm.com 网站上发现的,请再次确认 pdf 版本中是否仍有此问题。 该问题可能已被修复,但修改内容尚未部署。

贡献

如果你想要帮助修改或者贡献翻译,查看 贡献者指南

progit2-zh's People

Contributors

8loser avatar alamier avatar aollier avatar archersmind avatar ben avatar branchzero avatar chuckiechen945 avatar codetalks-new avatar crd avatar devbean avatar geno1024 avatar honkinggoose avatar icenature avatar jnavila avatar leo108 avatar leshiv avatar liuxilu avatar max123kl avatar mkarg avatar morganov avatar networm avatar oldsharp avatar ousugo avatar rpjday avatar sanddudu avatar schacon avatar spacewander avatar spotlesscoder avatar yuelinho avatar zwpaper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

progit2-zh's Issues

领取翻译任务 02-git-basics

我会尽快翻译第2章的如下章节:

02-git-basics/sections/viewing-history.asc
02-git-basics/sections/undoing.asc
02-git-basics/sections/remotes.asc
02-git-basics/sections/tagging.asc
02-git-basics/sections/aliases.asc

审校协作计划

所有认领任务的人必须都加QQ群:ProGit 2nd 翻译审校 463550926,想玩失联的不要来这儿玩

前言

之前我在 V2EX 上发布了 ProGit 2nd 中文版 翻译协作计划 - V2EX,招募到了很多人帮忙翻译,在此非常感谢大家的鼎力支持。

现状

截止到 20150811 11:02,现在还有 29 个章节等待审校,整体进度 68.4%。

工作量

但是翻译的内容需要经过审校才能进入主干,因为进入到主干的内容会被自动构建成各种格式的书籍,所以还是希望最终出来的东西质量能高一些。
首先是耗时的问题,比如 03-git-branching basic-branching-and-merging 这一小节,全文共 321 行,审校提出大概 50+ 意见,用时 70 分钟。现有翻译完成的章节共计 71 节,并且我认为每一小节最少要有三个人审校过才可以,这样才能保证质量,而不受不同的人的品味的影响。
假设审校一节平均用时 70 分钟的话,那么总体用时为 71 * 3 * 70 = 14910 分钟,合 248.5 小时,按一天 8 小时工作算合 31 个工作日,工作量其实还是蛮大的。

要求

因为接下来的工作不会有太多的打字,主要在于挑毛病,所以参与门槛很低;所以希望大家都可以去挑毛病,不管会不会英文,挑中文的毛病还是很简单的,只要你觉得语句不通顺、不理解什么意思、太啰嗦等问题,都可以直接在翻译那行下面评论。

参与方式

访问 审校协作计划 · Issue #160 · progit/progit2-zh 查看所有章节进度,所有未打勾且审校人员少于 3 人的建议认领,留言认领自己想要审校的章节,每个章节的限制工期是 3 天。
接着就可以点击对应的章节进入对应的 PR,点击 “Files Changed” 标签页,在你认为有问题的行点击左侧的 + 号按钮评论,可以使用 Markdown 语法引用你认为有问题的内容进行评论。
翻译者看到评论后可以与你进行讨论,有分歧的时候可以单独提交 Issue 共同解决,然后可以根据意见修改并重新提交。
此过程可能会重复多次,在三个审校者都审校完成并验收通过后,此翻译小节合并到主干。

审校者在审校完一遍时请 @ Pull Request 的译者,这样可以确定何时开始修改。

译者在接受审校者的意见进行修改并完成后,请 @ 对应的审校者,以便后续修正

必选交流群,所有参与审校的人员必须加入QQ群,现在发生了很多译者、审校者消失的情况,对修正非常不利。
ProGit 2nd 翻译审校 463550926
正常所有的交流都发生在对应的 PR 内,群只是用来紧急联络等等。

时间限制

每个任务都有一个 3 天的限制是有原因的:

  • 第一,项目需要尽快完成,这样才不会消磨大家的热情,只有完全翻译后才能申请将 Pro Git 官网网页版换成第二版的链接。
  • 第二,在任务未按时完成的话可以交给其他人继续,项目整体进度因而不会被某一小节拖住。
  • 第二,对每一个人也是有好处的,任务不会拖着不干,有压力才会有动力。

收获

所有参与翻译与审校的人员都会加入到 贡献者 列表中,让任何看到这本书的人都可以看到你的名字!
每个译者与审校者的工作量都会记录下来。

进度

所有打勾的表示章节已经进入主干,暂时不用审校;所有章节都需要三个以上的审校者,所以希望大家可以勇跃参与。

01-introduction

  • 1-introduction
  • about-version-control
  • history
  • basics
  • command-line
  • installing
  • first-time-setup @xinqiu 20150709 @robinwen 20150705 @ahlijin 20150709
  • help

02-git-basics

03-git-branching

04-git-server

05-distributed-git

06-github

07-git-tools

08-customizing-git

09-git-and-other-scms

10-git-internals

A-git-in-other-environments

B-embedding-git

C-git-commands

关于章节认领的时效问题

从 Progit 第二版英文版正式发布开始(大概是2014年11月份)我就开始关注本项目了,但是有很多人认领了并没有翻译,或者说是按时翻译;问题现在已经过去半年了,所以我觉得那个 章节翻译认领 · Issue #7 · progit/progit2-zh 已经失去时效了。

我现在的策略是以现在的版本为基础,跳过已翻译的章节,并按顺序依次翻译,然后将其提交到我自己所在的分支;在推送前我会拉取一下官方翻译库 progit/progit2-zh,手动进行一次拉取,并将自己的分支合并至官方库的 master 分支,如果合并冲突,我会去掉冲突的章节,新建一个分支,推送并提 Pull Request 到官方库。

同时我认为多个人翻译同一个章节并不会有问题,本来翻译这个东西讲究的就是信达雅,我认为翻译要经过好几轮:第一轮粗译、第二轮审校、第三轮审校,后翻译完成的人做审校的效果更好,因为对本章的英文原文了解地更深入,对中文也有自己的思考。

翻译 version 1 进度

按照 翻译计划 · Issue #54 · progit/progit2-zh 在此公开翻译进度

进度链接 Commits · networm/progit2-zh

进度更新形式
每次翻译完一节便会在此更新进度,方便大家了解实时情况。

有关合并
在完成全部翻译及第二版校对前,不进入主仓库。

这里列出的提交不包含已申请 Pull Request 的内容。

20150609 Update
这里更新的进度会包含开始与结束,方便大家追踪我的工作,我会翻译完一节再去下一下,按照阅读顺序来

提示:我这儿翻译的所有内容只有在 version 2 时才会进入 progit2-zh 官方分支

进度:(所有粗体的是我的进度)

  • 01-introduction
    • 1-introduction
    • about-version-control
    • history
    • basics
    • command-line
    • installing
    • first-time-setup
    • help
  • 02-git-basics
    • 1-git-basics
    • getting-a-repository
    • recording-changes
    • viewing-history
    • undoing
    • remotes
    • tagging
    • aliases
  • 03-git-branching
    • 1-git-branching
    • nutshell
    • basic-branching-and-merging
    • branch-management
    • workflows
    • remote-branches
    • rebasing
  • 04-git-server
    • 1-git-server
    • protocols
    • git-on-a-server
    • generating-ssh-key
    • setting-up-server
    • git-daemon
    • smart-http
    • gitweb
    • gitlab
    • hosted
  • 05-distributed-git
    • 1-distributed-git
    • distributed-workflows
    • contributing
    • maintaining
  • 06-github
    • 1-github
    • 1-setting-up-account
    • 2-contributing
    • 3-maintaining
    • 4-managing-organization
    • 5-scripting
  • 07-git-tools
    • 1-git-tools
    • revision-selection
    • interactive-staging
    • stashing-cleaning
    • signing
    • searching
    • rewriting-history
    • reset
    • advanced-merging
    • rerere
    • debugging
    • submodules
    • bundling
    • replace
    • credentials
  • 08-customizing-git
    • 1-customizing-git
    • config
    • attributes
    • hooks
    • policy
  • 09-git-and-other-scms
    • 1-git-and-other-scms
    • client-svn
    • client-hg
    • client-p4
    • client-tfs
    • import-svn
    • import-hg
    • import-p4
    • import-tfs
    • import-custom
  • 10-git-internals
    • 1-git-internals
    • plumbing-porcelain
    • objects
    • refs
    • packfiles
    • refspec
    • transfer-protocols
    • maintenance
    • environment
  • A-git-in-other-environments
    • 1-git-other-environments
    • guis
    • visualstudio
    • eclipse
    • bash
    • zsh
    • powershell
  • B-embedding-git
    • 1-embedding-git
    • command-line
    • libgit2
    • jgit
  • C-git-commands
    • 1-git-commands

附录 B 章俩单词求探讨翻译。

在附录 B 章中的 Libgit2 篇大量出现 binding 一词,我暂且翻译为“绑定”,不过总感觉还有更好的,求支招。
文末还出现了一次 bundle 大概意思应该差不多,但是为了区分它们,我将后者翻译为“附带”,也是想到了“adt-bundled”这个词。不过总是不知道为什么感觉怪怪的。。。
顺带,过十几个小时继续提 Pull Request ,包括 Libgit2 这一篇以及 JGit 的 一点 typo 和一些修改。
话说真的有个感觉写了下去就很难修改甚至想到的那一刻就没法再修改了。。。

04 protocols单词`Smart` `Dumb`翻译方法商讨

各位:

在04 章 protocols 一节里,有这么一段:

The newer version is often referred to as the “Smart” HTTP protocol and the older way as “Dumb” HTTP. We’ll cover the newer “smart” HTTP protocol first.

其中的Smart和Dump没有想到合适的译法,请大家一起商讨下。

contributing 应该如何翻译

引用 @networm 的话:
但是 contributing 这个不一定要翻译为贡献代码,因为 Github 不光是可以存放代码,其他领域的模型、图片、声音什么的都有很多存放在这儿,所以我的建议是单独提一个 Issue,来讨论一下这个问题。我个人觉得叫“贡献”就很好。

希望大家积极发表意见

正式版 翻译进度

下面是我整理的当前进度(20150611 SHA-1:57d83a594eb8c03cd10c04331076cd81aa818b4a)
每章的索引小节也包括在内,如果这一章所有小节的内容全部翻译完成,则会在这一章前打勾。

进度统一在这里管理,包括章节认领,每个人认领后都有一个截止日期,在截止日期后其他人都可任意认领。

同时将 @networm 的 v1 版本进度整合进来,这样方便大家查看整体进度。

01-introduction

  • 1-introduction
  • about-version-control
  • history
  • basics
  • command-line
  • installing
  • first-time-setup @networm v1
  • help

02-git-basics

03-git-branching

04-git-server

05-distributed-git

06-github

07-git-tools

08-customizing-git

09-git-and-other-scms

10-git-internals

A-git-in-other-environments

B-embedding-git

C-git-commands

  • 1-git-commands @banxi1988 20150620 PR

对"you"翻译成"您"的不解

我是看第一版然后找过来的,发现还没翻译完。看了一下翻译发现约定了将"you"翻译成"您",对此不解。
我知道"您"能表示礼貌,但在一本技术类的书籍/说明文档中通篇都是"您您您",读起来不觉得拗口难受吗?读者都是抱着学习的心态读书的,感觉更应该是"虚心请教",而不是感觉"被抬高"吧。我读过的工具书还真没见过通篇用尊称的(虽然读得不多)。建议用回"你",或者像繁体版本那样用"读者"(不过会没有用"你"那么亲切)。

如有不对,请见谅。

翻译参与方式

  1. 访问 正式版 翻译进度 留言来认领章节,认领的每一个章节的截止时间是 3 天,所以最好先认领一个章节,翻译完成后再认领其他章节。
  2. Fork progit/progit2-zh,然后 clone 到本地。如果 clone 到本地的速度实在是过慢,那么访问链接: http://pan.baidu.com/s/1sj3GTL7 密码: zz8q 下载我的版本,并且修改 .git/config 文件,如果不会修改的话再次 clone,然后将克隆目录内的 .git/config 文件拷出来覆盖这个文件。
  3. 新建对应章节的分支,在上面翻译并提交、推送。
  4. 到 Github 上发送 Pull Request,其他人审核、提出修改意见。
  5. 根据修改意见再次提交、推送到同一个分支,这时候不需要删除仓库或分支,其他人审核通过后合并入主干。

大家的主仓库尽量让 master 分支追踪官方的源,这样可以保持最新、减少冲突,设置方法如下:

git checkout master
git remote add upstream [email protected]:progit/progit2-zh.git
git fetch upstream
git branch --set-upstream-to=upstream/master master
git pull

这样之后每次就可以直接拉取了,要翻译新章节前进入 master 分支拉取一下,然后再新建分支:

git checkout master
git pull
git checkout -b chapter

大家尽量做到实时预览,可以用浏览器插件或者特别的编辑器:
Editing AsciiDoc with Live Preview | Asciidoctor

英文双引号是否需要替换为中文双引号

键盘中并不能直接输入英文的双引号,而且那的确是 `` 与 '',在 AsciiDoc 中转义显示为英文的双引号。

“Double quoted text”
Phrases enclosed with ``two grave accents to the left and two acute accents to the right'' are rendered in quotation marks.

AsciiDoc User Guide - 10.1. Quoted Text

具体一一个例子是:Update README.asc by wogong · Pull Request #91 · progit/progit2-zh

英文的双引号在中文的情况下显示没有留白,看起来并不太好看,见 Git - Git 基础 最下方的“索引”

大家可以讨论一下这个双引号到底要不要改?

章节翻译认领

翻译人员可以在这里追加自己想翻译的章节,以便别人选择。

01-introduction
1-introduction -- @Lax
sections/about-version-control -- @Lax
sections/basics -- @Lax
sections/command-line -- @shuaishuai
sections/first-time-setup -- @Lax
sections/help -- @Lax
sections/history -- @Lax
sections/installing -- @Lax

02-git-basics
1-git-basics -- @alamier
sections/aliases -- @alamier / @tonghuix
sections/getting-a-repository -- @alamier
sections/recording-changes -- @alamier
sections/remotes -- @alamier / @tonghuix
sections/tagging -- @alamier / @tonghuix
sections/undoing -- @alamier / @tonghuix
sections/viewing-history -- @alamier / @tonghuix

03-git-branching
1-git-branching -- @jun995
sections/basic-branching-and-merging -- @jun995
sections/branch-management -- @jun995
sections/nutshell -- @jun995
sections/rebasing -- @shuaishuai
sections/remote-branches -- @jun995
sections/workflows -- @jun995

04-git-server
1-git-server
sections/generating-ssh-key
sections/git-daemon
sections/git-on-a-server
sections/gitlab
sections/gitweb
sections/hosted
sections/protocols
sections/setting-up-server
sections/smart-http

05-distributed-git
1-distributed-git -- @Qunero
sections/contributing -- @Qunero
sections/distributed-workflows -- @Qunero
sections/maintaining -- @Qunero

06-github
1-github -- @devbean
sections/1-setting-up-account -- @devbean
sections/2-contributing -- @devbean
sections/3-maintaining -- @devbean
sections/4-managing-organization -- @devbean
sections/5-scripting -- @devbean

07-git-tools
1-git-tools -- @leo108
sections/advanced-merging -- @leo108
sections/bundling -- @leo108
sections/credentials -- @leo108
sections/debugging -- @leo108
sections/interactive-staging -- @leo108
sections/notes -- @leo108
sections/replace -- @leo108
sections/rerere -- @leo108
sections/reset -- @leo108
sections/revision-selection -- @leo108
sections/rewriting-history -- @leo108
sections/searching -- @leo108
sections/signing -- @leo108
sections/stashing-cleaning -- @leo108
sections/submodules -- @leo108
sections/subtree-merges -- @leo108

08-customizing-git -- @datawolf
1-customizing-git -- @datawolf
sections/attributes -- @datawolf
sections/config -- @datawolf
sections/hooks -- @datawolf
sections/policy -- @datawolf

09-git-and-other-scms
1-git-and-other-scms
sections/client-hg
sections/client-p4
sections/client-svn
sections/client-tfs
sections/import-custom
sections/import-hg
sections/import-p4
sections/import-svn
sections/import-tfs

10-git-internals
1-git-internals
sections/environment
sections/maintenance
sections/objects
sections/packfiles
sections/plumbing-porcelain
sections/refs
sections/refspec
sections/transfer-protocols

A-git-in-other-environments @shuaishuai
1-git-other-environments
sections/bash
sections/eclipse
sections/guis
sections/powershell
sections/visualstudio
sections/zsh

B-embedding-git @Geno1024
1-embedding-git
sections/command-line
sections/jgit
sections/libgit2

C-git-commands @kuuyee
1-git-commands @kuuyee

请大家在提交 PR 前自我审查一下

大家在翻译前一定要先将第一版中对应的章节阅读一遍
尽量保证翻译的质量,特别是一些计算机术语。

在提交前请多过几遍中英文的差别,确定翻译是否正确
有些英文的关键内容没翻译出来,有些缺失,在检查时可以轻松发现。

在提交前一定要在预览中仔细审查,找出所有可见的问题。
大家必须做到实时预览,可以用浏览器插件或者特别的编辑器:
Editing AsciiDoc with Live Preview | Asciidoctor

预览时不要预览对应的文件,而是要预览父目录中的 asc 文件,这样图片才可以显示出来。
例如你要修改 "\book\03-git-branching\sections\nutshell.asc",你需要预览 "\book\03-git-branching\1-git-branching.asc"

请大家在提交 PR 前努力修正各种非中文标点错误、英文前后留空格、英文专有名词大小写拼写等等常见问题。

提交的 PR 命名要规范
如你翻译的文件是 book/04-git-server/sections/gitweb.asc
那么标题就是是 Translate 04-git-server gitweb
规则是 Translate 加上 将 book sections .asc 去掉的路径

一个 Pull Request 中只能含有一个章节
含有多个章节的请自行拆分为不同的分支,分别发送 Pull Request。

因为审查也非常耗费时间,一个 300 行的 Translated 03-git-branch/sections/basic-branch-and-merging by archermind · Pull Request #105 · progit/progit2-zh 就花费了我 70 分钟审查,如果只是因为一些小毛病反反复复修改的话,浪费的是大家的时间。

有任何问题欢迎提交 Issue。

02-git-basics/sections/recording-changes.asc -- Removing Files

Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area.

另外一种情况是,我们想把文件从 Git 仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录中。

上述标粗体的部分从原文中看不出类似的意思,是否需要修改?

需要制定翻译用“术语表”

浏览既有的Issues的时候发现,大家对很多Git术语尚没有形成统一的认识。我个人认为,按照一般翻译规则,还是需要一张“术语表”。而且已翻译的版本也是根据翻译者水平,各有理解。

我个人还是比较推崇蒋鑫写的《Git权威指南》一书里的翻译,或者后来的第二本《Got Github》。比如他对一些常用的术语有一些翻译:

Frok - 派生
Pull - 拉取
Push - 推送
Rebase - 变基
Pull Request - 合并请求

同时蒋鑫也是Git的贡献者之一,因此他的中文翻译带有一定权威性,因此我建议是否可以将蒋鑫翻译的一些术语提出来,作为术语表供社区翻译者参考?

关于 “shortname of the Git repository URL” 的译法

目前的 shortname 译作“缩写”,个人感觉“别名”、“短名”或“简写”比较好。

首先“URL的缩写”没办法定义,因为你完全还可以取一个新的名字,可以不是URL中的任何字符串。其次还有 local path 的说法,甚至还可以设置独立的 fetch URL 和 push URL。例如:

[remote "origin"]
    url = ../my/project.git
    pushurl = https://github.com/My/Project.git
    fetch = +refs/heads/*:refs/remotes/origin/*

其实上面这三条信息合起来才叫一个 remote repository,就这点来说“缩写”也是不合适的,因为是给它取的一个名字。

各位有何高见?

10-git-internals transfer-protocols 中 SSH 小节的例子是否有问题?

例子如下:

[source,console]
----
$ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status \
    delete-refs side-band-64k quiet ofs-delta \
agent=git/2:2.1.1+github-607-gfba4028 delete-refs
003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic
0000
----

0x005b = 91,应为本行长度,即 91 字节,但是

005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status \
    delete-refs side-band-64k quiet ofs-delta \
agent=git/2:2.1.1+github-607-gfba4028 delete-refs

的长度为 164,并不是 91。

相应的

003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic

的长度为 57,不等于 0x3e,即 62。


于是我自己做测试

ssh -x [email protected] "git-receive-pack 'zwpaper/progit2-zh'"
00ca82d2b8601d253dd1df545d66543d12adba06f73c refs/heads/06-github-4-managing-orgreport-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2:2.4.0~peff-faster-fetch-pruning-1043-gc837c96
0053f6a3af3bcd0da7f51393a4d746b72346aa12b886 refs/heads/10-git-internals-packfiles
005e83cc8df409dd347e173bcdd9c630bf245185f3f2 refs/heads/double_quote_mark_in_translation_note
003faf9ee732e6977aa621e30c8ceb152375f0911346 refs/heads/master
0057be6fc3f4ce49ed58c5e6e5fd778796bcdec70461 refs/heads/smart_dumb_in_TRANSLATION_NOTE
0000Connection to github.com closed by remote host.
00ca82d2b8601d253dd1df545d66543d12adba06f73c refs/heads/06-github-4-managing-orgreport-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2:2.4.0~peff-faster-fetch-pruning-1043-gc837c96

第一行,长度为200,0xca = 202。
相应的其它各行也是差两个字节。
我理解可能是 \n\r

但也不应该是书上的例子,不知道谁能说明一下。

一些中文与英文的语序不同的要怎么处理?

刚刚看了一下 06-github4-managing-organization ,其中第 6 行:
类似于个人帐户,组织帐户提供一个命名空间用于存放所拥有的项目,但是也有很多不同的地方。
对应的原文是:
Like personal accounts, Organizational accounts have a namespace where all their projects exist, but many other things are different.
可以看到这个中文翻译使用了原文的英文语序。
我不知道这样是否可以,就是我们在翻译的时候,使用中文的语序。
但是对于例如 where 引导的从句来说,在翻译时将它们放在从句主语之前,这样有时候会使句式变得看起来复杂或者甚至难以理解。
我负责的翻译部分是 B-Embedding-git 整章,遇到这种比较复杂的句式(例如:主语 + 谓语 + 宾语,从句宾语 + 从句谓语 + 从句主语 + 从句宾语补足语),我习惯于把它们调换成中文语序,但是这种调换很复杂,很奇怪,还容易出错,即使不出错,出来的句子也是奇奇怪怪的。
所以,大家觉得,要用哪个?或者介于两者之间?

图片注解文字末尾是否要句号?

现在有三种情况

  • 没有句号
  • 中文句号
  • 英文句号

我认为英文句号肯定是有问题的,而前两种中应该统一意见,不知道大家有什么见解?

有关反引号两侧的空格

反引号一般用于有特殊格式的代码片段,英文原文中反引号两侧均有空格,个人认为,中文翻译中,反引号两侧的空格应该删除,以保持译文的紧凑。由于生成的代码片段带有特殊的格式,删除了空格也不会引起混乱。

申请作为协作者

到现在为止我已初步翻译完成 18 篇文章,还会按照计划继续下去。我的翻译进度 翻译 version 1 进度 · Issue #55 · progit/progit2-zh 里面有整张表,所有粗体的是我初步翻译的。
我之前已经在 翻译计划 · Issue #54 · progit/progit2-zh 说明了我的计划,不过有一点我忘说了,我会一直全职工作来翻译,直到翻译彻底完成。所以你们会有我翻译速度度的感觉,因为我一白天都在翻译,有时晚上也在翻译。。。
所以最近一直全天挂在 Github 上,时间充裕,可以辅助管理项目翻译。

之前我也曾买过一本《Git 权威指南》,也在网上看过很多教程,但是我认为本书是新手入门最好的书籍,没有之一。
我认为翻译人员流程有些混乱,原有的章节认领也没有更新,我认为这不利于尽快翻译完本书。

想要做以下事情:
. 更新原有章节认领 Issue,去除未参加的人员
. 统一所有章节认领到同一个 Issue
. 认领章节时增加截止日期,别人在截止日期后可以重新认领
. 加快审核 Pull Request 的速度,尽量不干扰其他人翻译

Github Organization 中团队的 @ 功能部分翻译求助

Github organization 中团队的 @ 功能,在所有成员都订阅了这个话题之后会怎么样呢?
也就是文中的后半句,

Additionally, team @mentions (such as @acmecorp/frontend) work much the same as they do with individual users, except that all members of the team are then subscribed to the thread.

中的

except that all members of the team are then subscribed to the thread.

应该怎么翻译比较好呢?

补充一下,这是 06-github-4-managing-organization 部分。

抱歉,突然发现是理解偏差。

编译的时候出现了问题,bundle install failed...,懂ruby的同学请帮忙confirm一下

本来是打算看 issue #48 的,结果在使用bundle的时候就出现了如下错误,但是都找到了解决方法,现在请大家一起帮忙看下,我完全不懂 ruby之类的东西,以下方法全部google得来。

. ruby官方的源貌似不太问题,执行 bundle install 的时候,常常报网络异常。

==> 参考解决方法 http://ruby.taobao.org/[] 将官方源换成 taobao提供的镜像

. kindlegen 这个工具在 bundle install 会报错,progit 其他repo也遇到类似问题

==> 类似问题 tdtds/kindlegen#12
==> 参考解决方案 progit/progit2#215

关于章节标题内的术语注解问题

此 issue 旨在讨论章节标题内的术语注解问题。

一般而言,在原文中出现专业术语时,译者倾向于对其作一注解,即在译文后紧跟一括弧,内注明原文单词,以助读者理解。

《Pro Git》第一版简体中文翻译里对这个问题的处理,稍显混乱。

其中,第六章与第九章尤为突出:

v1-06
v1-09

可以看到,有些小节标题作了英文注解,有些只保留中文,有些直接保留了英文原文。

我们希望对此作改进,至少做到统一。


一种意见认为,作为标题,有必要快速向读者阐明概念;因此,(如有必要)在标题内即可加入英文注解。举例:

原文

1  [[_plumbing_porcelain]]
2  === Plumbing and Porcelain
3
4  ...(ignored)...
5  These commands are generally referred to as ``plumbing'' commands, and the more user-friendly commands are called ``porcelain'' commands.
6  ...(ignored)...

译文:

1  [[_plumbing_porcelain]]
2  === 底层命令(plumbing)和高层命令(porcelain)
3
4  ...(ignored)...
5  这部分命令一般被称作“底层”命令,而那些更友好的命令则被称作“高层”命令。
6  ...(ignored)...

其中,line 5 是正文中首次出现 plumbing 和 porcelain 处,下同。


另一种意见认为,章节标题约定不作英文注解,只出现中文字样;如有必要,在正文中第一次出现处作注解。举例:

原文:
如上例。

译文:

1  [[_plumbing_porcelain]]
2  === 底层命令和高层命令
3
4  ...(ignored)...
5  这部分命令一般被称作“底层(plumbing)”命令,而那些更友好的命令则被称作“高层(porcelain)”命令。
6  ...(ignored)...

目前可以统一的是,如若已作了注解,则以第一次出现处为准,不应重复


请各位不吝抒发意见,希望最终能达成共识,并作相应约定。个人觉得有助于项目内部的标准化。谢谢。

注:问题背景与出处见 #63 (diff)

repository 应该翻译成什么?

现在在 TRANSLATION_NOTES 中“repository”被翻译为“版本库”。
我感觉翻译为“仓库”更好一些,更简洁一些;另外《ProGit》第一版也是使用的“仓库”。

大家有什么看法?

翻译计划

说来有些惭愧,《ProGit》之前读过第一版,后来2014年11月《ProGit》第二版正式发布后用了不到一个月的时间读完,就想要把这本书翻译一下,但是还是因为太懒了,拖到现在也没翻译。
最近有一些空闲时间,想要将其全部翻译完成,方便后来人,说实话,第二版比第一版好很多,有很多地方讲得比地一版细致得多,而且多讲了很多内容,比如说如何协作。

也就是说我会翻译所有章节,所以 @ 了所有认领章节的人。

初步计划:
version1:基于现有版本,翻译完剩余所有未翻译的部分,此为初译。
version2:同时参考英文版最新版与中文版第一版,校对内容,同时统一整理所有用词,例如“您”“你”问题。
version3:开始润色,将长句打断成短句,尽量使其信达雅。

用时:
version1:按照每天 3-5 篇的速度,刚刚统计的结果是还剩 58 篇,大概需要 20 天。
version2:初步预估,10 天。
version3:这个我认为需要协作,不确定天数。而且这一部分可作日后维护更新的内容。

问题:
什么时候进入主版本?
第一版翻译过程中;第一版翻译完成;第二版处理完成;第三版处理完成;应选择哪个阶段进入主版本?

用词问题在哪个阶段改
建议统一放到第二版处理,翻译的时候心无杂念比较好。

不知道大家有什么建议意见呢?

申请成为 reviewer

鉴于现在的任务分配情况差不多了,剩下的内容我也并不擅长。粗略看过本书译文之后,发现语句的通顺度尚不如意,因此自荐申请成为审校者,为已经翻译过的内容修改润色。

不过作为统领全书行文风格和术语标准的审校者,至少要具备一定的翻译经验。本人是 Go-zh 项目的翻译和负责人,代表译文有 实效 Go 编程Go 编程语言规范 (旧译版,新版仍未完成)和 包文档 等官方文档,以及 命名的学问反射法则Go 切片:用法和本质 等官方博文,偶尔也去 MDN 和 Wiki 上译些文档。

因此,本人希望贡献自己的力量,让 Pro Git 第二版更加严谨细致,简明易读,也能让这本自己很喜欢的书以最好的状态面世。

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.