Improve based on review comments

Author: node

translation/zh/patterns/extensions-for-sustainable-growth.md

@@ -57,15 +57,15 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 1. **易于创建：** 为了获得社区参与，扩展需要易于创建。
    - 创建一个初始扩展的代码库模板，作为新扩展的起点。这允许扩展在新代码库中添加新功能，与核心项目分开。该模板应提供与主代码库相同的模块化结构，并包含打包和发布扩展的框架。
    - 确保随着主代码库的变更，模板得到良好维护。主代码库维护人员负责更新模板以确保其与主项目兼容。遵循良好的版本控制约定，例如 [semver](https://semver.org/)，可以使这更容易遵循。
-   - 进一步建议主代码库维护者提供相关介绍，以指导如何在新版本发布时基于旧版本模板更新扩展。
+   - 建议主代码库的维护团队提供详细的指南，阐明如何在新版本发布时，基于旧版本的模板对扩展进行更新。
    - 添加从模板开发的示例扩展，项目开发人员可以参考这些扩展来了解如何编写模式良好的扩展。
    - 放宽对贡献者创建扩展的要求，绕过评审，以实现更快的发布或试验。
 2. **低耦合：** 拥有包含功能的模块化组件可以允许松散耦合，其中扩展的更改不会影响主代码库或其他扩展的质量。
-3. **依赖管理：** 每个扩展都应小心固定其构建的主代码库的版本范围（与任何其他依赖项相同），并且在使用其他依赖项时应小心主存储库的依赖项，以便为这些依赖项选择的版本与所选的主代码库版本兼容。与主代码库的任何冲突都将在扩展的测试框架中捕获。
+3. **依赖管理：** 每个扩展都应谨慎地指定其所依赖的主代码库版本范围，就如同处理其他依赖项一样。在选择其他依赖项时，也要特别注意与主代码库的依赖关系，确保所选版本与指定的主代码库版本相兼容。这种做法不仅能够保证扩展的稳定性，还能通过扩展的测试框架有效地捕获与主代码库之间可能存在的任何冲突。
 4. **测试策略：** 如何单独和组合测试扩展？
    - **单独测试扩展：** 扩展模板将提供一个测试框架，供扩展开发人员用来测试添加的功能。这可以包括单元测试、运行时性能和质量测试的框架。
    - **与主代码库结合测试扩展：** 扩展开发人员有一种模式良好的方法，可以针对主代码库的特定版本测试其扩展，而无需主代码库维护人员的参与。
-   - **与其他扩展结合测试扩展：** 为此场景提供测试框架可能会导致过度，特别是如果用户仍在探索大量扩展并且不太可能全部组合使用。如果用户在组合使用扩展时遇到冲突（如果有足够的松散耦合，这种情况应该不太可能发生），用户可以向相应的扩展所有者提出问题，由他们来解决。当扩展到达生命周期的后期阶段并合并到主代码库时，它将与库的其余部分结合进行测试，并且当时必须解决所有的依赖项冲突。
+   - **与其他扩展结合测试扩展：** 为每个扩展提供全面的测试框架可能会显得过于繁重。如果扩展之间保持适度的松散耦合，冲突的可能性本来就较低。然而，若用户在组合使用扩展时遇到冲突，他们可以直接向相关扩展的维护者报告问题，由这些专业人士来解决兼容性问题。值得注意的是，当扩展发展到生命周期的后期阶段，并有机会被合并到主代码库时，它将与库的其他部分一起进行全面测试。在这个关键阶段，所有潜在的依赖冲突必须得到彻底解决，以确保整个系统的稳定性和一致性。
 5. **可发现性和可用性：**
    - 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
    - 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
@@ -79,7 +79,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 遵循这些原则可确保：
 
 - 开发人员无需编写大量[样板](https://en.wikipedia.org/wiki/Boilerplate_code)代码，即可为项目生态系统添加新功能。
-- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有存入主资源库并不意味着它没有价值。
+- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有合并入主库并不意味着它没有价值。
 - 维护者的负担会减轻，直到扩展证明它填补了主项目中的重要空白。
 - 核心项目的通用代码（如基类和实用功能）可以作为扩展项目领域的新开发的起点。这就避免了事后移植创新工作的需要，从而减轻了为项目开发新功能的总体负担。
 - 开发人员更有可能为他们的代码库做出贡献，并继续参与维护和社区建设，这也有利于整个项目生态系统的健康发展。
@@ -88,7 +88,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 - 项目能够通过增加新功能来扩展，同时不会增加主项目代码库的维护成本。
 - 更快地发布新功能供社区探索，鼓励创新和试验。
-- 减少了成本高昂的代码评审和功能加固过程，直到功能能够证明其实用性，这将为企业节省成本。
+- 将耗时且成本高昂的代码审查和功能完善过程推迟到功能已经证明其实用价值之后， 以有效降低企业的投入。
 - 可能引入的一个后置问题——如果扩展无法完成一个完整的生命周期，会怎么样？
    - 如果一个扩展在一段时间内没有被采用，也无法围绕它建立一个支持维护的社区，那么就需要扩展所有者在他们希望的任何时间内继续维护它。如果扩展没有得到维护，就会被取消发布。
    - 如果扩展开发者无法继续维护其项目，而社区中的其他开发者希望继续支持该扩展，他们可以继续维护该扩展。