Japanese version is ready for review

[kkomazaw]

I included a Japanese version of this guidebook under l10n/ja. I am glad if it can be merged.

[semioticrobotic]

This is awesome, @kkomazaw. Fantastic work! And thank you. 🙏

At the moment, we don't (to my knowledge) have many community members qualified to help review your PR. But I've sent a call for volunteers and hope that we'll see a few new faces arrive to help us get this merged.

Again, thank you! ⭐️

[shu-mutou]

まだ少ししかレビューしていませんが、全体的に「オープンソース・ウェイ」の「・」をどうしたものかご検討いただきたく、一旦ここまでにします。

Although I have only reviewed a small amount so far, there is a point that I would like you to consider overall, so I will end my review here.

[shu-mutou]

空行は他のファイルに合わせて「なし」にしませんか。

[kkomazaw]

これはどういう意味でしょうか？お手数ですがもう少し詳しく教えてください。

[shu-mutou]

Rawで見ると、空行が幾つかあるようです。

[kkomazaw]

Thank you very much for your support,Shu. I will fix all as your advices.

[shu-mutou]

ルートにある大文字ファイルのレビューを完了しました。他の内容は、また別途実施します。

Completed review of uppercase files on the root directory. Other contents will be carried out separately.

[shu-mutou]

Rawで見ると、空行が幾つかあるようです。

[shu-mutou]

https://creativecommons.org/licenses/by-sa/4.0/deed.ja
が日本語版の原本のようなので、ここからまるっとコピーした方が良いと思います。

最後のリーガルコードのURLの日本語版は以下のようです。
https://creativecommons.org/licenses/by-sa/4.0/legalcode.ja

[shu-mutou]

中途半端ですが、時間的制約により、一旦レビューを区切ります。
It's only half-finished, but due to time constraints, I'll break up the review for now.

[shu-mutou]

本日もキリが悪いですが、時間切れです。

I'm running out of time today.

[shu-mutou]

Suggested change

	「新米ママの自由時間は通常1日1時間未満です。私にとっての鍵は、自分がやりたいオープンソース活動と、職場が報酬を支払うオープンソース活動を一致させることでした。産休明けにはCVEバイナリツールのオープンソース化に取り組み、メンターとしての役割で学生を指導する時間を確保できるよう上司と調整しました。」
	「新米ママの自由時間は通常1日1時間未満です。私にとっての鍵は、自分がやりたいオープンソース活動と、職場が報酬を支払うオープンソース活動を一致させることでした。産休明けにはCVEバイナリツールのオープンソース化に取り組み、メンテナーとして学生を指導する時間を確保できるよう上司と調整しました。」

[shu-mutou]

Suggested change

	例えば、プロジェクトの_ユーザー_と_開発者_という基本的な区別を考えてみましょう。ソフトウェアの_使用_に関心のある人は、インストール方法、設定方法、手元のタスク（例：ウェブサイトの構築）を達成するために必要な知識などに興味を持つでしょう。開発者もこうした詳細には関心を持ちますが、プロジェクトに効果的に貢献するためには追加情報が必要となります。
	例えば、プロジェクトの_ユーザー_と_開発者_という基本的な区別を考えてみましょう。ソフトウェアの_使用_に関心のある人は、インストール方法、設定方法、手元のタスク（例：ウェブサイトの構築）を達成するために必要な知識などに興味を持つでしょう。開発者もこうした詳細には関心を持ちますが、プロジェクトに効果的に貢献するためには追加情報が必要となります。

ditto

[shu-mutou]

Suggested change

	問題解決に役立つソフトウェアの情報を探す際、人々が最初に訪れるのはプロジェクトウェブサイトでしょう。
	問題解決に役立つソフトウェアの情報を探す際、人々が最初に訪れるのはプロジェクトウェブサイトでしょう。

ditto

[shu-mutou]

Suggested change

	プロジェクトウェブサイトの目立つ場所に、プロジェクトの簡潔な概要を掲載しましょう。この説明には、コードベースが何を目的として設計されているか、そしてそれを使用することで解決できる可能性のある問題を含める必要があります。この情報を簡潔かつ見つけやすくすることが重要です。プロジェクトのホームページに簡単な説明を掲載し、関心のある人がすぐにプロジェクトが自身のニーズを満たすように設計されているかどうかを判断できるようにしましょう。
	プロジェクトウェブサイトの目立つ場所に、プロジェクトの簡潔な概要を掲載しましょう。この説明には、コードベースが何を目的として設計されているか、そしてそれを使用することで解決できる可能性のある問題を含める必要があります。この情報を簡潔かつ見つけやすくすることが重要です。プロジェクトのホームページに簡単な説明を掲載し、関心のある人がすぐにプロジェクトが自身のニーズを満たすように設計されているかどうかを判断できるようにしましょう。

ditto

[shu-mutou]

Finished attracting-users chapter once.
Remaining few notation fluctuation across documents like "メンテナ" and "管理者" etc.

[shu-mutou]

Structural Issues in This Document

I would like to share some concerns that arose during the translation work.

Contradictory Messages

This document recommends "Release early, release often" for maintainers, while simultaneously condoning an attitude from potential contributors that they will only participate in "perfectly prepared projects."

Specifically, in the chapter "To Build Diverse Open Source Communities, Make Them Inclusive First":

• Affirmation of the stance that people won't participate in projects without a CoC
• Negative attitude toward projects with incomplete documentation
• The assumption that preparing all of these is solely the maintainer's responsibility

Many of the people quoted in this chapter are contributors with corporate support. They state they "won't contribute to unprepared projects," but isn't helping to improve projects part of their role?

What Should Be

If a project lacks a CoC or documentation, that itself is an opportunity for contribution.

Rather than "waiting for preparation," the attitude of "preparing together" is what truly creates an inclusive community, isn't it?

For example:

• When you find a project without a CoC, send a PR proposing a Contributor Covenant template
• If documentation is lacking, help organize it
• Work together to adjust it to the project's context

These are important "non-code contributions" that this document should value.

Lack of Consideration for Burnout

While this document has a chapter on "Community Manager Self-Care," the preceding chapters place additional burdens on maintainers.

Specifically:

• Create and enforce a CoC
• Prioritize documentation
• Build systems to value diverse contributions
• Establish mentorship programs
• Continuously improve

All of these are important, but there is insufficient consideration for who bears the cost of implementing them.

Improvement Proposals

If this document truly aims for sustainable communities, it should reconsider the following points:

1. Redefining "Inclusive First"

• A culture where not only maintainers but also participants contribute to building the environment
• An approach of "collaborative improvement" rather than "conditional participation"
• Encouraging an attitude of joining imperfect projects and improving them together

2. Addressing the Reality of Resource Constraints

• Realistic strategies for small-scale projects
• Guidance on "choosing what not to do"
• Concrete methods for prioritization
• Roadmaps for incremental improvement

3. Explicit Documentation of Maintainers' Rights

• The right to say "I can't do this"
• The right to publish imperfect projects
• The right to improve at one's own pace
• The right to decline contributions

4. Bidirectional Responsibility

Current structure:

Maintainers: Responsibility to prepare the environment
Contributors: Right to choose prepared environments

Desirable structure:

Maintainers: Responsibility to show project direction
Contributors: Responsibility to cooperate in environment preparation
Both: Shared responsibility to create better communities

Conclusion

As one of the burnout maintainers, I came to the following conclusion:

Without improvements to these issues, I believe this document will not prevent maintainer burnout but rather promote it in a different form.

"Inclusivity" is important, but unilaterally imposing the burden of achieving it on maintainers is not sustainable.

I judge that translating and promoting a document containing such structural issues, as is, would not be beneficial for the Japanese open source community at this time.

Unless the above issues are addressed, I cannot continue reviewing this translation project.

P.S., @kkomazaw I am very sorry.

[shu-mutou]

@semioticrobotic I would appreciate it if you would consider the above comments.

[semioticrobotic]

I certainly appreciate these reflections, @shu-mutou, and especially the care and effort you extended in documenting them. As I understand them, these aren't so much translation issues as much as conceptual/philosophical issues with the book's arguments themselves. All perfectly valid (and welcome!), but perhaps beyond the scope of this issue.

The chapters you reference have different authors, and I doubt they will see your comments in a thread on translation, so I will see what I can do about breaking these off into separate issues/discussions.

One final editorial note: The target audience for The Open Source Way is largely project maintainers and folks wishing to learn more about what's involved in creating and maintaining sustainable communities. So if there's an editorial bias toward the types of actions the book tend to promote—and who it addresses/assumes as the party undertaking these actions—it's those project maintainers. You're right that we should avoid giving the impression that maintainers are solely responsible for creating diverse and sustainable communities, but if we're planning to dispense advice on how to do this, we're more likely to begin by addressing maintainers, as they comprise the most significant audience for the book. That said, the conversation around project sustainability and maintainer burnout has evolved considerably since our community first published this work. It's likely time for an update!

[sanchuanhehe]

Thanks again for the Japanese translation work here. I previously helped with the Chinese translation, and this PR made me think about a more structural question for the project.

As more locales arrive, I think the main challenge may not only be translation capacity, but long-term maintenance: reviewer scarcity, keeping translations in sync with upstream changes, and the lack of CI/tooling to catch stale or broken localized content early. The current mirrored-directory approach works, but over time it may become expensive to review and maintain.

I opened #260 to discuss whether it would be worth exploring a more translation-aware docs workflow, for example Sphinx + MyST plus gettext-based localization tooling, along with editing/review support such as preview builds, link checking, style checks, and possibly tools like Weblate or similar platforms.

If the maintainers think this is useful, I would be glad to help maintain and bootstrap the corresponding infrastructure.