JA:ウィキのガイドライン

From OpenStreetMap Wiki
(Redirected from JA:Wiki guidelines)
Jump to: navigation, search
利用できる言語 — Wiki guidelines
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ‎ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
その他の言語このウィキの翻訳を支援してください
概要 ガイドライン 構造 翻訳 Cleanup ヘルプ

以下のウィキのガイドラインはウィキページを書く際に参照してください。これは誰からもウィキを利用しやすく役立つものにする助けになります。 WikiProject Cleanup は以下のガイドラインにより適合するようにするウィキ上の作業をコーディネートするページです。

理解しやすさ

ページは短く、簡潔な言葉で専門用語を避けてください。 OpenStreetMap は誰でも利用できるようになることを目指しており、これはドキュメントにも反映するべきです。子どもからお年寄りまでを対象に書いてください。

一部のウィキページは自然と技術文書の形になっています。このような文書であっても、様々な技術レベルのユーザーに分かるようすることを目指すべきです。主題に導く導入は簡潔に書き、非常に複雑な詳細はより専門的なウィキページに分けるように意識してください。

構造

ウィキはメインページから簡単にコンテンツが見つけられるように配置するべきです。一部の核となるコンテンツは、メインページから直接リンクされますが、一方でメインページは特定のトピックの「開始ページ」にリンクします。これはナビゲーション階層の次のレベルに当たります。ふつうは多くのリンクを持った短いページで、文章は多くありません(いわゆる「ポータル」です)。このナビゲーションが新しい来訪者に効果的に働くようにする作業が必要です。

情報の矛盾

情報の矛盾は非常に悪いことです。現在のタグ付けに関する推奨事項は一貫しているべきです。そうでない場合は、他のユーザーに連絡を取って合意を形成してください。明確な理由がない限り、理想的にはタグ付けの推奨事項は実際のタグ付け活動と一致しているべきです。

提案やタグ付けの変更の提案はこのルールの例外です。しかし、提案として明確に認識されなければなりません。

重複

Duplication is often bad because it risks providing conflicting information and increases the amount of work. Where there is unnecessary duplication, it should be rationalised to provide a single clear source of information. This may require discussion with other users! It is fine to summarise a topic in another page but that summary would link to the main page.

Template:merge is used to label pages which require reorganisation to remove duplication.

Where duplication is useful (for example, it is being presented in a different style, page structure, or for differing audiences), it is important to be clear about the reasoning for this, and cross-link to avoid confusion. If there is no good reason for duplication, then the pages should be merged. Note that a merge does not necessarily mean we are left with one page where there were two before. There are other outcomes, for example a non-technical summary page page may link to a more detailed technical page.

タイトル - ページ命名の慣例

Please follow Wikipedia capitalising naming conventions: For multiword page titles, leave the second and subsequent words in lowercase unless the title phrase is a proper noun that would always occur capitalized, even in the middle of a sentence.

Do not use CamelCasePageTitles in which words are jammed together with no spaces - MediaWiki allows us to use spaces as in natural language. The exception to this would be where the page title is the name of something which does typically have its words jammed together e.g. "OpenLayers"

Prefixes in page titles have been used heavily in the past (e.g. the 'WikiProject' prefix). This is mostly a cumbersome legacy, but not one we can easily rectify at this stage. Moving all such pages would be too big a task. However creating new page title prefixing schemes is strongly discouraged. Use natural language page titles, and cross-link a set of pages to create linking structures in the content of the pages themselves. Please refer to the Wiki organisation for the current discussion on this topic.

導入

Pages should start with a short introductory paragraph comprising a few sentences. This should include the title in bold and explain what the page is about. It's often useful to include a link to a more general page and to any more specific pages, as this helps navigation.

This introductory section should appear before any headings (and before the Table of Contents on a long page). Note that it is fairly common for people to create a first heading "Introduction". This should be restructured so that at least part of the introduction is at the top of the page above any headings. This will achieve a consistent layout across the wiki.

リンク

Pages should be well linked to help users find the information they are looking for. Important related concepts are usually linked to within the introduction. If you can't think of a related wiki page to link from here, then you're probably not describing the page in broad enough terms. You are also encouraged to link to related concepts throughout the rest of the page.

Linking a section to a main page

The {{main|page name}} code could be used under a section heading to provide a link to a main page relating to the subject of the section. The section should then only summarise the linked 'main' page (and should certainly not conflict with it in any way). The title for the section should normally be the same as the page to which it is linked.

ウィキペディアへのリンク

Wikipedia links can be confusing. Only link to wikipedia if it's useful, and if the concept is not better explained in an OSM context on this wiki.

If using the [[wikipedia:page name]] interwiki syntax, please leave the 'wikipedia:' prefix in place i.e. Don't do alternate link text: [[wikipedia:page name|page name]] as this is hugely confusing in a basic navigational sense. Don't link to a wikipedia page where the same or similar title exists on this wiki.

ウェブサイトに関するページ

We have lots of wiki pages dedicated to describing some external website (map services, software products etc). Obviously the external link to that site is hugely important. The main link should be placed in brackets after the title (which is bold) in the very first sentence and/or linked in larger text on it's own line after the top descriptive sentences.

On these pages there is no point duplicating lots of 'about' information found on the external site. The page should describe the site in an OSM context. Be more neutral and less promotional with your description, although do aim to use language which promotes OSM and uses of OSM.

ソフトウェアやサービスの列挙

We have a number of pages containing bullet pointed lists or wiki tables listing software / services. If we have wiki pages about the software, or even if we haven't (red links) the preferred format is an internal link to the OSM wiki page followed by an external link to the site in brackets. This might then be followed by a short description or other table columns. We should aim to provide links to both the wiki page and the external link even where the wiki page doesn't exist yet to encourage a healthy level of wiki interlinking. Red links can be filled in with stub information following the advice above.

Full URL external links can be nice, if they are short, since the user knows what to expect when they click it. Alternate link text should be used to shorten this, preferably to the domain name so that it's still clear that this is an external link.

Example:

In very space constrained situations (often in the case of wiki tables) we might use the numbered link syntax (e.g. [1]) to shrink the external link right down. We might opt to drop the external link and only link the wiki page, since this will itself have the external link. If the wiki page doesn't exist we might opt to only provide an external link, but it might be better to create a wiki page with stub description.

カテゴリ

Categories should be used to group pages by type which should follow the same naming conventions as with wiki pages.

Categories can themselves be categorised to create a hierarchy to help navigation to the subject of interest. For example Category:Buses is categorised within Category:Public transport.

Pages can be part of a number of categories but should not 'spam' categories. A page relating to buses (for example, a page about bus stops) should be categorised as 'Buses' but not also as 'Public transport'. However, the main Buses page should be tagged within the 'Public transport' category as well as the more specific one.

A single line introduction should be provided for every category which should in general link to an appropriate 'main' page for the subject, ideally of the same name. For example 'Pages relating to [[Public transport]] as an introduction to the category 'Public transport'.

When being categorised, pages should use the sort order option if necessary to ensure that they appear appropriately in the list of pages. For instance look at the pages listed in Category:Users in London. They would all be listed under 'U' because of the 'User:' prefix, but this has been overridden. For example the User:Harry Wood has the category wiki text: [[Category:Users in London|Harry Wood]] with the sort phrase provided after the '|'.

言語

OpenStreetMap uses British English for general English pages and the appropriate 'local' English for localised topic pages. So any page which mostly concerns the U.S., for whatever reason, would use American English. This particularly applies to place pages under Mapping projects.

翻訳

See Wiki Translation. This includes some introductory philosophical thoughts on what we aim to achieve with translations within the wiki, while it's not clear whether the wiki will migrate to the Translate extension.

日付の書式

Dates should be formatted in one of these ways depending on the precision required:

  • 12 August 2009 (the normal format, unless there is uncertainty or where the day is highly relevant)
  • Wednesday 12 August 2009 (for when the day of the week matters)
  • 1 August 2009 (no need for the leading zero in the day value)
  • August 2006 (day of month is not known nor relevant)
  • 2009
  • 'Soon' (August 2009) (when a prediction was made at a particular time)

Ordinal suffixes (th, nd, rd) are not necessary, and days and months should be written out in full. Avoid incomplete dates that are unclear, and avoid the use of seasons (summer in the northern hemisphere is winter down south!).