RU:Wiki guidelines

	Про Вики		Директива		Организации		Перевод		Очистка		Справка
При создании вики-страниц следует придерживаться следующих Руководящих принципов Вики. Это поможет создать полезную и удобную вики-страницу, доступную для всех. Очистка — это страница, на которой координируется работа над вики-страницей, в том числе для обеспечения соответствия этим рекомендациям. Понятность Делайте страницы короткими, используйте простой язык и избегайте профессионального жаргона. OpenStreetMap стремится быть доступной для всех, и наша документация должна это отражать. Пишите так, чтобы было понятно и детям, и бабушкам! Некоторые вики-страницы по своей сути представляют собой техническую документацию. Но даже в этом случае мы должны стремиться к тому, чтобы они были понятны пользователям с разным уровнем технических знаний. Пишите простые вводные материалы, чтобы подготовить читателя к теме, и старайтесь выносить сложные детали на отдельные, более специализированные вики-страницы. Структура Структура вики должна быть такой, чтобы пользователи могли легко находить нужный контент, начиная с Заглавной страницы. Некоторые ключевые материалы доступны по ссылкам прямо с главной страницы, но другие ссылки ведут на «стартовые страницы» по определенной теме. Это следующий уровень своего рода иерархии навигации. Зачастую это короткие страницы с большим количеством ссылок и небольшим объемом текста (их также называют «порталами»). Необходимо следить за тем, чтобы эта система навигации оставалась удобной для новых посетителей. Противоречивость информации Противоречивая информация — это очень плохо. Информация о текущих рекомендациях по маркировке должна быть согласованной. Если это не так, пожалуйста, свяжитесь с другими пользователями, чтобы прийти к единому мнению. В идеале рекомендации по маркировке должны соответствовать фактической практике маркировки, если только для этого нет веских причин. Исключением из этого правила являются предложения и предлагаемые изменения в маркировке. Однако они должны быть четко обозначены как предложения. Дублирование Дублирование часто приводит к негативным последствиям, поскольку может привести к противоречивой информации и увеличить объем работы. Если дублирование необходимо, его следует рационализировать, чтобы создать единый и понятный источник информации. Для этого может потребоваться обсуждение с другими пользователями! Можно кратко изложить тему на другой странице, но ссылка на эту страницу должна вести на главную. Template:merge используется для обозначения страниц, которые требуют реорганизации для устранения дублирования. Если дублирование оправдано (например, информация представлена в другом стиле, с другой структурой страницы или для другой аудитории), важно четко объяснить причины такого решения и использовать перекрестные ссылки, чтобы избежать путаницы. Если для дублирования нет веских причин, страницы следует объединить. Обратите внимание, что объединение не обязательно означает, что у нас останется одна страница вместо двух. Возможны и другие варианты, например, страница с кратким описанием для неспециалистов может содержать ссылку на более подробную техническую страницу. Соглашение об именовании титульных страниц Пожалуйста, следуйте правилам написания заглавных букв в названиях статей Википедии: «В многословных заголовках страниц второе и последующие слова пишутся со строчной буквы, за исключением случаев, когда заголовок состоит из имени собственного, которое всегда пишется с заглавной буквы, даже в середине предложения». Не используйте CamelCasePageTitles, в которых слова сливаются без пробелов. В MediaWiki можно использовать пробелы, как в естественном языке. Исключение составляют случаи, когда заголовок страницы является названием чего-то, в котором слова обычно сливаются, например «OpenLayers». В прошлом часто использовались префиксы в заголовках страниц (например, префикс «WikiProject»). По большей части это неудобное наследие прошлого, но на данном этапе мы не можем легко от него избавиться. Перенос всех таких страниц был бы очень сложной задачей. Однако создание новых схем с префиксами в заголовках страниц крайне нежелательно. Используйте заголовки страниц на естественном языке и перекрестные ссылки на несколько страниц, чтобы создать структуру ссылок в содержании самих страниц. Пожалуйста, ознакомьтесь с текущей дискуссией на эту тему в разделе Схема организации Вики. Introduction 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. Often, it is useful to include one link to a more general page and more links to any other, 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. Linking 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 cannot think of a related wiki page to link from here, 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. Linking to and styling of keys or values Often, texts contain related keys or values. If you use the templates (also called "macros" in other wiki softwares) Template:Tag (Key is an alias), Template:Value, and related by typing wiki source {{Tag|highway|motorway}} or adding it using the editor's menu, the text appears like highway=motorway which has several advantages: Due to the standardized and well-known formatting, the text can be recognized as key=value at first glance which is more difficult with plain text. Both key and value are each links on their own, making it easy to find more information. It is an internal link, so it leads a user to the page in the current language, it won't break even if URLs do change, it can be followed in both directions, it can be analysed for statistics, etc. Wikipedia linking 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. However, you may use a template to make the external link to Wikipedia more explicit: {{Wikipedia|en|Page name}} or {{Wikipedia|en|Page name|text= no }} to just keep the leading icon without the trailing text "on Wikipedia". Don't link to a Wikipedia page where the same or similar title exists on this wiki (except from the article on this wiki, where it could be used as an additional external reference for more information about the same topic). Page about a website 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 very 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 in duplicating a lot 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, but do aim to use language which promotes OSM and uses of OSM. Listing software / services 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 don'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. Alternative link text should be used to shorten the URL, preferably to the domain name, so that it's still recognized as an external link. Example: OpenLayers (openlayers.org) – A JavaScript library for showing maps. 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 Categories should be used to group pages by type which should follow the same naming conventions as other wiki pages. Categories can themselves be categorised to create a hierarchy to help with 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 '|'. This wiki provides HotCat-Gadget, a simple interface for changing categories. Language 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. Translation See Wiki Translation. This includes some introductory philosophical thoughts on what we aim to achieve with translations within the wiki. Migration to Translate extension has been discussed several times, but the current consensus seems to oppose this. Date formatting Dates should be formatted in one of these ways depending on the precision required: 26 May 2026 (the normal format, unless there is uncertainty or where the day is highly relevant; no need for the leading zero in the day value) Tuesday 26 May 2026 (for when the day of the week matters) May 2026 (day of month is not known nor relevant) 2026-05-26 (fixed format from ISO 8601 standard, to be used in tabular data, especially when content should be transcluded into multiple translated pages; includes zero left-padding) 2026-05 (similar when day of month is not known nor relevant) 2026 (year only, without thousands group separator) 'Soon' (May 2026) (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!). Edit descriptions Remember to use the "Summary" field during editing to indicate what was changed. It helps other editors. Changing content If you make a change that affects existing tagging, remember that it is beneficial for acceptance and the community to bring it up in a discussion with others. There's no automatic way that a change in the wiki will also result in a change in OSM. It has to be adapted by users and developers. Therefore, discussion is the way. In the Wiki, this can be done on the respective talk page or the central Talk:Wiki page; other places include the community forum. Please help others by leaving an easy-to-find reference and a link if the discussion takes place outside of the Wiki.