어떻게 Elasticsearch6.x Reference 중국어 버전 공헌 번역/검토

Elasticsearch6.x Reference 중국어판 번역 업무는 이미 공식적인 권한을 수여받았고 번역 중입니다. 관심이 있으면 함께 Elasticsearch 중국어 커뮤니티에 자신의 역량을 기여할 수 있습니다. 최종 번역이 완료되면 중국어 버전은 Elastic 홈페이지에 동기화됩니다.
번역 절차는 아래와 같습니다, 구체적으로 보십시오.https://github.com/elasticsearch-cn/elasticsearch/wiki.

Prerequisites

Github Account

Forked version of Elasticsearch

Write info https://yiqixie.com/s/home/fcADV-sYeZE8RITYnTtMztGpJ

Prepare translation

Fork the book repository to your own repository

login and goto https://github.com/elasticsearch-cn/elasticsearch

click  Fork and choose your own personal account

Clone the book repository

git clone [email protected]:${USER_NAME}/elasticsearch.git

Add upstream to your repository

git remote add upstream https://github.com/elasticsearch-cn/elasticsearch.git

Add the “PullRequest” Git alias (macro) to your Git config edit  .git/config  and add the following lines:

방법 1:

git config --global alias.pr '!f() { git fetch upstream pull/$1/head:pr/$1; }; f'

git config --global alias.review '!f() { git checkout cn && git pr $1 && git checkout cn && git pull --rebase upstream cn && git checkout pr/$1 && git rebase cn;}; f'

방법 2:[alias]   pr = "!f() { git fetch upstream pull/$1/head:pr/$1; }; f" [alias]   review = "!f() { git checkout cn && git pr $1 && git checkout cn && git pull --rebase upstream cn && git checkout pr/$1 && git rebase cn;}; f"

Catch up with latest updates:

* git checkout cn * git pull --rebase upstream cn # upstream should point to elasticsearch-cn/elasticsearch.git.git

당신이 현재 번역하고 있는 장과 절을 확정하세요. excel 안에 장만 굵게 나누면 원칙은 한 사람이 한 장을 책임지는 것입니다. 절대 틀리지 마세요. 먼저 당신의 임무 상태를 갱신하세요

Create a chapter branch -- Rule #1: Never work on master or cn!

* git checkout -b chapter/chapter1/getting-started.asciidoc for chapter #1 branch and the first doc in this chapter

Translate

Review locally ( https://github.com/elastic/docs )

git clone [email protected]:elastic/docs.git
./docs/build_docs.pl --doc getting-started.asciidoc --out es-book-output/--open --chunk=1

Warning The output/dir/will be deleted and recreated, so don’t point it at a directory with contents that you want to keep.

Send pull request(elasticsearch-cn:cn from ${USER_NAME}:${USER_BRANCH})

Wait for review( find some guy review for you)

Review and modify

Wait for merge

Merge to cn branch

Resource

문법, 컴파일 도구:https://github.com/elastic/docs

설명:https://www.elastic.co/blog/the-fine-manual

문서 컴파일 도구:http://asciidoctor.org/docs/install-toolchain/

mac 다음 문서 컴파일 도구:http://asciidoctor.org/docs/install-asciidoctor-macosx/

Chrome extension: Asciidoctor

Note about squashing commits

You should also **never squash commits during the review** process at Github, since that forces the reviewer to evaluate
hundreds of lines of code in a new, squashed commits, instead of just the changes in specific commits. In other words, during the review process, keep adding and pushing commits, and after the review is done, perform a final rebase/squash/reword/etc on the branch, before merging it.
```

git checkout your-chapter/chapters git merge-base your-chapter/chapters cn git rebase -i sha1 git rebase cn ```

Prepare push to your repo

* `git checkout cn`            # Go back to cn to get latest commits
* `git pull --rebase upstream cn` # Rebase the cn
* `git checkout chapter/chapter1`    # Go back to the translation branch
* `git rebase cn`            # Rebase feature branch using cn
* `git push origin chapter/chapter1` # Push to your remote

If you already pushed to your remote, and make changes to the history (like with rebase / squash), your push will be denied. In that case, you need to use the `--force` switch to overwrite the remote history:

```
git push origin chapter/chapter1 -f # Force push to your remote
```

Remember that it’s perfectly fine to overwrite your own history (ie. your fork, or private branch), but you must not (infact never!) overwrite shared history (ie. master, the cn branch, etc). In other words, force push to your fork or branch, but never to branches which you share with other developers and the world.

Prepare a pull-request for your fix

* Go to your Github account and open a pull request for the the branch you just committed and pushed.
  *  ， ， pr，（ + + ） ：`chapter1_part1: /getting-started.asciidoc`
  *  （ ） PR：`chapter2_part1: /setup/install.asciidoc`
* The pull-request will get an ID, which is the last number in the github URL:
    * https://github.com/elasticsearch-cn/elasticsearch/pull/2985

Fetch a PR and review locally

* If you are a reviewer you can pull the pull-request by running (2985 is your pr id):
    * `git review 2985`
    * or manually fetch PR
      * `git pr 2985` # Create a branch named “pr/2985” in your working copy (local)
      * `git checkout cn && git pull --rebase upstream cn` # Get latest changes
      * `git checkout pr/2985 && git rebase cn` # Rebase to latest cn
* Do your checking and review, please use web browser to view the final result
   `./docs/build_docs.pl --doc   getting-started.asciidoc  --out es-book-output/ --open --chunk=1`
* Go to pull thread and comment "LGTM"

* [DONT! do this now]`git checkout cn && git merge pr/2895` # Merge the commits into cn * [DONT! do this now]`git push upstream cn` # Push cn to the main repo 
* Make sure to add the proper labels to the github issue/PR: see following section * Clean local branch `git branch -D pr/2985` * Done

Labelling pull requests & issues

  * `to be review` `review`  `to be merge` `done`

Translation Reviews

* Everybody does translation reviews.
* Everybody's translation gets reviewed before being merged.
* You should find a reviewer for your PR.
* You have to satisfy your reviewer.

As the reviewee:

When your translation is ready for review (which includes updating the documentation and modify), create a pull request on GitHub and add the `to be review` label.

Then find somebody to review your translation and assign the PR to that person.  You can find people who are interested in your PR touches in the [spreadsheet] or from QQ group: 109764489 .

Generally, most PRs should be reviewed by at least two other people:
* For the first review, try to choose a less experienced person so that they have a chance to learn.
* Once you have satisfied the first reviewer, find somebody with more experience in the area to give the final LGTM (looks good to me).
* Try not to choose the same people all the time - spread the load.
* If a reviewer takes too long, feel free to bug them or to choose a different reviewer, but it is up to you to get your PR reviewed.

Once you have two LGTM, go ahead and label your PR: 

Label your PR with `to be merged`, and with the chapter number (eg `chapter1`, `chaper2`, `chapter1_part1`)

For smaller PRs, a single review may be sufficient, but if you are not 100% sure, then make sure you get a second review.

As the reviewer:

If you have any questions, or suggestions, leave comments on the PR, remove the `review` label and unassign yourself.  It is up to the reviewee to make the appropriate corrections or to explain their choices to your satisfaction.

As part of the review, make sure that the PR is properly labelled according to the labelling section above.

Once you are satisfied, leave a LGTM (looks good to me) comment and, again, remove the `review` label and unassign your