Extension:Semantic Forms/ja

解説
Semantic Forms は、フォームを使用してデータを追加・編集・検索するための MediaWiki 機能拡張です. Semantic Forms は Semantic MediaWiki 機能拡張と密接に連携しており、セマンティックマークアップされた構造化データに対して使用されることを想定しています. Semantic Forms 機能拡張の前提条件として Semantic MediaWiki がインストールされている必要があります; Semantic Forms プログラムは Semantic MediaWiki (バージョン 1.4 以上) がないと動作しません.

Semantic Forms を簡単に説明すると、Wiki に データを追加・編集・検索するためのフォーム を 追加プログラムなしで 持たせることができます. フォームは管理者だけでなく、ユーザ自身で作成・編集することができます.

Semantic Forms 機能の主な要素として、フォーム定義ページがあります. フォーム定義ページは新しく追加された名前空間 'Forms:' に配置されます. フォーム定義ページはマークアップコードで記述され、ユーザがデータを追加・編集しようとする際に構文解析されます. フォームはこの定義ページで厳密に記述されるため、ユーザは実際にプログラムすることなく、自分自身でフォームを作成・編集できます.

Semantec Forms 機能拡張は、セマンティックデータを作成する際に テンプレート の使用を強制します. Semantic Forms はデータページにおいてセマンティックマークアップを直接サポートしません. その代わり、すべてのセマンティックマークアップはテンプレートを通じて間接的に保存されることになります. フォームにより、ページに対してテンプレートの定期済みセットを配置することができます（裏では、ページが保存されるとこれらのデータはセマンティックプロパティになります）.

フォームは、既存ページのデータを編集するためにも使用できます. また任意のページで 'edit with form' タブを有効にすることができます. The 'edit with form' tab を参照してください.

Semantic Forms はまた フィールドのオートコンプリート をサポートし、ユーザは与えられたフィールドに過去にどのような値が入力されていたかを容易に見ることができます. この機能は曖昧な名前やスペルミス等を防ぐ大きな助けになります.

ページにあるフォームに適合しないデータ（ページタイトルの自由書式テキスト記述等）は、フォームを使用してページを編集する際も無視されません. これらは "free text" と呼ばれる別の入力ボックスに配置されます.

Semantic Forms はまた、外部コードにより新しい入力型を容易に定義できるフックを提供します. このことはとりわけ、新しい機能拡張で記述されたコードを使用する入力型を定義する機能拡張にとって役立ちます.

Demantic Forms はまた他の機能を提供します: セマンティックプロパティを作成するためのフォーム、テンプレートを作成するためのフォーム、ユーザフォームを作成するためのフォーム、サイト上の全てのテンプレートおよびユーザフォームの一覧を表示するページ、他. 本文書は機能の全てを網羅しますが、特に 特別ページ セクションを参照してください.

このソフトウェアの開発の一部は ontoprise GmbH、Google (via the Google Summer of Code) 他の資金援助により行われています.

ダウンロード
Semantic Froms プログラムを入手するには、以下の 2 つの圧縮ファイルのどちらかをダウンロードしてください.


 * semantic_forms_2.0.9.tar.gz
 * semantic_forms_2.0.9.zip

または、MediaWiki ソースコードリポジトリ http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SemanticForms/ から SVN を使用して Semantic Forms プログラムをダウンロードすることも可能です. コマンドラインから以下のコマンドを実行します:

svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SemanticForms/

インストール
繰り返しになりますが、Semantic Forms をインストールする前に、Semantic MediaWiki をインストールしておく必要があります.

圧縮ファイルの解凍もしくは SVN からのダウンロードにより作成された 'SemanticForms' ディレクトリを、MediaWiki 'extensions' ディレクトリに配置してください. 次に、MediaWiki メインディレクトリのファイル LocalSettings.php に、以下の行を、Semantic MediaWiki 機能拡張を呼び出している行 ('include_once' 主定義行と 'enableSemantics' 行の両方) 以降 に追加してください:

著者
Semantic Forms の作成および大部分の記述は Yaron Koren (連絡先: yaron57 -at- gmail.com) により行われました. jQuery および関連 Javascript 機能の初版は Sanyam Goyal により 2010 Google Summer of code の一部として作成されました. Stephan Gambke もまた Javascript コードのかなりの部分に対して貢献しました. Daniel Friesen、Eugene Mednikov、Harold Solbrig、Jayson Harshbarger、Jeffrey Stuckman、Louis Gerbarg、Matt Williamson、Nils Opperman、Remco de Boer、Sergey Chernyshev および wheresmytab もまた、重要なコードへの貢献を行いました.

バージョン
Semantic Forms の最新バージョンは 2.0.9 です. 全ての改版履歴については version history 参照してください.

サポートする言語
Semantic Forms は 100 以上の言語をサポートしています. 主要言語はほぼ全てサポートされます.

コード構造
Semantic Forms ファイルの完全な一覧とそれぞれのファイルの概要については Extension:Semantic Forms/Code structure を参照してください.

各ファイルのコードや改版履歴等の参照は、ここ でオンラインで行うことができます.

特別ページ
この機能拡張は数多くの MediaWiki "特別" ページを定義します:


 * Special:CreateForm - データを追加・編集するための新しいフォームを作成します. (See example of page)
 * Special:CreateTemplate - 新しいテンプレートを作成します. (See example of page)
 * Special:CreateProperty - 新しいプロパティを作成します. (See example of page)
 * Special:CreateCategory - 新しいカテゴリを作成します. (See example of page)
 * Special:CreateClass - ある "クラス" の全ての要素 (プロパティ・テンプレート・フォーム・カテゴリ) を一度に作成するためのページです (See example of page). このページへのアクセス権は 'createclass' MediaWiki パーミッションにより規定されます; 初期状態では全てのログインユーザがアクセスできます.
 * Special:FormEdit - ユーザ定義フォームを使用してページを作成または編集します. (See example of page.)
 * Special:FormStart - ユーザを 'FormEdit' または 関連ページの "edit with form" タブに誘導するために使用します. このページはユーザが直接アクセスすべきではありません.
 * Special:Forms - サイトの全てのフォームページの一覧を表示します. (See example of page)
 * Special:RunQuery - lets a user run a query, using a form (See example of page)
 * Special:Templates - lists all templates on the site. (See example of page)
 * Special:UploadWindow - lets a user upload a file; very similar to the standard Special:Upload page, but without the skin. This page is called from within a form, and should not be accessed directly by users.

スタートガイド
以上であなたのサイトには、必要なソフトウェアは全てインストールされています. さて次に何をしますか? 次のステップでは、データを保持し表示するための構造を作成します. この構造定義により、データを作成し編集できるようになります. ありがたいことにこれらの全ては、単にさまざまな Wiki ページを作成するだけで行うことができます. 必要な手順は以下の通りです:


 * データ構造を理解する.  どのような形式のページをサイトに配置するか? どのようなデータを各ページに記録するか?  これらは全て後からでも変更できますが、最初に設計しておいたほうが良いでしょう.


 * プロパティを作成する.  意味的サイトを構成する基本ブロックのひとつにデータ間結合があり、これを Semantic MedhiaWiki ではプロパティと呼びます. プロパティは当該ページのトピックに関する個々の情報を規定するために用いられます. プロパティには固有値か、Wiki ページ名が入ります. 全てのプロパティは Wiki の "Property:" 名前空間のページとして定義します. プロパティを作成するには 'プロパティ作成' 特別ページを使うのが最も簡単です (上記参照).


 * テンプレートを作成する.  テンプレートはページにおけるデータの表示を設定し、データを実際の意味的情報に変えるためにタグを保持し、(しばしば) あるカテゴリに分類されることを定義し、従ってあるページタイプであること. 一般的にページタイプあたりひとつのテンプレートがあり、時々単一のページタイプがひとつ以上のテンプレートを含むにもかかわらず. テンプレートはまた集合のためにも使用される、このページと一定の関連を持つ他の全てのページのリストを表示することにより (この詳細については インラインクエリ 文書を参照のこと). テンプレートを作成するには 'テンプレートの作成' 特別ページを使うのが最も簡単です (上記参照).


 * フォームを作成する.  これでやっとフォームを作成して、様々なタイプのページを簡単に追加・編集することができます. ページタイプあたりにひとつのフォームがあるべきです: あるフォームはこのページタイプを含むひとつまたは複数のテンプレートを殖民すべきです. 以前の通りに、新しいフォームを作成するための特別ページがあります: 'フォームの作成' (上記参照). フォームを定義するための特別なマークアップ言語に関する文書は以下を参照してください. ひとつの一般的要請はこれらの 3 つの特別ページ ('プロパティ作成'、'テンプレートの作成'、'フォームの作成') を既存のプロパティ/テンプレート/フォーム ページを編集できるようにです、新しいのを単に作成するのではなく. しかしながら、これは単に新規ページを作成するより実装するのがプログラム的により困難です、なぜならこれには構文解析が必要だから. 当分の間、既存のプロパティ・テンプレート・フォームを更新するには手動で行わねばなりません. 言い換えれば、プロパティ・テンプレート・フォームページへ行き (これらは特別ページに一覧されます)、更新したいものを選択します. 編集タブをクリックするとしたいことをすることができます、ソースコードを編集することにより.


 * カテゴリを作成する.  各フォーム中のひとつのテンプレートは一定のカテゴリに属するものとして作成されるフォームの各記事を定義すべきです. あなたはそのような各カテゴリに対してひとつのページを作成すべきで、それに対する既定フォームを既定する、それにより全ての記事は自動的にそれを作成した同じフォームで編集可能になります. そのためには 'カテゴリを作成' 特別ページを使うのが最も簡単です (上記参照).


 * フォームへのリンクを有効化する.  既定フォームを持つカテゴリを作成するのと平行して、ユーザに対して作成したフォームへのアクセスを有効にしなければならないという別のステップがあります. これらはサイドバーまたは他の場所にデータを追加するためのリンクを追加することや、プロパティに対する既定フォームおよび代替フォームを設定する、それらを作成するフォームを指し示す存在しないページへの赤リンクを持たせることを含みます. これらのアクションは以下の節で説明します.


 * データを追加する.  さらにサイトにデータを追加すべきです、新しいフォームを使用して、フォーム、テンプレート、カテゴリは期待したとおりに動作していることを確認するために.


 * サイドバーまたは他の場所にリンクを追加する.  サイドバー (英語 Wiki では、ページ "MediaWiki: Sidebar" で編集できます) はデータタイプの各々へのリンクを保持すべきで、これらデータタイプの各々へのカテゴリへのリンクも同様です. このようなリンクをメインページやその他の場所に含むことができます.


 * カスタマイズする.  いったん構造が配置されると、全てを望むようにカスタマイズできます - Wiki 全体、さまざまなテンプレート、フォームの外観を変更したり、フィールドを追加、変更したり、クエリに対してインラインクエリを変更したり、等です.

...逆に言うと、プロパティ、テンプレート、フォーム、カテゴリを別々に作成する代わりに、'クラスの作成' 特別ページを使用して これら全てを一括作成 できます (上記参照). このページは、これらの全てのページを別々に作成するよりもさほど柔軟には使えませんが、より早く行えます.

例
稼働中のこの手順を見るには、example の実際の Wiki に対してこれらのステップをどのように実行するかを参照してください.

クイックリファレンスガイド
Semantic MediaWiki、Semantic Forms、およびその他多数の機能拡張の、印刷に適したの両面ページタイプのクイックリファレンスガイド（あるいはチートシート「早見表」）があります. ここ から、PNG（画像）、PDF および SVG フォーマットのガイドが見つかります.

フォームマークアップ言語
フォームはテンプレートとテンプレート中のフィールドを規定するタグの集合を使用して定義されます. Wiki テキスト、およびいくつかの HTML、はタグ外のどこでも自由に埋め込むことができます. 使用可能なタグは:

フォームに関する特別情報を保持します. このタグはオプションですが、使用する場合はフォームの先頭に配置すべきでしょう. このタグで使用可能なパラメータは:

テンプレート名を指定し、また後に続く全てのフィールド (end template に達するまで) がこのテンプレートに属することを宣言します. for template 宣言の直後の名前はテンプレート名です. このタグで使用可能なパラメータは:

テンプレート範囲を終了します. このタグにはパラメータはありません.

フォームに配置するフィールドを指定します. このフィールドはテンプレートフィールドに対応しており、field 宣言子の直後にテンプレートフィールド名を記述します. このタグで使用可能なパラメータは以下の通りです:

One of eight inputs that usually appear in every form. The text immediately after "standard input&#124;" is the name of each input. The most notable of these inputs is 'free text', which is a textarea that holds all the non-template text in a page. The other seven are form elements such as the "Save" and "Preview" buttons; see Defining the bottom of the form for the full list.

For the 'free text' input, the allowed parameters are rows, cols, hidden, restricted, default and preload</tt>. The first five work just as they do for field</tt> declarations. The new parameter is;

For the other standard input types, the only allowed parameters are

データ型で使用可能な入力型
各定義済み Semantic MediaWiki データ型は、それぞれ既定入力型を持ち、そのうちいくつかは既定入力サイズを同様に有します. さらに、いくつかのデータ型は、フィールドが単独値のかわりに区切り一覧値を取扱う場合に特殊処理を行います.

以下各単独値に対するデータ型の既定及び他の可能な入力型です:

And here are the default and other allowed input types for delimited lists of a certain data type, enabled by the use of the "#arraymap" function:

In addition, several other extensions define additional form input types: most notably, Semantic Maps defines map inputs for properties of type Geographic coordinate, while Semantic Forms Inputs defines a 'datepicker' and 'simpledatepicker' input for dates and a 'regexp' input for regular strings.

オートコンプリート
One of the big strengths of Semantic Forms is that it supports autocompletion - you can enable a field to show a dropdown list of possible completions when the user starts typing. Semantic Forms' autocompletion is enabled by the jQuery UI Javascript library's Autocomplete plugin.

If a field represents a semantic property of type "Page", autocompletion will be enabled by default - the field will autocomplete on the names of all pages that are already pointed to by that property. For fields representing a semantic property of type "String", there is no default autocompletion, but you can achieve this same effect simply by adding the parameter "autocomplete" to the field's definition. You can also autocomplete on other sets of values:
 * to autocomplete on all the values of a specific property, add "autocomplete on property=property-name" to the field definition
 * to autocomplete on the names of all pages in a category, add "autocomplete on category=category-name"
 * to autocomplete on the names of all pages in a namespace (like "File"), add "autocomplete on namespace=namespace-name" (if you want to autocomplete on the main namespace, just add "autocomplete on namespace=").
 * finally, you can autocomplete based on the values in an external URL; which lets you get autocompletion values from essentially any outside system. See Autocompleting on outside values for how to do this.

If a field is specified to hold multiple values (see below), autocompletion will, by default, support multiple values: after a value is entered, and a delimiter placed, a new autocompletion will start for the next value. You can manually specify that a field should have multiple-value autocompletion, by adding the "list" parameter to the field's definition. You can also specify the delimiter for this list of values, using the "delimiter=..." parameter (the default is a comma).

The set of a field's possible values for autocompletion is, by default, contained right within the form's HTML page, in a Javascript declaration. For performance reasons, there is a limit to how many values can be placed in the page; this number is defined by the variable $sfgMaxAutocompleteValues, which by default is set to 1000. If you have more than this number of possible values for a field, you may want to use remote autocompletion instead, where autocompletion happens through an Ajax call to the server, based on what the user has typed. This type of autocompletion is slower, but always returns a comprehensive set of results. You can enable this by adding the "remote autocompletion" parameter to the field's definition.

By default, Semantic Forms autocompletion matches on the beginning of every word in the set of possible values. However, you can change autocompletion to instead match on every character, by adding the following line to LocalSettings.php: This feature is especially important for wikis that have values with non-ASCII characters, such as wikis in languages with non-Roman alphabets; since the default, word-based autocompletion doesn't yet work with non-ASCII characters.

Finally, you can disable autocompletion, if it's enabled by default for a field, by adding the parameter "no autocomplete" to the field's definition.

コンボボックス入力
For any input that has autocompletion for a single value, you can set the input to be a combo box by setting "input type=combobox" in the field definition. This input functions like a regular autocomplete field, but has an additional down-arrow icon, like that of a dropdown, to let the user see all the available values at once.

複数値を持つフィールド
一般的なシステムでは、ユーザに複数の値を入力させることができるフィールドを持つものがよくあります. SMW でも、テンプレートのあるフィールドに、カンマまたは他の文字列で区切られた複数の値を保存できます. これはテンプレートに、区切り記号で区切られた文字列部分のマッピングを指定する '#arraymap' Semantic Forms パーサ関数を記述して行います. この関数の一般的な構文は以下の通りです:

 </tt>

この関数は値を区切り記号で分離し、その各々に '式' による同一のマッピングを適用して '変数' に代入し、最後に新しい区切り記号で全ての部分を結合します. 例えば、ここに 'author' フィールドを生成するフォームがあるとします. このフィールドの、カンマで区切られた文字列のそれぞれに意味的プロパティ 'Has author' を持たせたい場合は、通常の意味的タグの場所に以下のテンプレートコードを記述します:

 </tt>

簡単に言うと、この関数はフィールドのカンマ区切り値にプロパティタグを 'マッピング' するものです. 特に設定しなければ、"区切り記号" の既定値は "," で、新しい区切り記号の既定値は ", " となります. この機能により、ユーザは 1 行に全ての値を、カンマで区切って入力することができます. カンマの前後に空白があっても構いません. （ここで、上記の例で内部変数に "x" を使用した点に注意してください. もしプロパティ名自身に文字 "x" が含まれていると問題が発生します. その場合は 文字 "x" を、プロパティ名に含まれない文字または文字列に変更してください. ）

もしテンプレートを作成する際に 'CreateTemplate' （'テンプレートの作成'）ページを使用する場合は、任意のフィールドに対して、複数の数値を入力可能にするためのパーサ関数を自動的に追加するオプションを設定できます.

ある種のマッピングは #arraymap 関数で記述するには複雑すぎる場合がありますが、その場合は #arraymaptemplate 関数を代わりに使用できます. この関数を使用する際には、1 つのフィールドを引数として受け取り、フィールドに対して希望のマッピングを行うテンプレートを準備します. 次に主テンプレートのフィールドに、#arraymap の場合同じように #arraymaptemplate 関数を適用します. この場合の構文は以下の通りです:

 </tt>

上記の 'テンプレート' には、先ほど言及したマッピングテンプレート名を記述します.


 * 1) arraymap と #arraymaptemplate のどちらにおいても、'区切り記号' および '新しい区切り記号' 中に記述された文字列 "\n" は改行に変換されます.  これは記憶しておくべきですが、値と値の間で実際に画面上で改行させたい場合は、改行記号を 2 つ （すなわち "\n\n" を） 挿入する必要があります.  これは MediaWiki では、画面上で改行表示させるためには、記事上では 2 つ連続で改行させる必要があるためです.

複数インスタンステンプレート
If you add the 'multiple' parameter to a template, it will allow for multiple (or no) instances of this template in the form, and therefore in the generated page. The sample form below, for the 'Item' form, contains two such templates. If you look at the form that this definition generates, you can see that there are two buttons labeled "Add another". Clicking on either of these will create a new instance of that template and its field(s). Instances can be rearranged, by clicking on the icon on the right-hand side and dragging the instance up or down within the set.

You can rename the "Add another" button to any other text, using the "add button text=" parameter. For instance, to change the button to read "Add another occupation" for a template called "Occupation", you could have " ".

If you want to semantically store all the data contained in these multiple-instance templates, it is recommended to use the Semantic Internal Objects extension.

ファイルのアップロード
If a field in the form is meant to hold the name of an uploaded file (say, an image), you can allow users to upload this file directly through the form. This is done simply by adding the parameter "uploadable" to that field's declaration in the form definition. This will add a link reading "Upload file" next to this field in the form; if the user clicks on this link, it will pop up a "lightbox"-style window (using the FancyBox Javascript library) that lets the user upload a file. Once the user has done so, the window will close, and the field will contain the name of the uploaded file. If the field is configured to contain a list of values, the new file name will be appended to whatever was there before; otherwise, the file name will overwrite whatever the field contained before.

For uploadable fields, you can also set the default filename of the uploaded files, by setting the "default filename=" parameter in the field definition. The value of this parameter can also include the variable " ", which gets substituted with the name of the page being added or edited. So adding to the field definition the parameter "default filename=Image for ", for instance, for a page called "Abc", would set the default name of any uploaded file to "Image for Abc".

You can see a demonstration of file uploading here.

カテゴリ入力
Two input types allow for a category-tree-style input: 'category' and 'categories'. 'category' is used for a single value in a field, and uses radiobuttons; while 'categories' is used for a multiple-value field, and uses checkboxes. Both input types use the code of the MediaWiki CategoryTree extension, so this extension must be installed for these inputs to work.

You also need to specify an additional parameter:
 * - sets the name of the category at the top of the "tree".

You can also optionally set the parameters:
 * - sets the height in px (pixel) of the box in which the category tree appears.
 * - sets the width in px (pixel) of the box in which the category tree appears.
 * - sets the delimiter when using 'categories'. Default is ','.

It should be noted that these two input types print only the names of the categories selected, without the "Category:" namespace before it; so if you want that to show up in the page as well, the template will have to add it.

If the field specifies multiple categories, and the template uses #arraymap to do it, the call to #arraymap should look something like:

...in other words, you need to specify the final "delimiter" parameter for #arraymap, and make it a space, blank or something similar, to avoid printing commas between the category tags.

You can see a sample form that uses the 'category' input type here.

フリーテキスト入力
'free text' 入力は、ページの全ての非テンプレートテキストを保持するテキストエリアをセットします. このフィールドの高さと幅および CSS スタイルは、他のテキストエリア入力の設定方法と同様に設定できます. もしフォーム定義から除外されている場合は、ページのフリーテキストはフォームの hidden フィールドに保持され、ユーザからは閲覧も編集もできません. フリーテキスト用の WYSIWYG エディタを使用することもできます. もし Wiki に MediaWiki FCKeditor extension がインストールされており、通常の '編集' ページに正しく表示されていれば、フリーテキスト入力にも自動的に表示されます （現時点では、フリーテキスト入力は FCKeditor が動作する唯一のフォームです）.

もし FCKeditor を使用しており、リンクが目障りに感じるなら、フォームで FCKeditor を無効にするためにリンクをはずすことができます. これは、以下の行を LocalSettings.php に追加します:

フォームエンド定義
The user inputs at the bottom of the form can be customized using the "standard input" tag. The layout, inclusion and text of each input can be modified. Each user input is defined as a "standard input" tag with its own value; the eight allowed values are:
 * "save" (for the "Save page" button)
 * "preview" (for the "Show preview" button)
 * "changes" (for the "Show changes" button)
 * "summary" (for the "Summary" text field)
 * "minor edit" (for the "This is a minor edit" checkbox)
 * "watch" (for the "Watch this page" checkbox)
 * "cancel" (for the "Cancel" link)
 * "run query" (for the "Run query" button in query forms)

So, for example, the button for "Save page" could be specified with " ", which would place the button where it was defined, with the text on the button reading "Save this page". If no  tags are included in the form definition, all six will appear at the bottom of the form, just as they do for regular "Edit" pages. However, if even one such tag is included, then only those inputs which have been included will be displayed, in the order, and with the wiki-text, that they appear in in the form definition.

サンプルフォーム
以下はディスコース DB における 'Item' フォーム定義ページ のソースコードです:

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;">

Topic:

Position:

Stance:

Item name:

Free text:

Note the presence of both wiki-text and some limited HTML (the 'div' tag) within the code. This markup was created using the Create Form page, and based around the templates Item, Opinion and Reference. You can see the working form at this add data page ; the form itself is created on-the-fly from the form definition file. In the 'Items' category page, if you click on any of the pages, you can see the 'edit with form' tab on the top right-hand side. If you click on that tab, you can see this same form, this time populated with the data contained in that page.

The 'wikiPreview' div tag, by the way, is included so that, when the user hits the "Preview" button, they'll be shown the preview directly within the form page, instead of being taken to another page.

データの追加
データの追加は通常、2 段階の手順を踏みます. ユーザはまずページ名を入力します. するとユーザは、追加フォームか編集フォームのどちらかへ自動的に移動します. どちらに移動するかは、当該ページが存在するかしないかに依存します. この仕組みにより、ユーザが不用意に既存ページを上書きすることを防止します. 以上に対して、もしフォームにユーザの入力からページ名を生成する数式を記述するなら、最初の手順を省略することも可能です.

2 段階手順
このやり方でユーザにデータを入力させるために、方法が 2 つあります:

1) 'forminput</tt>' パーサ関数を使用する – 任意のページにこのタグを記述して、ユーザに追加または編集するページのタイトルを入力させることができます. 'フォームの作成' ページで作成される全てのフォームには、この入力コントロールが既定で含まれています.  以下にこのタグの一般的な使用例を示します:


 * 引数は全て省略可能です. パラメータについて以下に簡単に説明します.
 * – 使用する SF form 名. この項目を空白にすると、既存フォームの一覧から選択するドロップダウンリストが表示されます.
 * – テキストボックスのサイズ （既定値: 25）.
 * – 入力ボックスの開始値 （既定値: 空白）.
 * – "submit" ボタンに表示されるテキスト （既定値: ブラウザ依存）.
 * – クエリ文字列としてフォームに渡したい値一式. この値はいわゆる URL クエリ文字列である必要があります.  例: "query string=namespace=User&User[Is_employee]=yes"
 * – 入力ボックスに、指定したカテゴリに属する全てのページを表示するオートコンプリートを設定する
 * – 入力ボックスに、指定した名前空間に属する全てのページを表示するオートコンプリートを設定する （使用可能な場合のみ）.

2) 'FormStart</tt>' を使用する – ユーザは /Special:FormStart からデータを追加することもできます. フォーム名は URL で /Special:FormStart/フォーム名 のように追加して指定できます.  フォーム名が指定されない場合は、ページ名を入力するボックスの後ろに Wiki で使用可能な全てのフォームから選択するドロップダウンが表示されます.  （このアプローチは推奨されません. ）

名前空間に応じたページ追加
ユーザに毎回、名前空間を入力させなくても、既定として指定した名前空間 （例えば 'User:' 等） にページを作成するページ入力フォームを用意することができます. 'forminput' タグを使用する場合は、"query_string" の値に 'namespace=名前空間名' と指定します. 'FormStart' を使用する場合は、URL に " http://mywiki.com/Special:FormStart/ フォーム名/Namespace:名前空間名" のように指定してください.

サブページの作成
MediaWiki では、ページ名にスラッシュを含めることで サブページ を作成できます. 目的のページをサブページとして自動的に作成するには、クエリ文字列 "super_page=</tt>" に値を設定します. 現在のページに新しいページをサブページとして追加するには、値を  "super_page=" </tt> と設定します. この設定により、ユーザが入力したページ名の前に "現在のページ名/" が付加されます.

1 段階手順
フォーム定義ページの "info" タグに "page name" パラメータを使用すると、フォームが作成するページ名を自動的に作成することができます. このパラメータの値として使用できる "変数" には 2 種類あります.


 * '< テンプレート名[フィールド名] >' – このタグは、指定したテンプレートの指定したフィールドの値で置換されます. 注意すべき点は、ページ名が決定されるまでは、指定したテンプレートは "実行" されない – 既定値も与えられず、サブテンプレートも評価されない – ということです.  従って、ページ名式は、テンプレートの入力パラメータとして与えられた値のみ使用できます.


 * ' ' – このタグは、生成されたページ名が一意となる最小値、または他に使用されていない乱数値のどちらかで置換されます. 通常はこの値は空白からスタートし、2、3、と増加していきますが、"start=" パラメータを付加するとこの値の開始値を手動で指定できます.  例えばこの値を 1 から順に増加させていきたい場合は、タグを " <unique number;start=1> " と指定します.  また "randome" パラメータを付加して " <unique number;random> " のように指定すると、値にランダムな 6 桁数字が使用されるようになります.  どちらの場合もパラメータはセミコロンで区切られますので注意してください.

例えば、前述のフォームでは "page name=<Item[Author]> opinion item <unique number;start=1>" のように宣言できます. これは、著者の名前を全てのオピニオン項目のページ名に含めると共に、付加数値により追加された全てのオピニオン項目の名前が一意に定まることを保証しています. ここで URL " http://discoursedb.org/wiki/Special:FormEdit/Item " に行き フォームに記入してみたとします. 著者名を "Ernest Hemingway" とし、Wiki に他にヘミングウェイの オピニオン項目がなければ、"Save page" ボタンとクリックすると "Ernest Hemingway opinion item 1" と命名された新しいページが作成されます.

For example in Form:Item write:

The "start" value can have leading zeroes; a value of "001", for instance, would lead to pages that had the value "001", then "002", etc.

The "page name=" value gets parsed by the MediaWiki parser, so you can also add parser functions, pre-defined variables, etc. into the value.

Note that users must be sent to the page "Special:FormEdit/form-name" for this automatic page-setting to work; if they go instead to the regular form page, or to "Special:FormStart", they will be prompted for a page name, which will override whatever the automatic page name would be. (Though it should be noted that you can also change the form page to link to "Special:FormEdit/form-name", in place of having the #forminput input.)

If you want, you can generate this link using the "#formlink" parser function, instead of creating the URL directly. This function is called as:



The " " and " " arguments work much the same way that their equivalents in "#forminput" work, and " " works like " " (see above). The " " argument sets the display of the link: if it's set to "button", the link will show up as a button; if it's set to "post button", it will be a button that sends the query-string value(s) using "POST" instead of via the URL - this is helpful when a lot of data has to be preloaded, and it is more robust with special characters like line breaks in the query string; if it's set to blank or anything else, it will show up as a regular link. Finally, the " " parameter shouldn't usually be used, but it sets the "target" page to be edited, if you want to link to the editing of a specific page.

Example:

This will link from the page, via a button, to a form, and specifically the form's "Summary" tab (assuming you've set up tabs in the form using the Header Tabs extension).

データのプリローディング
ユーザが編集作業を開始した時点で、フォームに既に何らかのデータがあるようにしたいと思うかもしれません （これは新しいデータを追加する場合のみである点に注意してください. 既存のページを編集する場合は、ページの現在の内容以外にフォームに内容を設定する方法はありません）. これを実現する方法はいくつかあります:


 * フォームで値を持たせるようにしたい各フィールドに "default" 値を指定する.
 * "free text" 入力欄に "preload" ページを指定すると、フリーテキストフィールドに当該ページの内容がプリロードされます.
 * 'forminput' コールに 'query string=' 値に 'preload=プリロードページ名' を挿入します. このことにより当該ページの内容がフォーム全体でプリロードされます.
 * 同様に、'FormStart' URL または 'FormEdit' URL のクエリ文字列に "preload=..." 値を追加することができます.
 * Add "template-name[field-name]=field-value" to the 'query string=' value in the 'forminput' call, to set the value for a specific field. To preload values for more than one field use "&": "template-name[field-name-1]=field-value-1&template-name[field-name-2]=field-value-2"
 * Similarly, you can add a value for a specific field to the URL query string for 'FormStart' or 'FormEdit'.
 * Finally, you can create your own custom handling, using the 'sfEditFormPreloadText' hook. If another extension calls this hook, it can preload data however it wants. The function registered with this hook should have a header like "function-name(&$page_contents, $page_title, $form_title)".

'フォームを使って編集' タブ
指定ページに 'フォームを使って編集' タブを表示させるには 3 つの方法があります:

カテゴリに基づく方法
第 1 の (そして推奨される) 方法は、カテゴリ を使用する方法です. この方法でページにタブを有効にするには、以下の 2 ステップを実行しなければなりません:

1) まず、ページが指定のカテゴリに属するように定義します - カテゴリはページの型を定義するための Semantic MediaWiki の標準アプローチです. ページをカテゴリにマッチさせる最もよい方法は、'カテゴリ' タグをこのページ型を定義するテンプレートの内部に配置することです: この方法で、このテンプレートを使用する全てのページはこのカテゴリに属することになります.

2) 次に、意味的プロパティ 'Has default form' をそのカテゴリへのページに配置します; タグは  Has default form:: form-name</tt> のように見えます. カテゴリを 'カテゴリの作成' ページを使用して作成すると、これは自動的に行われます.

このアプローチの例として、

1) Discourse DB 上の "Magazine" テンプレートのソースコード を参照してください. このページは、カテゴリ "Magazines" に自身を含めるページを定義します;

2) 次に "Magazines" カテゴリのソースコード を参照してください. このページは、"Magazine" フォームをこのカテゴリの既定フォームとして規定します.

3) 最後に、Newsweek マガジンへのページを参照してください. このページは "Magazine" テンプレートを使用しており、従ってカテゴリ "Magazines" に属し、従って上部に "edit with form" タブを得ます; そしてこのタブは "Magazine" フォームを使用した編集にリンクします. 以上ごらんの通りです.

名前空間に基づく方法
二番目に可能な方法では、ページの 名前空間 とフォームをマッチさせます. これは、名前空間を定義するページに 'Has default form' プロパティを記述することで実現できます. 仮にサイトの名前が 'MyWiki'、フォームと関連付けする名前空間が 'User' であるとすると、プロパティを挿入するページの名前はおそらく 'MyWiki:User' となります （このページを新規作成する必要があるでしょう）. 標準名前空間 （すなわち名前がない空間） に既定フォームを設定したい場合は、'MyWiki:Main' （または、Wiki の標準言語での標準名前空間名） ページを作成して上記のプロパティを記述する必要があります. 以上のプロパティを設定すると、名前空間の全てのページで、上記で指定されたフォームが使用できます. 但し既にカテゴリで関連付けされたフォームがあるページの場合はそちらが使用されます （カテゴリの方が名前空間より優先度が高い）.

フォーム編集が可能なページで、ユーザが当該ページの編集アクセス権を持っていない場合は、タブには代わりに "View form" と表示されます. このタブをクリックすると入力できないフォームが表示されます.

ページ内で
Pages can set their own form, by including a "Page has default form" property placed either directly within the page or in a template that the page calls, e.g. Page has default form::form-name. This is especially useful when the category and namespace options aren't possible, such as if pages belong to multiple categories that have different default forms; or for editing category pages themselves.

編集タブの設定
"Edit with Form" タブを持つページに対して、通常の "Edit" タブを名前を変更するか、全て削除してしまうかしたいと思うかも知れません. 編集タブの表示を変更するために "LocalSettings.php" に設定可能なフラグがあります:
 * - renames the "edit with form" tab to "edit", and the "edit" tab to "edit source" (in whatever language the wiki is being viewed in)
 * - renames only the "edit" tab to "edit source" (in whatever language the wiki is being viewed in)
 * - can be set, for different types of viewers, to toggle whether each type will see the regular edit tab. One common modification is to set it to false normally (i.e. for viewer type '*'), and to true for 'sysop' viewers:

If these settings are added to LocalSettings.php, they should be placed in the file after the include of Semantic Forms.

Note that some of the early MediaWiki skins, like Cologne Blue, contain hard-coded links to "Edit this page", that can't be removed or renamed by the Semantic Forms code.

フォームへの赤リンクを指し示す
MediaWiki では、存在しないページへのリンクを '赤リンク' と呼びます. これは、これらのリンクが通常赤色で表示されるためです. 既定ではこれらのリンクは、標準編集フォームを使用して Wiki に記事を追加するページにリンクします. しかしながら、もし意味的プロパティに対する新しい値からもたらされる場合には、ページ追加用の正しいセマンティックフォームにリンクさせることができます.


 * Simply add the semantic property 'Has default form' (see "The 'edit with form' tab") to the page for the property.


 * You can also add one or more 'Has alternate form' properties to the property page, so that the user gets other possibilities when they click on the red link.

You can set either a default form, or alternate forms, or both, for a property; setting the default form can be done directly within the 'CreateProperty' page.

As an example, see this page. Both the author and the source are red-linked, but the links take you to forms for adding these two pages (please do not actually fill out and submit these forms, because that would ruin the example). When you get to the forms for each page, you can see, at the top, that there are alternative forms that you can select for adding each page. That is enabled by 'Has default form' and 'Has alternate form' properties in the pages for both the properties 'Was written by' and 'Was published by'.

Note also that, if you've defined a namespace as having a default form, red-links that go to a page within that namespace will also go to the right 'add data' form, without any extra work needed.

By default, Semantic Forms checks, for every red link, for the existence of properties across the wiki pointing to that page in order to find default forms. However, for pages with a large number of red links, this can slow down page loading. If that's an issue for you, you can change the behavior so that SF only checks properties on the page in question, instead of throughout the whole wiki. To do that, add the following to LocalSettings.php, after the inclusion of Semantic Forms:

Sometimes, when a page with red links is first created, the red links will point (incorrectly) to the standard edit URL, and not to the form URL; the correct URL will only appear at some point later. That happens because of caching on the wiki. If you want to get around this problem you can very easily disable caching (see the instructions here).

赤リンクページの自動生成
It's nice to have red links point to the right form for creating the page, but this still calls for work on the part of users - they have to click to the form, fill out the fields and save the page. This is especially bothersome when the form contains few or no fields, and/or if there are many such pages to be created. You can instead have such red-linked pages get automatically created by the system. To do this, instead of 'Has default form' or 'Has alternate form', you should add the special property 'Creates pages with form' to the property that you want pointing to those automatically-created pages. For instance, if you have pages that point with the property "Has country" to other pages, and you want those other pages to automatically be created using a form called "Country". You just need to add the following to the "Has country" property's page:

Creates pages with form::Country

It should be noted that it may take a while for each page to be created, since page creation is done through MediaWiki "jobs", which can take anywhere from a few seconds to several hours or more to run, depending on the length of the job queue.

データの問い合わせ
フォームはまた、データを追加したり編集するだけでなく、データを問い合わせるためにも使用されます. そうするためには、'Special:RunQuery' ページを使用します. この特別ページは 'Special:FormEdit' とよく似た方法でフォームを表示しますが、関連付けられた 'ターゲットページ' を持ちません. そのかわり、ユーザが "Run Query" ボタンをヒットしてフォームをサブミットしたときに、入力した値つきで表示される時と同じようにテンプレートが見えます. フォームが使用するテンプレートは、ユーザが入力した値を使用してデータを問い合わせるために、ひとつ以上の Semantic MediaWiki inline queries を含んでいる必要があります. 問い合わせフォームのサンプルとして here を参照してください.

問い合わせデータがプリロードされる必要があるばあいには、'Special:RunQuery' は入力規則 Special:RunQuery/form-name?template-name[item-name]=value に従う必要があります (例: http://discoursedb.org/wiki/Special:RunQuery/Item_query?ItemQuerier[author]=Joe ). 構文 [item-name] は Wiki マークアップに関して問題の原因となるはずであるので、 [ and ] は %5B および %5D で痴漢することができます.

フォームをタブ化セクションにする
もしフォームがユーザが快適に入力するには長すぎると考えられる場合には、Header Tabs 機能拡張を使用してセクション化し、タブインターフェイスを通じてそれらのセクション間を切り替えて表示させることができます. この機能拡張をインストールしていれば、フォームにタブを追加することはとても簡単です: 単にタブを表示したい箇所にトップレベルセクションを "=Tab 1=" の形式で挿入し、次に  タグをフォームの下部付近の、"standard input" 宣言文の直前に挿入するだけです. タブ宣言文はテンプレート間、テンプレート中のどちらにも記述でき、テンプレートのフィールドを異なるタブに分割配置することができます. タブ化セクションの簡単な例として ここ を参照してください. このページを作成するために使用したフォームの定義は ここ で見ることができます.

これらのタブは、同様にして、データページ自体を表示するために使用することもできます.

部分フォーム
フォームを部分フォームとして指定するには、 タグにプロパティ "partial form" を付加します. この設定により、フォームは 1 つまたは複数のテンプレート部分のみを処理し、これらのテンプレートの前後部分は変更されません. 部分フォームをカテゴリまたは名前空間の既定フォームとして使用することは推奨されません. 部分フォームは既存のページの一部を変更するツールとして使用します. 部分フォームの例として ここ を参照してください. また実際の動作例として、 このサイト で "Add or change this opinion item's references" と書かれたリンクをクリックしてみてください.

フォーム要素の再利用
もし全く同じテキストやセクションを含む複数のフォームを作成する場合には、これらのフォームで共通に使用されるテンプレートを作成して、重複を防ぐことができます. これは単に、置き換えたい全てのテキストをテンプレートに配置し、各フォームからテンプレートを呼び出すだけで実現できます. これらのテンプレートに （フィールド定義のような） フォーム要素が含まれる場合は、フォーム要素に含まれる文字を HTML エスケープする必要があります - '{' を '&amp;#123;' に、'|' を '&amp;#124;' に、'}' を '&amp;#125;' に置換します.

フォーム定義のキャッシュ
フォームが表示される際に、フォーム定義の構文解析は 2 回行われます - 最初に Wiki テキストを HTML に変換し、次に "" のようなセマンティックフォーム特有のタグを処理します. もしある Wiki ページのフォームが表示されるまでに時間がかかる場合は、おそらく第 1 段階が原因と思われます. この処理には数秒かかる場合があります. フォーム定義のキャッシュを許可すると、（ほとんどの場合に） HTML バージョンを直接抽出できるようになり、第 1 段階を省略できます. この許可を行うには、LocalSettings.php に以下の行を追加します:

この設定を行った後に、対象となるフォームページを再保存する必要があります.

ツールチップ
Semantic MediaWiki で定義されるパーサ関数  を使用して、フォームに   のようなツールチップを付加できます （このパーサ関数と Semantic Form の "  " タグを混同しないように注意してください）.

新しい入力を定義する
You can use hooks to define inputs, for either a new input type or a new semantic type; see Defining new inputs.

MediaWiki に関する問題

 * If a template contains section headings (like "==Section 1=="), when the template is displayed on a page each section heading will have its own "Edit" link. Such links are not desirable, since they will take the user to editing the template, rather than the actual page in question. The easiest way to avoid this problem is to place the string "" anywhere within that template; this will remove all section-edit links from any page that contains that template.

Semantic MediaWiki に関する問題

 * If one or more of your fields can contain internal links entered by users (e.g., "This is a cat "), and you want those fields to be saved correctly by SMW, add the following line to your LocalSettings.php file, under the inclusion of SMW:

Semantic Forms に関する問題

 * You can change the way dates are entered in, and outputted by, the forms by adding the line "$wgAmericanDates = true;" to the main MediaWiki LocalSettings.php file. By default, dates are printed out as "2007/06/20"; making this change will set dates to instead be printed out as "June 20, 2007" (with the month name dependent on the language of the wiki).


 * Similarly, you can change the way times are entered and displayed. If you have a form field with input type 'datetime', by default it will use the 12-hour format, with "AM" and "PM". You can change this to 24-hour format by adding the line "$sfg24HourTime = true;" in your LocalSettings.php file.


 * If a page (which we'll call Page A) gets transcluded in another page (which we'll call Page B), and Page A belongs to a category that's associated with a form, it can have the unfortunate side effect of making Page B a member of that category as well, thus giving Page B an "edit with form" tab at the top, even if such a tab is not appropriate. You can solve this problem by putting the category declaration in Page A within a " " block, which will make Page A a member of that category but not Page B.


 * If, when you go to the special pages 'CreateProperty' or 'CreateTemplate', you see a database error message that looks like "Access denied for user...", it means your database account lacks permission to create temporary tables.


 * If dates before 1970 and after 2037 are not displayed correctly in the form, that is most likely because you have a version of PHP older than 5.1; consider upgrading, if possible.


 * Versions 2.0 and higher of Semantic Forms do not currently work correctly with either the GuMax or the OntoSkin skins, due to a conflict between different instances of the jQuery Javascript library. If you're using GuMaxDD and MediaWiki 1.16, there appears to be a workaround: within the file gumaxdd.php, remove the line that includes "jquery-1.4.2.min.js". Then, at the top of the same file, right below the the call to die( -1 );", add the following two lines:


 * If you want to do any processing on a list of values before calling #arraymap on it, such as sorting it, splitting it up or printing its size, it may help you to use the ArrayExtension extension.


 * Semantic Forms only handles forms for adding and editing data in wiki pages. You may want forms for other purposes: fortunately, there are other form extensions you can use. EmailForm allows you to create forms for emailing data, and Simple Forms allows you to create generic forms for a variety of purposes. See also the MediaWiki forms manual for other such extensions.


 * It is best to urlencode all elements of query strings, otherwise special characters like ampersands (&) cause trouble. An example #forminput call with urlencoded query string elements:   Note, that the ampersands dividing the query string elements must not be urlencoded.

You can also see other tips and hints for using Semantic Forms in the tips section of the SMW Community Wiki.

データ設計に関する問題

 * One common issue is how to use categories. The Wikipedia approach is to have many categories on each page, to identify all aspects of that page's subject. Semantic MediaWiki was created in part to eliminate the need for categories, by allowing for semantic properties to represent this data. The general Semantic Forms approach is to only have one category per page, and have this category be set by the main template in the page: in other words, it is recommended that users not enter category declarations directly. The one exception to this rule is when there's a need for "hierarchical tagging", i.e. being able to add a page within different levels of a category tree. For this purpose, the 'category' and 'categories' input types exist.


 * When creating a semantic property connecting any two "classes", or pages represented by different categories, you may be unsure about which way to point the property. Usually such relationships will be of the one-to-many variety, also known as parent-child relationships, in which each page of type A has a relationship to any number of pages of type B, while each page of type B always has a relationship to exactly one page of type A. An example is countries and cities: a country can have many cities, but a city always belongs to exactly one country. In such a case, you may not know whether it should be country pages that have a "Has city" property, or city pages that have a "Belongs to country" property, or even whether both properties should exist. In this situation, it is recommended that you specify the relationship only from the child to the parent, i.e. use a "Belongs to country" property for cities and not the other way around. This is for two reasons: first, it lets you guarantee the rule that every child has exactly one parent, by setting this property through a field within the child's main template; and second, it makes page-name autocompletion more reliable, since parent pages are usually created before their children's pages are.


 * You may not be sure about whether to create one form or many for a set of related page types. For instance, in a wiki about restaurants, should you have a separate form/template/category set for regular restaurants, fast-food restaurants, diners etc., or a single form called "Restaurant", with a corresponding single template and category, that just uses a field to indicate the type of restaurant it is? A good rule of thumb is to look at the set of data that you want to be entered and displayed for each type of page. If it's the same across all the types, then you could probably use a single form/template/category set for all of them. However, if there's even one difference in the set of fields being displayed for any page type, then it probably makes sense to give such a page type its own form, template and category.


 * It is possible to create a different namespace for each page type. Wikisource does this with an "Author:" namespace, for instance, and several SMW-based wikis have one or more namespaces for different page types. Whether you do this on your wiki is up to you, but it is not recommended that you do it unless there is a real possibility of naming ambiguity otherwise. A massive wiki like Wikipedia will have a great deal of pages that require disambiguation, but most small wikis will barely have any, and so having separate namespaces will probably be a needless complication. (Currently the only common examples of ambiguity in SMW wikis are caused by having pages for both cities and states in the United States: "New York" and "Washington" both fit into either category. There are various solutions to this problem, but the simplest may be to have all states referred to by their two-letter abbreviation, e.g. "NY" and "WA".)

既知のバグ

 * "show on select=" currently does not work within multiple-instance templates.

機能拡張のテスト
The best place to try out Semantic Forms is on the "Referata scratchpad" wiki, at scratchpad.referata.com. There you can create all the properties, templates, forms, etc. that you want, and see how they all interact. You do not need to register to make edits.

Semantic Forms を使用しているサイト
Here is a small sampling of sites that use Semantic Forms in conjunction with Semantic MediaWiki, subdivided by type. For a more comprehensive listing, see the list of sites that use Semantic Forms on the Semantic MediaWiki Community Wiki, which is itself an SMW-based wiki that contains additional information on each site.

サポートの入手
Please use the Semantic MediaWiki mailing list, semediawiki-user, for any questions, suggestions or bug reports about Semantic Forms; if possible, please add "[SF]" at the beginning of the subject line, to clarify the subject matter.

(Until July 2009, Semantic Forms had its own mailing list - you can see the archives here.)

If you want more in-depth support, or you would like to hire someone to set up forms on your wiki, a large number of options exist - see the professional support page on semantic-mediawiki.org.

ホスティング
Currently two wiki hosting sites offer support for Semantic Forms:
 * Referata - a site created and run by Yaron Koren. Wikis on Referata can use Semantic MediaWiki, Semantic Forms and a variety of related extensions; basic usage is free.
 * Wikia - wikis on Wikia can request Semantic MediaWiki, Semantic Forms and Semantic Drilldown to be turned on (they are not enabled by default). Be aware that these extensions can be several versions behind on Wikia; see here, for example, for the current version numbers. Additional SMW-based extensions are currently not available on Wikia.

バグおよび機能要望
You can submit bug reports and requests for new features at MediaWiki's Bugzilla, extensions here.

The current list of known bugs and requested features for Semantic Forms can be found here.

プロジェクトへのパッチ提供
If you found some bug and fixed it, or if you wrote code for a new feature, please create a patch by going to the main "SemanticForms" directory, and typing:

svn diff >descriptivename.patch

Then go to the relevant bug report in Bugzilla, or create one if one doesn't exist (note, again, that Bugzilla is used for both bugs and feature requests), and attach this patch file to it.

If, for any reason, you don't wish to use Bugzilla, feel free to simply send this patch, with a description, to the semediawiki-devel mailing list.

翻訳
Translation of Semantic Forms is done through translatewiki.net. The translation for this extension can be found here. To add language values or change existing ones, you should create an account on translatewiki.net, then request permission from the administrators to translate a certain language or languages on this page (this is a very simple process). Once you have permission for a given language, you can log in and add or edit whatever messages you want to in that language.

関連項目

 * Semantic Maps
 * Semantic MediaWiki
 * SemanticSignup
 * Simple Forms