MediaWiki ハッカーになる方法

Jump to: navigation, search
This page is a translated version of the page How to become a MediaWiki hacker and the translation is 42% complete.

Outdated translations are marked like this.
Other languages:
العربية • ‎български • ‎dansk • ‎Deutsch • ‎Ελληνικά • ‎English • ‎español • ‎فارسی • ‎français • ‎magyar • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎한국어 • ‎Nederlands • ‎occitan • ‎ਪੰਜਾਬੀ • ‎polski • ‎português • ‎português do Brasil • ‎română • ‎русский • ‎српски / srpski • ‎svenska • ‎ไทย • ‎Türkçe • ‎Tiếng Việt • ‎中文
この記事が執筆されたのは、開発の初心者が MediaWiki の開発に貢献するのに必要なスキルを学習するのを支援するためです。

あなたが経験を積んだ開発者である場合は、代わりに 開発者ハブDeveloper hub を参照してください。


MediaWiki は、ウィキペディアとその姉妹プロジェクト群や世界中の数多くのウィキを支えるソフトウェアです。 多くのオペレーティング システムで動作します。PHP で書かれており、主に MySQL データベース サーバーを使用し、クライアント側の JavaScript ライブラリとして jQuery を使用します。 MediaWikiの開発は主にウィキメディア財団によってサポートされていますが、ボランティアコミュニティの開発者たちもまた大きな役割を果たしています。

このページはMediaWikiの貢献者となるために役立ちます。 これはチュートリアルではありません。ここでは、あなたが必要なことを学ぶことができる場所を示すだけです。


始めるには[[開発者アクセスDeveloper access|開発者アクセス]]に登録し、Gerritのチュートリアルを読んでください。

その後に、コードをダウンロードしたり変更、テスト、パッチの送信が可能になります。 開発環境を準備するには、あらかじめ設定された仮想マシン(vagrant)を使用する方法とマニュアルで行う2通りがあります。

Vagrant で仮想マシン[edit]

  • Vagrantのインストール - これにより、Linux仮想マシン上でMediaWikiサーバーの準備が完了します(ホストはLinux、Windows、Macいずれも使用可能です)


MediaWikiの機能開発を行うために、Wikipediaデータベースダンプをダウンロードする必要はありません。 実際には、多くの場合いくつかの特別な細工をしたテストページに近い空のデータベースを使用するほうが簡単です。 しかしながら、もし何らかの理由でWikipediaのコピーがほしいのならばダンプを入手することができます。




Watch as a developer fixes a bug, including investigation, git commit, getting it reviewed and merged, and closing the Bugzilla ticket (now replaced by PhabricatorPhabricator).
  • MediaWikiの開発を開始する場合は、主に、既存のコードの厄介な小さなバグを修正するか、MediaWiki拡張機能を使って新しい機能を追加するという2つの方法があります。


  • You are expected to do some basic research yourself first: Look at the code, try to get some understanding what it is supposed to do, read related documentation, try to find the probable place(s) where you need to make changes in order to fix the bug.
  • If you have general questions about infrastructure, the software architecture or workflows which are not tied to the specific bug that you want to work on, use generic channels like IRCIRC, mailing lists, or wiki discussion pages. For example, if you have a problem with Gerrit, the Gerrit discussion page could be a good place to ask.
  • If you have a specific question about the bug itself, comment in the corresponding bug report (normally a task in PhabricatorPhabricator). "What do I have to do to fix this bug?" is not a good question to start with: The more specific your questions are, the more likely somebody can answer them quickly. If you have no idea at all how to fix the bug, maybe that bug is not (yet) for you - please consider finding an easier one first.
  • When asking, elaborate what you have tried and found out already, so others can help at the right level. Try to be specific - for example, copy and paste your commands and their output (if not too long) instead of paraphrasing in your own words. これにより誤解を回避できます。
  • Avoid private email or support requests in our social media channels.
  • Please be patient when seeking input and comments. On IRC, don't ask to ask, just ask: most questions can be answered by other community members too if you ask on an IRC channel. If nobody answers, please ask on the bug report or wiki page related to the problem; don't just drop the question.
  • コミュニケーションCommunication についてもっと詳しく知ります。
  • You can ask at the weekly Technical Advice IRC Meeting on #wikimedia-tech

Communicate that you work on a bug[edit]

You do not need to ask if you can work on a bug. You do not need to be set as the assignee in a bug report or announce your plans before you start working on a bug, but it would be welcome. At the latest when you are close to creating a patch for the bug, it is good to announce in a comment that you are working on it. Your announcement also helps others to not work on the bug at the same time and duplicate work.

Also note that if a bug report already has a recent link to a patch in Gerrit and has the project "Patch-For-Review" associated, you should choose a different bug to work on instead - avoid duplicating work. If the patch in Gerrit has not been merged and has not seen any changes for a long time, you could also pick up that existing patch and try to improve it.

If you stop working on a task you should remove yourself as the assignee of a bug report and reset the assignee to the default assignee, so others know that they can work on the bug report and don't expect you to still work on it.

By communicating early you will get more attention, feedback and help from community members.

Working on extensions[edit]

If you choose to work on MediaWiki extensions code, the following links provide more information.

MediaWiki extensions primers
MediaWiki 拡張機能のリソース

Hands-on suggestions[edit]


Phabricatorにおいて、タスクの右上の角 (バグレポート) に表示されるのは、問題が起きた製品とコンポーネントです。 ここからコードが属するGitリポジトリのヒントがわかり、もしもっと「広い」視点で議論したい場合、どの開発担当と相談すればよいか予想が付きます (バグレポートは、そのレポートに特定した問題に限定してコメントを書いてあるべきです)。



PyWikibotMediaWikiのボットを書くためのPythonに基づくフレームワークです。 開発に関する一般的な質問はPywikibotメーリングリスト#pywikibot IRCチャンネルで尋ねましょう。


マルチメディアに関する一般的な質問はマルチメディア・メーリングリスト#wikimedia-multimedia IRC channelで尋ねましょう。


ウィキメディアのウィキにアクセスできる携帯機器のアプリケーションは多数あります (Android、iOS、Windows Phone等…)。 全般的な開発の情報を読んでから質問はモバイル・メーリングリスト#wikimedia-mobile IRCチャンネルで尋ねましょう。


閲覧担当は私たちの読者に役立つソフトウェア作りをしています。 またモバイルのウェブ体験を管理しています。 一般的な開発の情報を読んでから質問はモバイル・メーリングリスト#wikimedia-mobile IRCチャンネルで尋ねましょう。


Wikidataはウィキ間のレファレンスや統計情報など構文情報に関する集中知識ベースです。 一般的な開発の質問はWikidata メーリングリスト#wikidata IRC チャンネルwikiで尋ねましょう。




自働ブラウザーテストはウィキメディアの技術者が利用者に面した高品質のソフトウェア作りを補助します。 使われる技術の詳細と参加方法はブラウザー試験のページを読んでください。 一般的な情報は品質の保証へ。

言語技術 (ローカライゼーション/翻訳/国際化)[edit]

言語技術の一般的な質問はmediawiki-i18n メーリングリスト#mediawiki-i18n IRC チャンネルで尋ねましょう。


VisualEditorは、MediaWikiにおけるWYSIWYGエディターです。 ビジュアルエティターの開発の一般的な質問はwikitechメーリングリスト#mediawiki-visualeditor IRC チャンネルで尋ねましょう。

ビジュアルエディターはウィキテキストのパーサーとランタイムで稼動する Parsoidです。 Parsoid開発の一般的な質問はウィキテキスト・メーリングリスト#mediawiki-parsoid IRC チャンネルで尋ねましょう。

発見 / 検索[edit]

Discovery担当は無記名の発見から信頼のできる関連の知識ソースへのパスを作ります。 一般的な質問はDiscoveryメーリングリスト#wikimedia-discovery IRC チャンネルで尋ねましょう。


問題解析担当はウィキメディアにおいてデータに基づく意思決定の権限を与え支援します。 一般的な質問は問題解析メーリングリストで尋ねましょう。


デザインのバグもしくはリクエストの修正にはベクターの画像アプリケーションを使いこなせる現在のグラフィック技術が必要です (たとえばInkscape)。 CSSの基礎知識も調整に役立ちます。 一般的な質問はデザイン・メーリングリスト#wikimedia-design IRC チャンネルで尋ねましょう。


外装は利用者がMediaWikiのルックアンドフィールをカスタマイズできるようにします。 CSSとPHPの基礎知識が役に立ちます。 それぞれの外装と連絡先の詳細はPhabricatorのプロジェクトページをチェックしてください。


MediaWikiもしくはエクステンションのシステムメッセージはしばしば英文に細かい訂正が必要ですが、翻訳とは対照的に、ソーステキストは開発者しかコードの変更を許可されません。 そのため通常は簡単な訂正が大幅に遅れてしまいがちです (たとえば誤字の訂正など細かいものも含む)。

さらに、メッセージの多くは不明瞭で文書の改良が必要です (Localisation#Message 文書化を参照)。 不足した説明文書は他の翻訳と同じように、translatewiki.net上でメッセージの/qqqサブページを編集するだけで追加できますが、場合によってはメッセージの内容を理解するにはコードを勉強する必要があります。つまり翻訳者にとってコードの知識を増やすことは最適条件であり、たいへん役に立つものです (その技能を身につけていない場合)。



Collaboration担当のプロジェクトに関する質問は#wikimedia-collaboration IRC チャンネルで尋ねましょう。


コアなソフトウェアはMediaWikiで基本的なウィキの機能を提供します。 PHPで記述され複雑で、エリアによってはメンテナンス権限が不明です。 一般的な質問はwikitech メーリングリスト#wikimedia-dev や #media wiki IRC チャンネルで尋ねましょう。


Phabricatorはウィキメディアでプロジェクト管理やバグ報告、機能のリクエストのために使われます。 Phlogistonは一連のSQL、Python、R scriptsから成り立ち、Phabricatorデータ、なかでも暴走報告および予測をレポートします。

Semantic MediaWiki[edit]

Semantic MediaWiki is one of the biggest and most popular MediaWiki extensions.


Maps is a popular MediaWiki extension that allows for, amongst other things, embedding of dynamic maps into wiki pages


まだ疑問がありますか? 見てまわれる分野はまだあります。MediaWikiには何百ものエクステンションツールがあるのです! 新しい貢献者にお勧めのバグの全リストはこちら。

何か困ったことや疑問がある場合、IRC経由もしくはお気軽にSrishti SethiあるいはAndre Klapperに助言を求めてください。


MediaWiki contributors at work in Bangalore, India.


MediaWiki is written in PHP, so you'll need to get familiar with PHP to hack MediaWiki's core.

Learn PHP
  • PHP のチュートリアル — Available in many different languages. If you have no knowledge of PHP but know how to program in other object-oriented programming languages, PHP will be easy for you to learn.
  • PHP Programming at Wikibooks.
  • PHP topic at Wikiversity.
PHP のリソース
Stuff to know
  • The script maintenance/eval.php in MediaWiki provides a basic PHP interpreter with MediaWiki objects and classes loaded.


Many features require some amount of database manipulation, so you'll often need to be familiar with MySQL/MariaDB.

Learn MySQL/MariaDB
MySQL/MariaDB リソース
Stuff to know
  • Test your code with MySQL/MariaDB.
    • MediaWiki currently uses MySQL and MariaDB as the primary database back-end. It also supports other DBMSes, such as PostgreSQL and SQLite. However, almost all developers use MySQL/MariaDB and don't test other DBs, which consequently break on a regular basis. You're therefore advised to use MySQL/MariaDB when testing patches, unless you're specifically trying to improve support for another DB. In the latter case, make sure you're careful not to break MySQL/MariaDB (or write queries that are horribly inefficient in it), since MySQL/MariaDB is what everybody else uses.

JavaScript と CSS[edit]

JavaScript and CSS have become omnipresent in front-end code. You don't have to be familiar with JavaScript, jQuery and CSS to work on MediaWiki, but you might need to, depending on what you choose to work on.

Learn JavaScript and CSS
JavaScript と CSS のリソース


The MediaWiki code base is large and some parts are ugly; don't be overwhelmed by it. When you're first starting off, aim to write features or fix bugs which are constrained to a small region of code.

MediaWiki primers and must-reads
MediaWiki のリソース