Add Japanese translations and implement I18N support

docs/ja/advanced.md

@@ -0,0 +1,108 @@
+<!--
+Copyright © 2012-2023 jrnl contributors
+License: https://www.gnu.org/licenses/gpl-3.0.html
+-->
+
+# 高度な使用方法
+
+## 設定ファイル
+
+`jrnl`には、テンプレート、フォーマット、複数のジャーナルなど、設定ファイルを通
+してカスタマイズできる多様なオプションがあります。詳細については[設定ファイルリ
+ファレンス](./reference-config-file.md)を参照するか、以下の一般的な使用例をお読
+みください。
+
+### 複数のジャーナルファイル
+
+[設定ファイル](./reference-config-file.md)でより多くのジャーナルを定義することで、`jrnl`を複数のジャーナル（例：`private`と`work`）で使用するように設定できます。例えば：
+
+```yaml
+journals:
+  default: ~/journal.txt
+  work: ~/work.txt
+```
+
+`default`ジャーナルは`jrnl`を初めて起動したときに作成されます。
+これで、`jrnl`の代わりに`jrnl work`を使用して`work`ジャーナルにアクセスできます。例えば：
+
+```sh
+jrnl work at 10am: @Steveとのミーティング
+jrnl work -n 3
+```
+
+これらはどちらも`~/work.txt`を使用しますが、`jrnl -n 3`は`~/journal.txt`から最後の3つのエントリーを表示します（`jrnl default -n 3`も同様です）。
+
+各ジャーナルのデフォルトオプションを個別にオーバーライドすることもできます。
+`jrnl.yaml`が以下のようになっている場合：
+
+```yaml
+encrypt: false
+journals:
+  default: ~/journal.txt
+  work:
+    journal: ~/work.txt
+    encrypt: true
+  food: ~/my_recipes.txt
+```
+
+`default`と`food`ジャーナルは暗号化されませんが、`work`ジャーナルは暗号化されます！
+
+`jrnl.yaml`のトップレベルにあるすべてのオプションをオーバーライドできますが、少なくともそのジャーナルのジャーナルファイルを指す`journal: ...`キーを指定してください。
+
+以下の設定例を考えてみましょう：
+
+```yaml
+editor: vi -c startinsert
+journals:
+  default: ~/journal.txt
+  work:
+    journal: ~/work.txt
+    encrypt: true
+    display_format: json
+    editor: code -rw
+  food:
+    display_format: markdown
+    journal: ~/recipes.txt
+```
+
+`work`ジャーナルは暗号化され、デフォルトで`json`形式で出力され、VSCodeの既存のウィンドウで編集されます。同様に、`food`ジャーナルはデフォルトでmarkdown形式で出力されますが、他のすべてのデフォルト設定を使用します。
+
+### コマンドラインから設定を変更する
+
+現在の`jrnl`インスタンスの設定フィールドを`--config-override CONFIG_KEY CONFIG_VALUE`を使用してオーバーライドできます。ここで、`CONFIG_KEY`は有効な設定フィールドをドット表記で指定し、`CONFIG_VALUE`は希望する（有効な）オーバーライド値です。ドット表記を使用して、`colors.title`のような他のキー内のキーを変更することもできます。
+
+複数のオーバーライドを指定するには、`--config-override`を複数回呼び出します。
+
+!!! note
+これらのオーバーライドにより、jrnl設定の**_任意の_**フィールドを変更できます。自己責任で使用してください。
+
+#### 例
+
+```sh
+# 高速ログ記録のために`stdin`プロンプトを使用してエントリーを作成する
+jrnl --config-override editor ""
+
+# プロジェクトのログを記録する
+jrnl --config-override journals.todo "$(git rev-parse --show-toplevel)/todo.txt" todo タオルを見つける
+
+# 複数のオーバーライドを渡す
+jrnl --config-override display_format fancy --config-override linewrap 20 \
+--config-override colors.title green
+```
+
+### 代替設定の使用
+
+現在の`jrnl`インスタンスに対して、`--config-file CONFIG_FILE_PATH`を使用して代替設定ファイルを指定できます。ここで`CONFIG_FILE_PATH`は代替`jrnl`設定ファイルへのパスです。
+
+#### 例
+
+```sh
+# 個人的なジャーナルエントリーに個人用設定ファイルを使用する
+jrnl --config-file ~/foo/jrnl/personal-config.yaml
+
+# 仕事関連のエントリーに代替設定ファイルを使用する
+jrnl --config-file ~/foo/jrnl/work-config.yaml
+
+# デフォルトの設定ファイルを使用する（初回実行時に作成される）
+jrnl
+```

docs/ja/contributing.md

@@ -0,0 +1,132 @@
+<!--
+Copyright © 2012-2023 jrnl contributors
+License: https://www.gnu.org/licenses/gpl-3.0.html
+-->
+
+# jrnlへの貢献
+
+jrnlへの貢献を歓迎します。バグの報告、ドキュメントの改善、リリースのテスト、機能やバグに関する議論への参加、コードの作成など、さまざまな形での貢献が可能です。
+
+## 目次
+
+- [行動規範](#行動規範)
+- [バグの報告](#バグの報告)
+- [ドキュメントの編集](#ドキュメントの編集)
+- [テスト](#テスト)
+- [機能リクエストとアイデアの提出](#機能リクエストとアイデアの提出)
+- [jrnlの開発](#開発)
+
+## 行動規範
+
+まず始めに、[行動規範](https://github.com/jrnl-org/jrnl/blob/develop/CODE_OF_CONDUCT.md)をお読みください。
+
+## バグの報告
+
+バグは[新しい問題を開く](https://github.com/jrnl-org/jrnl/issues/new/choose)ことで報告してください。できるだけ詳細に説明してください。多くのバグは特定のオペレーティングシステムやPythonのバージョンに固有のものなので、その情報も含めてください！
+
+## ドキュメントの編集
+
+ドキュメントにタイプミスや間違いを見つけた場合は、すぐに修正してプルリクエストを送ってください。何を変更すべきか不確かだが問題を見つけた場合は、「ドキュメントの変更」タイプで[新しい問題を開く](https://github.com/jrnl-org/jrnl/issues/new/choose)ことができます。
+
+ドキュメントを編集するには、**develop**ブランチの`docs/*.md`ファイルを編集します。プロジェクトのルートディレクトリで`poe docs-run`を実行し、ブラウザで[localhost:8000](http://localhost:8000)にアクセスすることで結果を確認できます。
+
+### 外部エディタとヒントとコツ
+
+便利だと思うjrnlのコマンドラインテクニックを共有したい場合は、["ヒントとコツ"セクション](tips-and-tricks.md)に追加するとよいでしょう。特定の外部エディタとの統合に関するアドバイスは、["外部エディタ"セクション](external-editors.md)に追加できます。
+
+## テスト
+
+jrnlの保守作業の多くは、コーディングよりもテストに関わるものです。
+
+jrnlの性質上、非常に機密性の高いデータを扱うため、データ損失のリスクを冒すことはできません。jrnlには包括的な自動テストスイートがありますが、ユーザーテストはこのリスクを軽減する上で極めて重要です。
+
+### プレリリース
+
+[プレリリースは通常のリリースと同様にPyPiを通じてデプロイされます](https://pypi.org/project/jrnl/#history)。[pipx](https://pypi.org/project/pipx/)を使用してそれらを取得し、テストすることができます。各リリースで変更された内容については[チェンジログ](https://github.com/jrnl-org/jrnl/blob/develop/CHANGELOG.md)を参照してください。
+
+### プルリクエスト
+
+gitに慣れている場合は、特定の[プルリクエスト](https://github.com/jrnl-org/jrnl/pulls)をフェッチし、自分でテストして、結果を報告してください。新機能の動作をスクリーンキャストで示すとなおよいでしょう。
+
+### バグ報告の確認
+
+[GitHubの問題](https://github.com/jrnl-org/jrnl/issues?q=is%3Aissue+is%3Aopen+label%3Abug)には常にオープンなバグがあり、多くは特定のOS、Pythonバージョン、またはjrnlバージョンに固有のものです。「jrnl v2.2、MacOS 10.15、Python 3.8.1で確認」といった簡単なコメントでも、バグの追跡に非常に役立ちます。
+
+### 自動テスト
+
+新しい自動テストの追加方法については、以下の開発セクションを参照してください。
+
+## 機能リクエストとアイデアの提出
+
+jrnlに対する機能リクエストやアイデアがある場合は、[新しい問題を開いて](https://github.com/jrnl-org/jrnl/issues/new/choose)機能の目的と関連するユースケースを説明してください。私たちはあなたと議論し、それがプロジェクトに適しているかどうかを決定します。
+
+新機能について議論する際は、私たちの設計目標を念頭に置いてください。jrnlは[一つのことをうまく行う](https://en.wikipedia.org/wiki/Unix_philosophy)ことを目指しています。私たちにとって、それは以下を意味します：
+
+- *機敏*であること
+- シンプルなインターフェースを持つこと
+- 機能の重複を避けること
+
+## 開発
+
+### 環境のセットアップ
+
+jrnlを開発するには[poetry](https://python-poetry.org/)をインストールする必要があります。poetryがプロジェクトの他のすべての依存関係を管理します。
+
+### ブランチの理解
+
+jrnlは主に2つのブランチを使用します：
+
+- `develop` - 継続的な開発用
+- `release` - リリース用
+
+一般的に、プルリクエストは`develop`ブランチに対して行われるべきです。
+
+### 一般的な開発コマンド
+
+`pyproject.toml`にコマンドの一覧があります。ユーザーは`poe`の後にコマンド名を入力することでコマンドを実行できます（[Poe the Poet](https://github.com/nat-n/poethepoet)は単独で、または`poetry install`の一部としてインストールできます）。
+
+典型的な開発ワークフローには以下が含まれます：
+
+- 依存関係のインストール：
+  - `poetry install`
+- 仮想環境の有効化：
+  - `poetry shell`
+- 仮想環境でソースを実行：
+  - `jrnl`（必要に応じて引数を付けて）
+- テストの実行：
+  - `poe test`
+- コードのフォーマットをスタイルに標準化：
+  - `poe format`
+
+### 自動テストの更新
+
+バグの解決や新機能の追加時には、将来その機能が壊れるのを防ぐためにテストを追加してください。テストでカバーされていない機能に気づいた場合は、テストのみのプルリクエストを提出することもできます。
+
+テストには、ユニットテスト用に[pytest](https://docs.pytest.org)を、統合テスト用に[pytest-bdd](https://pytest-bdd.readthedocs.io/)を使用しています。すべてのテストは`tests`フォルダーにあります。
+
+多くのテストは、他のテストと同じフォーマットの`*.feature`ファイルを編集するだけで作成できます。より複雑な機能については、`tests/lib/`にステップを実装し、それを`feature`ファイルのテストで実行する必要があるかもしれません。
+
+### プルリクエストの提出
+
+準備ができたら、プルリクエスト（PR）を提出してください。jrnlのメンテナーは通常2週間ごとにプルリクエストをレビューしますが、継続的統合パイプラインは数分以内にあなたのコードに対して自動テストを実行し、さまざまな環境で見つかった問題を報告します。
+
+プルリクエストのテンプレートにはハウスキーピング項目のチェックリストが含まれています。提出時に必要に応じてそれらを記入してください。
+
+プルリクエストにテスト失敗が含まれている場合、おそらくレビューされず、確実に承認されません。ただし、テスト失敗の解決に助けが必要な場合は、PRでその旨を言及してください。
+
+### 作業対象を見つける
+
+[jrnlのGitHub Issues](https://github.com/jrnl-org/jrnl/issues)を[ラベル](https://github.com/jrnl-org/jrnl/labels)で検索して、作業対象を見つけることができます。以下は検索する価値のあるラベルです：
+
+- [critical](https://github.com/jrnl-org/jrnl/labels/critical)
+- [help wanted](https://github.com/jrnl-org/jrnl/labels/help%20wanted)
+- [bug](https://github.com/jrnl-org/jrnl/labels/bug)
+- [enhancement](https://github.com/jrnl-org/jrnl/labels/enhancement)
+
+[マイルストーン](https://github.com/jrnl-org/jrnl/milestones)をレビューして、プロジェクトの優先事項を把握することもできます。
+
+### 新しいプログラマーとPythonを初めて使うプログラマーへの注意
+
+jrnlは発足以来かなり成長しましたが、全体的な複雑さ（エンドユーザープログラムとしては）は比較的低く、コードを理解しやすいと思います。
+
+質問がある場合は、遠慮なく聞いてください！Pythonは初心者プログラマーを歓迎し、オープンなコミュニティとして知られています。コードをフォークして自由に試してみてください！私たちと共有したいものを作成した場合は、プルリクエストを作成してください。プルリクエストが完璧で、慣用的で、すぐにマージできるコードであることは期待していません。一緒に取り組んでいきましょう！