Help:Extension:Translate/Developer guide/ja

Translate 拡張機能は、数百のクラスからなる大規模な拡張機能です. このページでは、コードに手を加える開発者のためのガイダンスを提供します. このページとリンク先の文書を読めば、Translate のコードがどのように構成され、どのような特別な規約が使用されているか、よりよく理解できるはずです. 一般的な MediaWiki の開発方針、コーディング規約、Gerrit や Phabricator のようなツールの使い方は範囲外です. これらの話題は既にご存知だと思いますが、Translate に適用される場合、ここでは繰り返しません.

Translate 拡張機能では、多くの大規模な移行が同時に進行しています. ここでは、現在進行中の主な移行を列挙し、新しいコードにどのスタイルが好ましいかを詳しく説明します. 一般に、既存のコードを修正する場合は、現在のスタイルを維持し、移行は別に行うのがいいでしょう. コードを触るときにやってもいい小さなクリーンアップもあります.

名前空間の移行
現在、すべての Translate のコードを名前空間  配下に移行しているところです. すべての名前空間付きコードは、 ディレクトリ配下に置かれます. 新しい PHP ファイルは、すべて適切な名前空間に配置する必要があります. どの名前空間が利用できるようになるかのガイダンスは を参照してください. Namespaces are organized by domain, rather than function. Abbreviations should be avoided in namespaces and class names. Legacy code is in the repository root and various subdirectories.

Splitting tests into integration and unit tests
Previously there was no distinction of integration and unit tests. For new code, unit tests should be the main type of tests. Unit tests are placed under  directory matching the namespace layout. There is a Makefile in that directory to easily run all or parts of unit tests while developing.

Type declarations and comments
All new code should declare both parameter and return types. In addition strict types should be enabled using.

Thanks to type declarations, most function and method comments are now redundant, as they would only repeat the parameter names and types. For this reason, linter checks for missing parameter or return type declarations are disabled for code under  and , which roughly correlate with places using type declarations. For this code, do not add redundant documentation unless it provides additional value. One such example is to provide more accurate type hints for array types, for example:

As illustrated above, for comments having only one tag or one line description, do use the one line comment syntax as well.

Constructor dependency injection
New code should have all its dependencies injected via constructor. In many cases this is not yet possible, due to many services only being available in MediaWiki 1.35 (we currently support 1.34 and later) as well lack of ObjectFactory support for services. For such new code, place all dependencies on the class constructor (or main entry point to the class) to easy migration to constructor dependency injection in the future.

File header
For new code, we have chosen the following minimalistic header:

If you wish to assert your copyright more explicitly, you can optionally add @copyright tag as well.

Deprecation and version numbers
When changing Translate code in backwards incompatible ways, do check https://codesearch.wmflabs.org/search/ for any users of the code. Known users are TwnMainPage, TranslateSVG, CentralNotice, MassMessage and bunch of stuff in the translatewiki repo.

You can use the deprecation facilities provided by MediaWiki core, including the @deprecated tag and wfDeprecated hard deprecation. If there are no known users of the code, it is okay to change it in backwards incompatible way without deprecation, unless it is explicitly marked as stable (See Stable interface policy). Code marked as stable should be hard-deprecated at least for one MLEB release.

MediaWiki core version numbers are meaningless in the context of Translate, as Translate always supports multiple MediaWiki releases. Translate itself uses YYYY.MM style versioning (as part of MLEB). New classes and methods should be annotated with @since YYYY.MM tags.