From 93a0adef15e184330263dc30dea7345b9e3e1cf6 Mon Sep 17 00:00:00 2001
From: CanYellow <hc_hc_hc@126.com>
Date: Sat, 17 Dec 2022 16:35:05 +0800
Subject: [PATCH 1/2] Third Translation

---
 ...­�ï¸� Write documentation like you develop code.md | 53 ++++++++++---------
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/sources/talk/20221028.1 ���� Write documentation like you develop code.md b/sources/talk/20221028.1 ���� Write documentation like you develop code.md
index 1aea7321f7..9c373f96bd 100644
--- a/sources/talk/20221028.1 ���� Write documentation like you develop code.md	
+++ b/sources/talk/20221028.1 ���� Write documentation like you develop code.md	
@@ -7,51 +7,52 @@
 [#]: publisher: " "
 [#]: url: " "
 
-Write documentation like you develop code
+�代�开�一样撰写文档
 ======
 
-Don't want documentation to be an afterthought? Try a new approach.
+�想让书写滞�于你的�考？或许你该�试一下全新的写作方�。
 
-Many engineers and craftspeople are particular about their tools. To do a job well, you need the best tools and the skills to use them. The best tools in software development can be very powerful when applied to other kinds of digital creation. The [Docs as Code][1] approach is a great example. Docs as Code entails writing documentation using the same tools and workflows used for developing code. Proponents of Docs as Code report that this method leads to better documentation while easing the workload of the people who write it.
+很多工程师与手工艺者都对他们使用的工具有特别的�求。为了顺利的完�工作，你需�最好的工具和使用它们的技巧。软件开�中最好的工具在应用到其他的数字创作领域中也�以是很强大的。[Docs as Code][1] (译注：代�化文档)的方�就是很好的例�。Doc as Code �味者使用与代�开�相�的工具与工作��撰写文档。Doc as Code 的支�者认为这样的方��以在�低作者的工作符负�的�时��更好的文档结构。
 
-### Text formats and source control
+### 文本格�与�文件控制
 
-The most significant adjustment when moving from a more traditional documentation platform to the Docs as Code approach is that the content is stored in a text-based markup format. This change makes all the tools for text-based materials available for generating documentation. Whether you choose [DocBook][2], [Markdown][3], or another markup language, the transition from using just one tool to using a standard format and a variety of tools is a big change.
+从传统的写作平�切�到 Docs as Code 方�时，最主�的调整是写作内容�存在基于文本的标记格�中。这一转�使得基于纯文本�料的工具都适用于文档写作。当你选择 [DocBook][2]， [Markdown][3] 或者其他的标记语言时，从�使用一�工具到使用一�标准格���多�工具是一�巨大的转�。
 
-Finding tools that support your workflow is really important. Many developers use their [coding editors][4] when working on Docs as Code projects. Since they are already advanced-level users with that tool, it works well for them. Finding tooling that fits the other professionals on the team, such as technical writers, editors, information architects, and documentation product owners, may take more effort. A few options to consider:
+找到支�你的工作�程的工具是�常��的。在 Docs as Code 项目中，很多开�者使用他们的 [代�编辑器][4]。考虑到他们已�是这些工具的高阶用户，一切都很顺利。而找到适�团队里适�其他专业从业者，比如技术撰稿�编辑�信�架构师和文档产�责任人，的工具�能需�一番努力。这里有一些选项�兹�考：
 
-- One of the many [good markdown editors][5] available
-- Coding editors with good preview tools, which make them approachable for non-coders
-- The web interfaces of popular Git hosting services, especially for occasional contributors
+- ��[优秀的 Markdown 编辑器][5]之一是�行的
+- 附带良好的预览工具的代�编辑器�能更适��程�员
+- �行的 Git 托管�务的网页界�尤其适用于�尔有需�的贡献者
 
-Once content is safely in a markup format, the project can use source control such as [Git][6], an open source tool with many more features than most documentation platforms can claim:
+一旦内容以标记语言的格�安全�存就�以使用版本控制进行管�，比如 [Git][6]。Git 相比大多数文档平�具有更多的功能：
 
-- A clear and detailed version history of who changed what and when. If you have good commit message culture, you may even be able to learn why the change was made.
-- Easy parallel change processes. Working in branches in Git means everyone can make all the changes they want to and combine them at the end.
-- Advanced collaboration and review tooling. All the source-control platforms are designed to review each change in detail and have as much discussion as needed until everyone is confident that the change can go ahead.
-- Automated quality checks such as spellchecking and link checking. This saves time and catches errors that might otherwise be missed.
+- 清晰详细的文档版本历�：�在什么时候改�了什么。
+- 简明的并行修改过程支�。在 Git 中使用分支工作�味�任何人�以�出他们想�的任何改�并在最��并所�的更改。
+- 高级的�作与审查工具。所有的�代�管�平�都设计支�评审�一�细节�更并在足够的讨论�使�个人都确信改��以继续的�程。
+- 自动质�检查，比如拼写检查和链接检查。这�仅节�了时间，而且�以�现以�无法�现的错误。
 
-Source control has many benefits. Just keep in mind that if you're new to source control, it has a learning curve. There are some excellent [learning resources][7] and [articles for writers][8] that can help. You can also let your curious documentarians find the learning materials that work for them rather than asking your engineers to teach them. (Ask me how I learned this—the hard way of course!)
+�代�管�有很多优点。但�记�，如果你准备入门�代�管�，它有一定的学习曲线。这是一些有助于入门的优秀的[学习资�][7]和[作者文章][8]。你也�以让具有好奇心的文档作者自行寻找对他们有用的学习�料，而�是请你的工程师�培训他们。(探寻他人的学习历程是最困难的学习方�)
 
-### Pull requests and review cycles
+### 拉�请求和评审循环
 
-All source-control platforms are designed around the concept of pull requests, sometimes also called merge requests. Someone, or some team, puts together a set of changes and then requests that the changes are pulled into the main project. In many ways, working with many changes at once is easier in documentation than in code. Changing one article in one place in documentation has fewer side effects than when you change code and find that there were several other sections depending on it.
 
-The most powerful collaboration tool is the [diff][9], which shows the difference between old and new versions in a way that's easy to follow. There are many versions of this tool available to make the comparison view easier to look at: side-by-side, inline, or even as rendered markdown rather than just text. Each team member can use the tool or tools that work best for them. For example, the web view is commonly used to look at a small change, but for something bigger I would want to look at it locally using `vimdiff` or [Meld][10].
+所有的�代�管�平�都围绕拉�请求这一概念设计，这有时也称为�并请求。有时候，�些团队先将一系列改�整�到一起然��主项目�起�求修改被拉�的请求。�过从许多方��说，在文档中一次处�多个�更比在代�中更容易。改�文档中�处的一篇文章比之更改代�并找出有哪些地方�赖它具有更�的副作用。
 
-Review comments can be added to the change as a whole or to individual lines in the proposed change. Some projects adopt a maximum line length, called a hard wrap, or start each sentence on a new line to make it easier to attach comments to specific parts of a block of text. Further changes and comments can be added until the review process is complete and the change is accepted. Since the pull requests are shown in a queue on the repository for the project, this is a good way to show what's in progress and what needs review attention. The tools make it easy for reviewers to add their thoughts. In particular, if you are working with technical audiences it can be easier to get reviews from these folks via the tools they use daily.
+最强大的�作工具是 [diff][9]，它�以通过一个易于察觉的方�展示旧版本与新版本之间的差异。该工具有多���的版本�使得比较视图更易于查看：��模��行内模�，甚至是渲染�的 Markdown 模�。团队中的�一个�员都�以选择最适�他们的版本。举例而言，网页视图通常用于查看细微�更，而对于更大的�更，我习惯于使用 `vimdiff` 或 [Meld][10] 在本地�览。
 
-### Continuous integration and deployment
+检查的注释�以整体�交到�更中，也�以�交到指定�更中的个别行中。一些项目�制了行的最大长度，�硬�行，或者一行一�，以使得�文本的特定的部分添加注释更加容易。进一步的�更与注释�以在检查完�接��更时添加。由于拉�请求在项目仓库以队列形�展示，这是很好的方��展示目�正在进行的任务以�需�进行检查�作的任务。diff 工具使得评审人员更方便地加入他们的�考。尤其是你在与技术�众工作时，你�以通过他们日常使用的工具获得�自他们的评论。
 
-Having the source of your documentation available in plain text has many benefits, such as making it easy to find every occurrence of something that needs changing and using existing tools such as [wc][11], [grep][12], or `tree` to work with potentially large document sets. When you combine this with a source-control platform, even more existing tools become available, and they're all open source.
+### �续集�与部署
 
-One big workflow improvement is the ability to have continuous deployment in place. This simply means that when a pull request is merged into the main project, the project is immediately and automatically deployed. If the change is good enough to be accepted into the project, it is also good enough to be live on the documentation site, helping your readers. Typically, continuous deployment is set up with either a separate automation server, such as [Jenkins][13], or [Git Hooks][14]. Either way, the text-based markup is combined with the Docs as Code platform (usually a static site generator such as [Hugo][15] or [Sphinx][16]) to produce the documentation website, which is then deployed.
+以纯文本形�拥有你的文档的�代�有很多益处，你�以轻易找到�次需�修改的�置，你�以使用现有的诸如 [wc][11]�[grep][12]或 `tree` 之类的工具在潜在的大型文档集中工作。当你将这些与�代�管�平�结�起�之�，你�能获得更多的�用工具，并且它们都是开�的。
 
-The same automation can be used before deployment to add some excellent checks to the pull requests before they are merged. On a coding project, it's common to run code linters, tests, and other quality checks that a machine can do itself. Documentation projects can get the same treatment, with tools like [Vale][17] to do prose linting and check for correct heading styles, spellings, and so on. It's also useful to add other tools here, such as a link checker to make sure all the links go somewhere valid.
+�一个工作�程上的巨大��是�续部署的能力。简��说，这�味�，�当一个拉�请求被�并到主项目中，项目�以直接自动化部署到�。如果�更好到足以接收进项目中，他�时�以在文档页�中实时更新，从而帮助到你的读者。典型情况下，�续部署是�置在任�一�分离的自动化�务器上的，比如 [Jenkins][13] 或者 [Git Hooks][14]。�论哪�方�，基于文本的标记语言与 Doc as Code 平�(通常是��网页生�器，比如 [Hugo][15] 或 [Sphinx][16])结��生�文档网站，然�自动部署。
 
-### Code tools for docs workflows
+在部署之�，�样的自动化�程�以被用于对将��并的拉�请求进行检查。在一个编程项目中，通过计算机自行进行代�检查�代�测试和其他的质�检查已�习以为常。通过类似 [Vale][17] 之类的工具进行文本检查�文档项目也�以�样对待，你也�以添加其他的工具，比如添加一个链接检查器�确�文中所有的链接都是有效的。
 
-The tools known and loved by engineers are very good tools, but they are useful for all sorts of other projects too. For documentation, they contribute valuable efficiency, especially when you need your documentation to be moving at the same speed as your development teams. All the tools discussed here are open source, so you can try them for yourself, deploy them for a huge global team, or anything in between. May your docs process be as smooth as any code process.
+### 用于文档�程的代�工具
+
+被工程师们熟知并喜爱的工具都是�常好的工具，它们�时也�以用于其他类型的项目中。在文档项目中，它们��了�贵的效率，尤其是当你希望你的文档与你的团队�步推进的时候。上�讨论到的所有工具都是开�的，你�以亲自�试，为大型全�团队部署他们，亦或者介于两者之间，最终使你的�文过程和编程过程一样顺畅。
 
 --------------------------------------------------------------------------------
 
@@ -59,7 +60,7 @@ via: https://opensource.com/article/22/10/docs-as-code
 
 作者：[Lorna Mitchell][a]
 选题：[lkxed][b]
-译者：[译者ID](https://github.com/译者ID)
+译者：[CanYellow](https://github.com/CanYellow)
 校对：[校对者ID](https://github.com/校对者ID)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出

From dee4803e9dee1a51c3b4c52f9169264b4f66ee76 Mon Sep 17 00:00:00 2001
From: CanYellow <hc_hc_hc@126.com>
Date: Sat, 17 Dec 2022 16:46:37 +0800
Subject: [PATCH 2/2] move

---
 .../20221028.1 ���� Write documentation like you develop code.md  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename {sources => translated}/talk/20221028.1 ���� Write documentation like you develop code.md (100%)

diff --git a/sources/talk/20221028.1 ���� Write documentation like you develop code.md b/translated/talk/20221028.1 ���� Write documentation like you develop code.md
similarity index 100%
rename from sources/talk/20221028.1 ���� Write documentation like you develop code.md
rename to translated/talk/20221028.1 ���� Write documentation like you develop code.md