FDS-Dev公開 — 非英語圏の開発者のためのドキュメントリンティング + AI翻訳オールインワンツール
(github.com/flamehaven01)FDS-Dev公開 — 非英語圏の開発者のためのドキュメントリンティング + AI翻訳オールインワンツール
🤔 オープンソースの世界で、非英語圏の開発者が最も大きく感じる壁のひとつは、英語でドキュメントを書くことです。
コードには自信があっても、READMEやコメント、ドキュメントを英語で整理しようとすると、なぜか手が止まってしまいます。
AI翻訳ツールの助けを借りられる時代にはなりましたが、
「これは本当に自然な表現だろうか？」
「自分の意図どおりにきちんと伝わっているだろうか？」
そんな悩みを抱えたことがある人も多いはずです。
私自身も15年以上海外で開発者として働いていますが、
今でも 母語で考えて書くのがいちばん自然です。
そのため、開発に没頭しているといつの間にかコメントが母語のまま残っていたり、ドキュメントを整備しようとすると
「これを今公開したら、ドキュメント品質を気にしない開発者だと思われるかもしれない……」
とためらったことも何度もありました。
そうした悩みの末に、自分のような非英語圏の開発者が少しでも負担を減らせるツールがあればいいのに、と思いました。
そこで作りました。
💡 既存リンターの限界: 「優れているが、英語圏中心」
すでに優れたドキュメント品質チェックツールは存在します。
- 🔺 markdownlint → Markdownの文法・スタイルチェック
- 🔺 Vale → トーン、用語の一貫性、文体ガイドのチェック
これらのツールは、GitHub上のドキュメント品質を維持するうえで非常に強力です。
しかし問題は、これらのツールが英語圏の開発者を前提に設計されていることです。
韓国、日本、ドイツ、中国など、非英語圏の開発者が自国語でドキュメントを書く場合:
- リントが正しく機能せず
- スタイルガイドが英語の文を基準としており
- 翻訳・多言語環境が考慮されていないため
結局、「英語で書き直さなければならない負担」が残ります。
🚀 そこで作ったFDS-Dev
✨ 1) 超高速の構造ベースドキュメントリンター
単純なスタイルチェックを超えて:
- ▪️ セクションの順序
- ▪️ 必須ヘッダー
- ▪️ ドキュメント全体のレイアウト
といった 実践的なドキュメント構造まで自動で点検します。
✨ 2) AIベースのコード認識翻訳ツール
ドキュメント、コメント、docstringを翻訳するとき:
- ▪️ コードブロック保護
- ▪️ CamelCase / snake_case の保持
- ▪️ 技術用語の正確な維持
母語で書いたドキュメントを プロダクションレベルの英語ドキュメントへ自動変換します。
✨ 3) 非英語圏の開発者のための、初の「コードレベル国際化」ツール
もう英語でドキュメントを書かなくても、
世界中の誰もが理解できるドキュメントを作れるようになります。
⚙️ 簡単な使い方
pip install --upgrade fds-dev
fds translate README.ko.md --output README.md
fds lint README.md
DeepL, LibreTranslate 등 다양한 번역 백엔드 선택 가능하며
GitHub Actions · Docker 환경도 완벽 지원합니다.
🌏 オープンソースに貢献してください
FDS-Devは今も急速に進化しています。
皆さんの ⭐ Star、Issue、PR がこのプロジェクトの方向性を形作ります。
🙌 非英語圏の開発者のための新しい標準を作りたいです
ドキュメント作成への負担なくコードに集中できる環境、
言語の壁なくグローバルなオープンソースに貢献できるエコシステム——
FDS-Devがその出発点になることを願っています。
たくさんの関心と参加をお願いします!
4件のコメント
🔥 FDS-Dev v0.0.4 — 本日分のアップデートを共有します
FDS-Devを継続して実運用しながら改善を進めています。
本日リリースした v0.0.4 (2025-12-08) の更新内容を簡単に共有します。
✅ 主な変更点
Config 解釈ロジックの改善
これで lint/translate の実行位置を基準に
.fdsrc.yamlを自動探索します。フォルダ単位の設定を変更しても、
cdで移動しなくても即座に反映されます。翻訳パイプラインの安定性強化
language: auto使用時に言語オブジェクトの欠落で発生していたクラッシュを防止しました。DeepL は 5秒のデフォルトタイムアウト + 明確なエラーメッセージにより、CLI のハング問題を解決しました。
コード品質の整備
モジュール全体で行末コードの正規化、末尾空白の削除、最小限の docstring を追加。
プロジェクト専用の
.pylintrcを導入し、Black/Ruff スタイルと衝突せず「実質的なエラー」だけを検出するようにしました。🧪 テスト
pytest 110件通過
pylint fds_dev 10.00/10 点を達成
私はこのプロジェクトを「小規模な言語ベースのドキュメント/コード品質自動化ツール」として育てており、
毎日コミットしながら安定性とエンジニアリング品質を着実に高めています。
興味があれば、ぜひリポジトリをご覧ください:
https://github.com/flamehaven01/FDS-Dev
必要な機能の提案や Issue もいつでも歓迎です!
v0.0.3 バージョンをリリースしました。今回のアップデートでは、セキュリティとエンジニアリング品質の大幅な強化に重点を置きました。
主な変更点は以下のとおりです。
セキュリティ: SECURITY.md、脆弱性レポートプロセス、毎週の Dependabot アップデート、secret scanning、ブランチ保護、セキュリティチェックリストを追加
エンジニアリング品質: pre-commit hooks（black/ruff/isort/yamllint/detect-secrets）、CI テストカバレッジ 70% を強制、mypy（strict）、すべてのツール設定を pyproject.toml に統合
CI/CD: カバレッジレポート・型チェック・マルチリンティングを統合
ドキュメント: Docker/Kubernetes/monorepo パターンを含むエンタープライズ向けデプロイガイド、10分チュートリアルを更新
サンプルコード: 基本/応用サンプルを追加
リポジトリ全体の品質スコアは 10% → 72.5% に改善されました。
リリースノート: https://github.com/flamehaven01/FDS-Dev/releases/tag/v0.0.3
フィードバックはいつでも歓迎します。
MITライセンスのオープンプロジェクトなんですね :) こういうプロジェクトはいつでも歓迎です。
好意的に見ていただき、ありがとうございます！ 🙂
MITライセンスで維持している理由も、誰でも自由に利用し、チームや会社の環境に合わせて発展させられるようにするためです。
特に今回の v0.0.3 では、セキュリティ/エンジニアリング基盤を大幅に強化したため、
小さな個人プロジェクトからエンタープライズ環境まで、負担なく活用していただけるはずです。
もし使っていて改善アイデアや提案があれば、いつでもお知らせください！ 🙌