ご協力ください

Zettlrをより良いアプリケーションにしたいとお考えですか？素晴らしい！新たに翻訳を提供したい方、開発に参加したい方は、このページをご覧ください。

全般的なリソース

Zettlrは、インターネット中で互いに助け合う活発なコミュニティを有しています。あなたが抱いた疑問を投げかけることができる場所を、以下の一覧に示します。

  • Zettlr user forum — 一般的な質問、ワークフローやZettlrのコンセプトに関する議論、カスタムテーマの共有まで、このサイトで投稿してください。
  • Zettlr subreddit — コミュニティ内のRedditorを対象としたサイトです。
  • 公式Twitterアカウント — アプリケーションの更新をリアルタイムに確認することができます。これが、私たちの活動を定期的に知らせる唯一の場所です。さらに、ほとんどの議論もここで行われます。質問がある場合は、ここに投げてください。
  • 公式Facebookページ — ツイッターのアカウントを持っていない場合、ここからメッセージを送ることができます。通常は、通知を受けたらできる限りはやく返信しますが、確約はできません。このページが存在する理由は……最近は、みんなFacebookのページを持っているからということだけです🤷‍♂️
  • YouTubeチャンネル — 視覚からの情報を好む方は、こちらで入門用の動画をいくつか見ることができます。
  • The GitHub issue tracker — アプリケーションをより良くしようとする私たちの努力の結晶です。バグの指摘や新機能の提案を行うならこちらです。しかしながら、特にユーザのワークフローや新機能に関わる質問については、まず、フォーラムやRedditで話し合うのが最善です。

ユーザの貢献

あなたが、見た目が良くて適切に機能するアプリケーションを求めるユーザーであるならば、エラーが発生したときに見逃さないように、ちゃんと見ていてください。そしてさらに重要なことは、ワークフローをより効率的にする方法を私たちに教えてください。私たちは、私たち自身のワークフローについて判断することしかできません。あなたがより使いやすいアプリケーションとするために、私たちに、その方法を教えてください。ただし、ワークフローをそのままの形で設計に乗せることはできず、他のワークフローとの折り合いをつける必要があることを記憶に留めておいてください。しかし、既存の機能と新提案の機能とのトレードオフが大きくなければ、可能な限り便利でスムーズに動作する機能となるように努力します。

バグ報告は、GitHubリポジトリでIssueをオープンしてください。この方法であれば、私たちが報告に素早く対応できて、直接問題に対処できます。

アプリケーションの翻訳

アプリケーションを、地球上に存在するあらゆる言語に翻訳するための協力を歓迎します。翻訳は翻訳サーバにて管理されています。翻訳を行うためには、アカウントの作成が必要です。これは、スパム対策のために行っています。加えて、生成された翻訳データに（あなたが希望するならば）あなたのユーザー名がクレジットされます。

翻訳方法は単純です。メインページで任意の言語をクリックして、現在存在する識別子の一覧を表示します。

Translation Keys

左の列に書いてあるのが翻訳IDです。これらは概ね、自己説明的な名前になっています。どのように始めたら良いか分からない場合は、英語の翻訳文と、実際のアプリケーションを見比べてれば、翻訳IDがどの要素に対応しているかが分かると思います。

ユーザベースの品質マネジメントシステムが実装されていて、これは、みなさんが既存の翻訳文に投票することで機能します。つまり、自分で翻訳をしたいと思わなくても、翻訳文の中から適切だと思うものに投票することができるのです。誰かが翻訳をダウンロードする際には、得票数の最も多い翻訳文がシステムにより自動的に選択されることで、翻訳の検証が反映されます。

詳細は、翻訳サービスのショートガイドをご覧ください。.

開発

開発を始めるには、リポジトリをフォークし、機能の開発やバグ修正などを行います。それから、プルリクエストをオープンします。developブランチに対してのみプルリクを出すということを覚えておいてください。masterブランチへは、新しいリリースが準備されるときのみpushされます。ですので、新機能を開発しているときにZettlrの新バージョンがリリースされたなら、単純にorigin masterをpullして最新化すれば、機能の開発を続けられます。

機能の開発を始めようと思ったら、新規のissueを作成して他の人に知らせるのが良いでしょう。誰かがすでに取り掛かっていると知らせることで効率を最大化できます。

開発を始める

すべて準備ができたら、お好きなIDEとターミナルを起動してください。ZettlrはNodeJSスタックに基づいているので、現行のNodeサーバとNodeパッケージマネージャがシステムにインストールされている必要があります。ZettlrとしてはYarnを勧めますが、もちろん（Nodeと一緒にインストールされている）NPMを使うこともできます。

続いて、初期化を行います。

Yarnを使う場合

$ git clone https://github.com/Zettlr/Zettlr.git
$ cd Zettlr
$ yarn install
$ cd source
$ yarn install

NPMを使う場合

$ git clone https://github.com/Zettlr/Zettlr.git
$ cd Zettlr
$ npm install
$ cd source
$ npm install

sourceディレクトリで行う、2回目のinstallは、electron-builderのtwo-directories-structureを使うために必要です。

CLIコマンド

Zettlrは開発プロセスで使える便利なコマンドも提供しています。以下にすべてを列挙します。

いずれのコマンドも、使用するパッケージマネージャに合わせてnpm run <command>またはyarn <command>で実行することができます。Zettlrのmainディレクトリで実行してください。

  • start: アプリケーションを開始します。
  • build:quick: 使用中のオペレーティングシステム向けにアプリケーションをビルドし、/releaseフォルダに出力します。
  • release:this: build:quickと同様ですが、アプリケーションのパッケージ化（macOSの.dmg、Windowsの.exeインストーラ、Linuxのパッケージ）も行います。
  • release:mac: 明示的にmacOS向けにリリースを行います。
  • release:win: 明示的にWindows向けにリリースを行います。
  • release:linux: 明示的にLinux向けにリリースを行います。
  • less: LESSコンバータを実行し、/resources/less内のソースをsource/common/assets/cssのCSSファイルに変換します。スタイルの変更を行うたびに、このコマンドの実行が必要です。
  • less:extract: ソースファイルから、CSSのすべてのIDとclassを抽出し、/resources/css_list.mdに一行ごとに出力します。これは、カスタムCSSリファレンス一覧を生成するためだけに使われています。
  • handlebars: このコマンドは、Handlebarsプリコンパイラを起動し、ダイアログとポップアップのテンプレートをアプリケーションで使える形に変換し、/source/common/assets/tplに出力します。 /resources/templatesに含まれるファイルを変更するたびに、このコマンドを実行する必要があります。さもなくば、変更が反映されません。
  • lang:refresh: 最新のデフォルト翻訳（German (Germany), English (United States), English (United Kingdom), French (France)）をtranslate.zettlr.comからダウンロードし、/source/common/langに保存します。
  • reveal:build: revealJSのプレゼンテーション用テンプレートをリビルドします。

これらのコマンドに加えて、Zettlrのフルリリースサイクルを実行するためのmasterコマンドが存在します。これは、/scripts/make.shの中に書かれたシェルコマンドであり、前述のWindows, macOS, DebianベースLinuxディストリビューション, FedoraベースLinuxディストリビューション向けのインストーラを作成するコマンドを実行します。さらに、これら4つのインストーラのチェックサムを含むファイルSHASUMS.txtを出力します。

注意: 今のところMakeスクリプトはYarnとmacOSを必要とします。NPMを使ったり、他のプラットホーム上では動作しません。これは、SHA256チェックサムを生成するコマンドがmacOSとその他のLinuxディストリビューションで異なることに起因します。

プロジェクト構造

技術的な内容に移ります、プロジェクトの構造です。ほとんどの点において、Electronアプリケーション開発のベストプラクティスに従った構造をしています。しかしながら、このアプリケーションは巨大です。それゆえ、いくつかのガイダンスが必要となります。

まずは、ディレクトリ構造を抑えましょう。（これは網羅的なリストではありませんが、必要になるフォルダとファイルはほとんどカバーしています。）

Zettlr                 // ルートディレクトリ
|
+ release              // アプリケーションをビルドすると作成されます。
|
+ resources            // 開発用のあらゆる物が格納されています。リリースには含まれません。
|  |
|  + less              // CSSを生成するソースファイルが格納されています。
|  |
|  + templates         // ダイアログとポップアップ用のテンプレートが格納されています。
|
+ scripts               // 上述の開発用スクリプトが格納されています。
|
+ source                // 実際のアプリケーションソースが格納されています。
|  |
|  + common             // 共通的に使われるファイルです。
|  |  |
|  |  + assets          // CSS, フォント, HBランタイム, 画像, JS, テンプレート。
|  |  |
|  |  + lang            // デフォルト言語とi18nモジュール。
|  |  |
|  |  + util            // アプリケーション全体で使われるユーティリティ関数。
|  |  |
|  |  + data.json       // アプリケーション用の静的データ。
|  |  |
|  |  + validate.js     // バリデーションモジュール
|  |  |
|  |  + validation.json // バリデーションルール
|  |
|  + main               // メインプロセスのファイル
|  |  |
|  |  + assets          // メインプロセス用asset
|  |  |
|  |  + commands        // 実行可能なすべてのコマンド
|  |  |
|  |  + providers       // アプリケーション用のサービスプロバイダー
|  |
|  + print              // 印刷ウィンドウのソースコード
|  |
|  + quicklook          // QuickLookのソースコード
|  |
|  + renderer           // メインウィンドウのコード
|  |  |
|  |  + assets          // 描画処理でのみ使われるasset
|  |  |  |
|  |  |  + codemirror   // CodeMirrorプラグイン
|  |  |  |
|  |  |  + context      // コンテキストメニューで必要なすべてのファイル
|  |  |  |
|  |  |  + toolbar      // ツールバーのテンプレート
|  |  |
|  |  + dialog          // アプリケーションのすべてのダイアログ用のモジュール
|  |  |
|  |  + util            // 描画処理でのみ使われるユーティリティ関数
|  |
|  + main.js            // アプリケーションのエントリーポイント
|
+ CHANGELOG.md          // すべての変更の詳細履歴