Krita マニュアルの作成者用ガイド

Welcome to the Krita Manual Contribution Guide!

もしあなたが Krita のドキュメントに貢献したいのならば、あなたは正しい場所にいます。

Krita is (free) open source software, which effectively makes us a community project with dozens of volunteers pitching in to make it better. This, of course, requires we keep track of manuals and how-to's for new volunteers to come in and help us. The various places we’ve done this have been rather spread out, so the contributors' manual is an attempt to consolidate all the information. It is therefore very technical in places.

This documentation will include:

Krita のリファレンスマニュアル

This one is probably what everyone is expecting when they look up Krita's documentation. Dry, basic, 'what does this button do' type of information.



また、Krita では色管理やレイヤー処理などの特定の概念が、一般的なアーティストが使用するものよりもはるかに先進的であることも分かりました。Krita は誰でも使用可能ですから、Krita ユーザの多くはデジタルアートワークの正式なトレーニングを受けていません。そのため、アーティスト向けの色管理やフィルタレイヤの使用方法に関する基礎知識が既存のものは用意されていません。

In addition there are systems that are unique to Krita, for example the brush system, the transform masks, the alpha inheritance and the perspective assistants. Finally, there are users who aren't familiar with even standard painting workflows, and are not flexible enough to understand how to port a tutorial for SAI or Photoshop to Krita.


見たところ、Krita 開発チームの素晴らしい点の一つはアーティストとの関わりにおいて、彼らの素晴らしい仕事を認めていることです。チュートリアルとして有用な、特に Krita の使い方や、優れた絵画へのアプローチなどの知識を、ユーザーが共有することを勧めています。

Contributors' Manual

今あなたが読んでいるものです! チュートリアル と にはたくさんのチュートリアルがあり、前者は新機能の使い方を説明することに焦点を当てており、後者はユーザのリクエストに応えたものです。


これは公開されていた、私たちが持っていたさまざまな FAQ を統合したものです。既に翻訳中のため、これを基点に更新していきたいと思っています。


Mediawiki とは異なり、Sphinx は Krita のソースコードを書くような形で動作します。

First things first, you will want to talk to us! For this you can join us in the chatroom "#krita" via matrix. A introduction about Matrix is given here. Create a matrix on account and join the channel. Or more importantly, make an account at The account you make at identity can be used to both access as well as the phabricator, where we organise Krita development.

Sphinx は reStructuredText マークアップを含む単純なテキストファイルを作成することで動作し、そのテキストファイルを取り込んでマニュアルに変換します。私たちはマニュアルの変更を、Git と呼ばれるバージョン管理システムで管理しています。


私たちは Git というバージョン管理システムを使用していますが、Git 上でファイルを変更できる権限を持つ人は数人しかいません。何かを変更したい場合は、変更点を Git に反映する前に評価(レビュー)することが必要です。

Edit mode を使用してマージリクエストを作成する


この方法は、あなたが KDE のリポジトリに対するプッシュアクセスを持っていない場合のみ適しています。そうでなければ直接リポジトリに変更をコミットすることになりますが、これは現在のガイドラインに反しています。


一度に複数のファイルを変更する場合はお勧めしません(より多くのファイルを変更したい場合、または単にマージリクエストごとに1つだけファイルを編集したい場合は WebIDE を使用してマージリクエストを作成する または コマンドラインを使用してマージリクエストを作成する を参照してください)。


  1. KDE アカウントを取得します。

  2. KDE_gitlab にログインします。

  3. repository にアクセスして fork をクリックします。

  4. あなたのフォークリポジトリの場所にリダイレクトされるはずです。通常は です。

  5. Come back to the official repository. Make sure you're browsing Documentation > Documentation, not your own fork. Otherwise this method won't work correctly.

  1. Gitlab にはファイルを編集する機能があります。Repository ‣ Files から行います。

  2. At the top of the page you should see a dropbox with master as a chosen item.

  3. 編集したいファイルを見つけて開き、Edit をクリックします。

  4. 変更を行います(注:このモードでは、一度に1つのファイルしか編集できません)。

  5. 小さなテキストボックス欄に変更内容を含む小粋なメッセージをコミットメッセージ項目に書き込みます。完了したら Commit changes をクリックします。これでマージリクエストが提出されますので、次で説明するように全項目を入力してください: 新しいマージリクエスト提出のガイドライン

    悪い面は、この方法を使用してマークアップでエラーが発生したかどうかを判断する方法が現在ないことです。Online Sphinx Editor で変更を確認してください(編集中のファイル全体をコピーして貼り付けてください)。


EditWebIDE は別々の項目です! Edit を必ず選択してください。


WebIDE を使用してマージリクエストを作成する

複数のファイルを一度に編集したい、Git について多少の知識があるユーザにお勧めします。

ブランチが何であるかが分からない場合はお勧めしません(Edit mode を使用してマージリクエストを作成する を代わりに参照してください)。

  1. 上記の指示に従って KDE_gitlab にログインし、フォークリポジトリを作成します。

  2. あなたのフォークリポジトリに移動します(コンテンツ URL とユーザ名が正しいか確認してください)。

  3. master ブランチにいることを確認してください。

  4. WebIDE をクリックします。これにより、左側にファイルのリストがあり、右側にファイル内容のための大きな空きスペースがあるページが表示されます。

  5. 編集したいファイルを開き、変更を行います。

  6. Commit... をクリックします。Unstaged の全ファイルをダブルクリックして Staged changes に移動します。

  7. Commit... を再度クリックすると、コミットメッセージ作成用のテキストボックスが現れます。変更内容と変更の理由をコミットメッセージとして入力します。

  8. 正しく設定されていることを確認してください。次のいずれかを選択する必要があります。 ・ Create a new branch (ブランチの名前は [ユーザ名]/[変更箇所の簡単な概要] としてください)。変更が完了したら、Start a new merge request がチェックされていることを確認します。 ・それ以外の場合は、後で新しいマージリクエストを作成する必要があります。

  9. Stage & Commit をクリックします。

  10. すべての項目を入力してください: 新しいマージリクエスト提出のガイドライン を参照してください。

  11. 新しいマージリクエストを手動で作成するには、Krita マニュアルの公式リポジトリにアクセスし( URL にあなたのユーザ名が含まれて"いない"ことを確認してください)、Create a new merge request (左側にある緑色のボタン)をクリックします。あなたのフォークリポジトリを選択し、WebIDE で作成したブランチを選択します。


If you don't have a push access to the official repository, gitlab won't allow you to save your changes if you were editing the official repository by mistake (and Create a merge request won't help with that: you still need to commit your changes to your branch, but if you don't have push access, you can't do it). It will just show the message: An error occurred whilst committing your changes. Please try again.

この場合は、変更したすべてのファイルの内容をコピーし、フォークリポジトリに移動して WebIDE に貼り付けます。


Git の動作やコマンドラインの使い方を知っているユーザにお勧めします。

ブランチが何であるかが分からない場合はお勧めしません(Edit mode を使用してマージリクエストを作成する を代わりに参照してください)。

  1. 上記の指示に従って KDE_gitlab にログインし、フォークリポジトリを作成します。

  2. git clone で Git リポジトリをローカルリポジトリに複製します。リポジトリのページには git clone を実行できる URL があり、フォークした自分のローカルリポジトリから変更をプッシュすることもできます。この方法の利点は、コンピュータ上のすべてのツールを使用してこれらのファイルを編集したり、エラーをチェックするためのマニュアルをローカル上に作成したりできることです(この手順は最初の1回だけ実行します)。

    # for ssh access
    git clone [email protected]:<username>/docs-krita-org.git
    git remote add upstream [email protected]:documentation/docs-krita-org.git
    # for https access
    git clone<username>/docs-krita-org.git
    git remote add upstream
  3. 新しい変更を行う前に、必ず公式リポジトリから pull することを忘れないでください。

    git pull upstream master
  4. Make sure you create a new branch for your changes, since september 2019, all changes should be branched from master.

    git checkout master
    # and then:
    git checkout -b "<username>/<description of the new feature>"
  5. 変更後、それらをコミットしてあなたのフォークブランチにプッシュします。このワークフローで Git をターミナルで使用する方法の詳細については、Forking on Gitlab を参照してください。

    # install the python3-sphinx package for your system. For example for Ubuntu:
    sudo apt install python3-sphinx
    # build the manual (reports potential errors, allows to inspect changes in the browser)
    make html
    # make sure everything is correct
    git status
    git diff
    # add all of the files
    git add .
    # commit your changes
    git commit
    # submit your changes to your fork
    git push
  6. Finally, go to the website of the original repository, and then to Merge Requests. Select your fork and the correct branch and create a new merge request. For instruction on how to fill the fields, see 新しいマージリクエスト提出のガイドライン.


  1. コミットメッセージは、次に説明する標準に従ってください: How to Write a Git Commit Message

  2. TitleDescription はコミットメッセージのように、あなたが行った変更とその理由を説明すべきですので、上記リンクのガイドラインに従ってください。

  3. Target should point to master.

  4. マージリクエストの内容が、後で変更を必要とすることが確実な場合は、マージリクエストのメッセージタイトルを [WIP] で始めます。

  5. Allow commits from members who can merge to the target branch. (対象ブランチにマージできるメンバからのコミットを許可する)をチェックしたことを確認してください。これはマージリクエストが master ブランチに基づいて再作成されるため、マージリクエスト自体がシステム的に変更されますが、実際のファイル変更内容は変わりません。これを Rebase と言いますが、これは作成ユーザまたはレビュー担当者が行うことができます。後で面倒なことになりたくない場合は、このチェックボックスをオンにして、レビュー担当者が Rebase を行えるようにしてください。

  6. 多くの場合、Delete source branch when merge request is accepted をチェックしても大丈夫です。

  7. レビュー担当者から特に指示がなければ Squash commits when merge request is accepted をチェックしてください。コミットメッセージの最初の行はあなたのマージリクエストの Title から文章がコピーされ、残りはマージリクエストの Description からコピーされます。

  8. When you finish creating your merge request, go to IRC (see Internet Relay Chat) and ask someone with push access to add the Needs Review label on your merge request.

  9. マージリクエストに誤りがある場合は、フィードバックを受けることがあります。以下のいずれかの方法で、あなたのブランチの誤りを修正してください。

    • If you want to use Edit mode, just go to Changes section of the merge request and click on the pencil icon (with a tooltip that says Edit) to use the Edit mode again.

    • WebIDE モードを使用したい場合は、あなたのフォークリポジトリに移動し、変更したブランチを選択して WebIDE を選択します。

    • パソコン上のファイルを編集してコマンドラインで Git 操作する場合は、正しいブランチにいることを確認して、変更をリポジトリにプッシュしてください。Gitlab は公式リポジトリへのマージリクエストを自動的に更新します。

    変更後はラベルをもう一度 Needs Review (レビューが必要)に変更するように依頼してください。

詳細については、技術編である Forking on Gitlab を確認してください。


このガイドの執筆時点でマージリクエストにラベルを設定できるのは、公式リポジトリへの書き込み権を持つコントリビュータだけです。この意味がわからない場合は、基本的にラベルを設定できるユーザーではありません。そのため、マージリクエストを作成または変更するときには、IRC(Krita コミュニティ を参照)にアクセスして、誰かにラベルを付けてもらう必要があります。


すぐにマージリクエストを作る前に、まずいくらか変更を試してみたい場合(そして Git やコマンドラインの使い方を既に知っている場合)、これらは コマンドラインを使用してマージリクエストを作成する の第5ステップ目で説明されています。




「Krita のユーザは全員55歳の男性であることを知っています」というような形で、人口統計について話すことはできません。Krita は非常に多くの人に使われていますが、私たちはユーザ層が多様であることを誇りに思っています。


  • 彼らはアーティストです。これは対象とするユーザの明確な特徴です。

    • アーティストですから、きれいな画像を好みます。

    • 彼らは視覚に訴えます。

    • 彼らはきれいな絵を表現したいと思っています。



  • High-school and college students trying out drawing software for illustrations. These usually have some previous experience with drawing software, like Paint Tool SAI or Photoshop, but need to be introduced to possibilities in Krita. This group's strength is that they share a lot of information with each other like tips and tricks and tutorials.

  • ペイントソフトを用いて収入を得ているプロ。このグループの強みは、プログラムを改善するために提供する方法や意思が様々にあることです。次の2パターンがあります:

    • 一般の専門家。これらの人々は、ソフトウェア工学を把握していませんが、長年にわたってしっかりとしたワークフローを作り上げ、磨き上げられたセンスをもって、ソフトウェアでの作業を行っています。これらはイラストレーター、画家、印刷職の関係者であることが多いです。

    • 技術者。手段の一つとして Krita を使用し、間違いのない計算とピクセルの配置に注意を払う人々です。ゲームや VFX の業界で働く人が多いですが、科学者もいます。

  • 大人や年配の、趣味に熱中する人達。彼らはコンピュータについてあまり詳しくなく、チュートリアルにはないちょっとしたステップにおいて、困難を感じているようです。彼らの集団としての強みは、学生が知らないような、そしてプロにとっては行うための時間がないような、実生活から生まれた型破りなワークフローを取り入れたり、そのためのツールを作成すること、そして、もっと大きなコミュニティの中の、初期グループに対する緩冷効果をもたらすことです。


  • 技術的なことが分かるのは1グループだけです。そのため、マニュアルテキストを作成する上で根幹をなすコンセプトページが必要です。

  • そのうち3人は、以前に他のソフトウェアの使用経験があって、そこからの移行方法を必要としています。

  • そのうち2人は、Krita と他のソフトウェアを連携させる方法を知る必要があります。

  • そのうちの2人は自分が何をしているのかまったく分かっておらず、最も基本的な手順を示す必要があるかもしれません。



可能であれば、アメリカ英語( American English )を使用してください。

Krita の UI がデフォルトでアメリカ英語(American English)になっているので、マニュアルではアメリカ英語を使用しています。


As a community, we want to be welcoming to the users, so we try to avoid language that is unwelcoming. Swearing is already not condoned by KDE, but going to the far other end, an academic style where neither writer nor reader is acknowledged might give the idea that the text is far more complex than necessary, and thus scare away users.

Avoid using GIFs (open for debate)

The reason is that people with epilepsy may be affected by fast moving images. Similarly, GIFs can sometimes carry too much of the burden of explanation. If you can't help but use GIFs, at the least notify the reader of this in the introduction of the page.


This consists of using SVG for infographics, and using the appropriate markup for a given text.


  • We would like to discourage photos and traditional paintings in the manual if they are not illustrating a concept. The reason is that it is very silly and a little dishonest to show Rembrandt's work inside the Krita GUI, when we have so many modern works that were made in Krita. All of the Pepper&Carrot artwork was made in Krita and the original files are available, so when you do not have an image handy, start there. Photos should be avoided because Krita is a painting program. Too many photos can give the impression Krita is trying to be a solution for photo retouching, which really isn't the focus.

  • もちろん、光沢のつけ方やライティング(lighting)など、写真やマスター・ペインティングの中にある種の概念を示したいと思っています。この場合は、絵や画家の名前、または写真であることを示す見出しを追加します。

  • Photobashing を使用してもよいですが、Photobashing の話題に限ります。(訳注: Photobashing : 写真をイラストのように編集した作品のこと)


  • 画像内へのテキスト挿入は避け、代わりに見出しを使用します。これを行うには figure コマンドを使用します。

  • テキストを使用する必要がある場合は、テキストデータを簡単に差し替えできるように SVG で挿入するか、最小限のテキストを使用します

  • 高品質で魅力的な画像を作ってみましょう。みんなに Krita でお絵描きをする発想を与えましょう!

  • マニュアルは GDPL1.3 の下でライセンスされているので、提出された画像はそのライセンスが適用されることを覚えておいてください。「CC-By-Sa/CC-By」の場合は、ファイルにライセンス表示が適切に行われているか確認してください。もちろん、どちらのライセンスでも使用できない画像は提出しないでください。




テキストの追加と削除は draft ブランチで行います。

古いページの見直しはバグ修正と見なされるため、master ブランチに取り込まれ、必要に応じて draft ブランチにマージされます。

draft ブランチをマージする前に、次の操作を行います:

  • master ブランチに古いバージョンのタグが付けられます。

  • draft ブランチは初めにバージョン番号が更新されたことと、epub cover が更新されたことをチェックします。

draft ブランチは、リリースの前日までマージされず、元のページを長く保ちます。

それぞれのリリースには、リリースの作業の一部としてアップロードされた、epub のバージョンがあります。……どこから POT ファイルを取得すればいいのでしょうか?翻訳されたバージョンも?



  1. 最初に非推奨とマークされます。


    .. deprecated:: バージョン番号
  2. 'deprecated'というページにリンクされます

  3. 次のバージョンに移行すると、非推奨項目としてリンクされているすべてのページが削除されます。


  1. 正しい位置であることを確認します。

  2. Krita マニュアルのマークアップ規約 に従って、ページが正しく構成されていることを確認してください。

  3. 目次へページを追加します。

  4. 新機能は versionadded:: で追加します

    .. versionadded:: バージョン番号

画像の場合と同様に、許可のないテキストは追加しないでください。つまり、テキストは自分が作成したものか、テキスト作成者の許可が必要です。マニュアルは GDPL1.3+ ライセンスなので、追加されたテキストは再ライセンスされます。



機能が変更されたときに、ページを変更してコミットする場合は、レビューなしで変更をプッシュできますが(レビューがないと不安な場合は除きます)、add:: を使用するべきです。

.. versionchanged:: バージョン番号


いずれの場合も、上部の metadata の項目で著者として自分を追加するかどうかを確認します。

(非推奨の方法です)バージョン番号として versionadded と versionchanged を使用すると、マニュアル内で grep を使って次の用語を簡単に検索できます:

grep -d recurse versionadded * --exclude-dir={_build,locale}





最も重要なのは、人が行った変更をレビューすること です。これを KDE_gitlab で行うには2つの方法があります:

  1. マージリクエストをレビュー


    マージ(merge)は、文書内で行われた変更(追加、削除)をデバイスが読み取り可能なファイルにまとめます。誰かがレビューリクエスト(Gitlab や Github のようなシステム上では"Merge Request"や"Pull Request"と表記)を提出した場合、元のファイルの管理者はそれらを確認し、変更が必要な点についてコメントする必要があります。これにより、タイプミスや複雑になりすぎている書き方のようなものだけでなく、間違っている点についてもコメントできます。リクエストが受け入れられると、文書変更が反映されます。

  2. マニュアルへの変更に対してコメントする。

    コメントの変更は fact の後に行われます。変更にコメントするには、commit message に移動します(リポジトリページから history に移動し、コメントしたい項目をクリック)。このページでは、行った変更にコメントすることができます。



変更を行う に従って、ページのアクセス権を得て編集できるようにします。


マニュアルの翻訳は KDE localization community で行われています。翻訳作業に参加するには、翻訳者用サイトにアクセスし、translation teams のリストから翻訳したい言語を選択し、表示されたページの指示に従って他の翻訳者と連絡を取ります。

KDE のローカライゼーションに参加するためのもっと一般的な説明に関しては、 を参照してください。

翻訳チームは、このマニュアルの PO ファイルにアクセスできます。PO ファイルは、POEdit や Lokalize などの翻訳用ツールで使用されるファイル形式です。翻訳チームは協力してこれらのファイルを翻訳し、翻訳用 SVN にアップロードすることができます。そこから特殊なスクリプトが SVN から翻訳を受け取り、マニュアルデータの配置場所に持ってきて、毎日反映させます。

翻訳チームが画像も翻訳で差し替えたい場合は、独自の画像を使用できます。デフォルトでは、画像フォルダ内のすべてのイメージが「en」になります。特定の画像を翻訳する場合は、画像フォルダの場所に移動し、言語コード(訳注:日本なら「ja」)を名前に含むフォルダを追加して、翻訳バージョンの画像を追加します。例として、Sphinx は次のように画像ファイルのオランダ語版を検索します /images/Pixels-brushstroke.png/images/nl/Pixels-brushstroke.png または、/images/dockers/Krita-tutorial2-I.1-2.png/images/dockers/nl/Krita-tutorial2-I.1-2.png

完成した翻訳ファイルをウェブサイトに反映させるには、ウェブサイトの更新手順にファイルが追加される必要があります。翻訳の状態に自信のある翻訳チームは、kimageshop のメーリングリスト(または を通じて主要な Krita 開発チームに連絡し、翻訳を完了する必要があります。


reStructured Text の規約に関しては、Krita マニュアルのマークアップ規約 を確認してください。