# Help:Style (Русский)

Ссылки по теме

- Help:Стиль/Форматирование и пунктуация
- Help:Стиль/Пустые строки
- Help:Редактирование
- Help:Чтение

Приведённые здесь правила призваны способствовать созданию кратких, легко читаемых статей и поддержанию единого стиля. Следуйте им как можно тщательнее в ваших правках.

## Страницы статей

### Заголовок

- В заголовках должен использоваться режим набора предложений с большой буквы: например, написание "Заголовок новой страницы" является правильным, а "Заголовок Новой Страницы" - нет. При этом, если в заголовке присутствуют общие слова, которые являются частью имени собственного или аббревиатурой с написанием в верхнем регистре, они должны писаться прописными буквами: например, "Advanced Linux Sound Architecture", а не "Advanced Linux sound architecture".
  Пространства имен не считаются частью заголовков, поэтому написание "ArchWiki:Статья-пример" является правильным, а "ArchWiki:статья-пример" - нет. Имена подстраниц должны начинаться с прописной буквы: например, написание "Моя страница/Моя подстраница" является правильным, а "Моя страница/моя подстраница" - нет
- Если предмет статьи широко известен как под своим полным именем, так и в аббревиатуре, предпочтительным является использование в названии статьи полного имени. Не включайте и полное имя, и аббревиатуру (например, в скобках) в название статьи, лучше использовать перенаправление со страницы с аббревиатурой на страницу с полным названием
- Для получения дополнительной информации смотрите статью Указания по выбору имен статей.

### Структура

Используйте следующий порядок элементов в статье:

1. #Магические слова (необязательно)
2. #Категории
3. #Межъязыковые ссылки
4. #Шаблоны состояния статьи (необязательно)
5. #Секция ссылок по теме (необязательно)
6. #Предисловие или введение
7. Оглавление (генерируется автоматически, если есть достаточное количество разделов)
8. Специфичные для статьи разделы

### Магические слова

Переключатели поведения, и, в общем, все магические слова, изменяющие отображение или поведение статьи, но при этом не имеющие какого-либо непосредственно важного содержимого, всегда должны находиться в самом начале статей.
В частности, это правило применяется также к `{{DISPLAYTITLE:title}}` и Template:Lowercase title.

### Категории

- Любая статья должна относиться хотя бы к одной существующей категории
- Статья может быть отнесена к нескольким категориям, если они не являются родительскими друг для друга
- Категории должны быть перечислены в самом начале статьи, сразу после любых магических слов
  Обратите внимание: Этим Arch Wiki отличается от других проектов на основе MediaWiki, таких как Википедия, содержащих категории в конце статьи
- Во избежание появления лишнего пустого пространства вверху страницы, между категориями и первой строкой текста (или межъязыковыми ссылками, если они есть) не должно быть пустых строк
- Для получения дополнительной информации смотрите статью Help:Category

### Межъязыковые ссылки

- Если у статьи имеются переводы на другие языки в локальной или внешней Arch Linux wiki, сразу за категориями и перед первой строкой текста должны быть добавлены межъязыковые ссылки.
  Обратите внимание, что они появятся в соответствующей колонке в левой части страницы
- Во избежание появления лишнего пустого пространства вверху страницы, между межъязыковыми ссылками и первой строкой текста не должно быть пустых строк
- При добавлении или редактировании межъязыковых ссылок вы должны позаботиться о том, чтобы продублировать ваши действия на страницах других переводов
- Не добавляйте в статьи более одной ссылки для одного языка
- Не добавляйте межъязыковую ссылку языка, на котором написана статья, в эту статью
- Межъязыковые ссылки должны быть отсортированы в алфавитном порядке на основе языковых тэгов, а не на основе местных названий: например, ссылка `[[fi:Название]]` должна идти перед `[[fr:Название]]`, даже если в местном языке слово "Suomi" идет после "Français"
- Для получения дополнительной информации смотрите статьи Help:i18n и Ссылки на статьи в иноязычных разделах по той же теме

### Шаблоны состояния статьи

- Шаблоны состояния статьи могут быть помещены после категорий (или межъязыковых ссылок, если они есть) и перед введением (или секцией ссылок по теме, если она есть)
- При необходимости можно помечать шаблонами состояния отдельные разделы
- Всегда сопровождайте шаблон состояния несколькими словами объяснения в соответствующем поле (примеры есть на страницах соответствующих шаблонов), а еще лучше, по возможности, создать обсуждение на странице обсуждения. Вариант "я скопировал англоязычную статью, добавил шаблон {{translateme}} и был таков" не катит!

### Секция ссылок по теме

- Дает простой список внутренних статей, относящихся к теме
- Это необязательная секция. Она включается сразу после категорий (или межъязыковых ссылок, или шаблонов состояния статьи, если они есть)
- Для ее создания необходимо использовать только Template:Related articles start (Русский), Template:Related и Template:Related articles end. Смотрите указания по применению на соответствующих страницах этих шаблонов
- В статьях, написанных не на английском языке, также можно использовать Template:Related2 для перевода соответствующих ссылок
- Используйте #Раздел "Смотрите также" для создания более полного и детального списка, в который также можно включить описания, ссылки между wiki и внешние ссылки

### Предисловие или введение

- Описывает предмет статьи.

  Вместо перефразирования или написания вашего собственного (возможно, предвзятого) описания программного обеспечения, вы можете использовать описание автора. Обычно его можно найти на домашней странице проекта или странице "О проекте", если она существует. Пример: MediaTomb

- Располагается непосредственно перед первым разделом статьи
- Не создавайте разделов с названиями `== Введение ==` или `== Предисловие ==`: лучше, если они будут находиться до заголовка первого раздела. Оглавление будет создано автоматически между предисловием и первым разделом, и в нем будут перечислены только существенные разделы
- Для получения дополнительной информации смотрите статью Написание введений для статей

### Заголовки разделов

- Должны начинаться со 2 (`==`) уровня, поскольку первый уровень (соответствующий тегу `<h1>`) зарезервирован для заголовков статей
- Не пропускайте уровни при создании подразделов, т.е. подраздел уровня 2 должен иметь уровень 3 и т.д.
- В заголовках должен использоваться режим набора предложений с большой буквы: "Мой новый заголовок", а не "Мой Новый Заголовок"
- Не используйте ссылки в заголовках, поскольку они разрушают согласованность стиля и не выделяются достаточно хорошо. Обычно целевой текст можно также найти в содержимом раздела; в ином случае можно использовать простой текст вида Смотрите также: Моя новая страница.
  По той же причине не используйте любой вид разметки HTML или wiki, в том числе шаблоны форматирования кода. Смотрите также статью Форматирование и пунктуация
- Для получения дополнительной информации смотрите статью Эффективное использование заголовков

### Форматирование кода

- Используйте шаблон `{{ic|код}}` для небольших строк кода, имен файлов, названий команд, имен переменных и т.п., если они должны находиться внутри строки. Например:
  Выполните `sh ./hello_world.sh` в консоли

- Для единичных строк кода (ввода или вывода командной строки и содержимого файлов), которые должны находиться в отдельном фрейме, просто добавьте в начале один символ пробела (смотрите также раздел Код). Например:

    $ sh ./hello_world.sh

    Hello World

- Используйте шаблон `{{bc|код}}` для нескольких строк кода (ввода или вывода командной строки и содержимого файлов), которые должны находиться в отдельном фрейме, например:

    #!/bin/sh

    # Demo
    echo "Hello World"

- Используйте шаблон `{{hc|ввод|вывод}}`, когда необходимо представить как ввод, так и вывод командной строки, например:

    $ sh ./hello_world.sh

    Hello World

- Когда вам необходимо представить содержимое файла, и вы думаете, что, возможно, читателям будет трудно понять, к какому файлу это содержимое относится, можно также использовать шаблон `{{hc|имя файла|содержимое}}`, чтобы отобразить имя файла в заголовке. Например:

    ~/hello_world.sh

    #!/bin/sh

    # Demo
    echo "Hello World"

- Для получения дополнительной информации и решения проблем с использованием некоторых символов в шаблонах, таких как `=` или `|`, смотрите статью Help:Template

### Текст командной строки

- При использовании блоков с кодом (Template:bc), предваряйте каждую команду правильным символом приглашения. При использовании кода внутри строки (Template:ic) делать это нет необходимости, но любые пометки о правах доступа должны быть явно сделаны в тексте
- В блоках с кодом используйте знак `$` для команд, выполняемых от имени обычного пользователя, и `#` для команд, выполняемых от имени суперпользователя
  Обратите внимание: Символ `#` также нередко используется как символ комментария, так что старайтесь избегать неоднозначности толкования
- Команда всегда должна предваряться объяснением, заканчивающимяся двоеточием (`:`)
- Используйте `# command` вместо `$ sudo command`, если только использование sudo не является действительно необходимым
- Не предполагайте, что на машине пользователя есть `sudo` и подобные ему утилиты (`gksu`, `kdesu` и т. д.).
- `# sudo command` является излишним и его следует избегать. Единственное исключение - использование `sudo` с флагом `-u`: в этом случае приглашение может быть таким же, как и в остальном коде, или тем, что используется по умолчанию (`$`)
- Не добавляйте комментарий в саму команду (например, `# pacman -S foo #Установка пакета foo`)
- Не используйте чрезмерно длинные команды, есть множество способов их разбиения

### Инструкции по редактированию файлов

- Не предполагайте использование конкретного редактора (nano, vim, emacs и т.п.), когда пишете инструкции по редактированию файлов, кроме тех случаев, когда это необходимо
- По этой же причине не используйте команды неявного редактирования, кроме тех случаев, когда это необходимо. Например, команда `$ echo -e "clear\nreset" >> ~/.bash_logout` должна выглядеть так:

  Добавьте следующие строки в `~/.bash_logout`:

      clear
      reset

### Клавиатурные комбинации

- Для выделения клавиатурных сочетаний используйте стандартный способ - Template:ic
- Клавиатурные комбинации должны быть представлены в строчном виде: `a`. Для указания прописных букв используйте `Shift+a` вместо `Shift+A` или `A`
- Правильным способом указания клавиатурных сочетаний является использование символа `+` без дополнительных пробелов, в одном шаблоне: `Ctrl+c`.
  Использование `Ctrl + c`, `Ctrl`+`c` и `Ctrl-c` является неправильным: их следует избегать
- В этом списке перечислены стандартные способы указания некоторых специальных клавиш:
  - `Shift` (а не `SHIFT`)
  - `Ctrl` (а не `CTRL` или `Control`)
  - `Alt` (а не `ALT`)
  - `Super` (а не `Windows` или `Mod`)
  - `Enter` (а не `ENTER` или `Return`)
  - `Esc` (а не `ESC` или `Escape`)
  - `Space` (а не `SPACE`)
  - `Backspace`
  - `Tab`
  - `Ins` (а не `INS` или `Insert`)
  - `Del` (а не `DEL` или `Delete`)
  - `Print Screen`

### Инструкции по управлению пакетами

#### Официальные пакеты

- Пожалуйста, избегайте использования примеров команд pacman, вместо этого давайте ссылки на инструкции по установке официальных пакетов. Это необходимо для простоты (каждый пользователь Arch должен знать большинство команд из статьи pacman), а также во избежание ошибок вида `pacman -Sy пакет` или возможных (но никогда не заканчивающихся) разговоров о выборе между `pacman -S пакет` и `pacman -Syu пакет`. По другим причинам вы не должны советовать использование фронтендов или оберток для pacman.
  Вместо всего этого используйте простые высказывания такого вида:
  Установите пакет из официальных репозиториев.
  Или, если, например, название приложения отличается от имени пакета:
  МоеПриложение можно установить, установив пакет мое-приложение-pkg, доступный в официальных репозиториях.
  Инструкции по установке списка пакетов могут выглядеть так:
  Установите пакет1, пакет2 и пакет3 из официальных репозиториев.
  Вы вольны выбирать слова и предложения, подходящие для вашей статьи
- Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием Template:Pkg. Пример: `{{Pkg|пакет}}`
- В приведенных выше примерах используются неявные ссылки на статьи pacman (Русский) (например, `[[pacman (Русский)#Установка определенных пакетов|Установите]] ...`) и Official Repositories (Русский) (`[[Official Repositories (Русский)|официальные репозитории]]`): рекомендуется использовать их по крайней мере при первом предложении установки, особенно в статьях, посещаемых новичками Arch
- Примеры команд pacman, тем не менее, принято и даже рекомендуется использовать в статье Руководство для новичков
- Если пакет находится в репозиториях core, extra или community, не делайте каких-либо конкретных ссылок на них: это усложнит обслуживание, поскольку время от времени пакеты перемещаются в другие репозитории. Однако, если пакет расположен в официальном репозитории, который выключен по умолчанию (multilib, testing и т.д.), его упоминание необходимо, например, подобным образом:
  Установите пакет из официального репозитория multilib

#### Пакеты из AUR

- Пожалуйста, избегайте использования примеров установки пакетов из AUR, как официального способа, так и с помощниками AUR: каждый пользователь, устанавливающий неофициальные пакеты, должен прочитать статью Arch User Repository и знать о всех возможных последствиях для его системы.
  Вместо этого используйте простые высказывания такого вида:
  Установите пакет из AUR.
  Вы вольны выбирать слова и предложения, подходящие для вашей статьи. Смотрите дополнительные примеры в разделе #Официальные пакеты
- Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием Template:AUR. Пример: `{{AUR|пакет}}`
- Вы всегда должны явно указывать на то, что пакет является неофициальным, предоставляя ссылку на статью Arch User Repository (Русский) или одно из ее перенаправлений, например, AUR (Русский)

#### Неофициальные репозитории

- Если вы советуете использовать неофициальный репозиторий для установки заранее собранного пакета, не предоставляйте инструкций по включению этого репозитория, но убедитесь, что он включен в список неофициальных пользовательских репозиториев, и просто дайте ссылку на этот список. При этом, как и в случае с официальными пакетами, не добавляйте примеров команд pacman. Например:
  Установите пакет из репозитория пример.
  Если пакет также доступен в AUR:
  Установите пакет из AUR или репозитория пример
  Если пакет имеет разные имена:
  Установите пакетaur из AUR или другойпакет из репозитория пример.
  Вы вольны выбирать слова и предложения, подходящие для вашей статьи
- Ссылка на неофициальные пользовательские репозитории является обязательной и должна указывать на раздел, соответствующий конкретному репозиторию. Пример: `[[Unofficial user repositories#пример|пример]]`

### Управление модулями ядра

- Приведение примеров того, как загрузить, удалить, добавить в черный список или осуществить любую другую базовую операцию с модулями, запрещено: стандартная формулировка - это список затрагиваемых модулей, указание возможных зависимостей или конфликтов с другими модулями, описание действий и ссылка на модули ядра
- Статья Руководство для новичков является единственным исключением из приведенного выше правила

### Управление демонами

- Приведение примеров того, как включить, запустить или осуществить любую другую базовую операцию с демонами, запрещено: стандартная формулировка - это список затрагиваемых демонов, указание возможных зависимостей или конфликтов с другими демонами, описание действий и ссылка на раздел Использование юнитов или всю статью systemd (Русский)
- Статья Руководство для новичков является единственным исключением из приведенного выше правила

### Заметки, Предупреждения и Советы

- Для информации, которая так или иначе расходится с тем, что пользователь ожидает в какой-то части статьи, необходимо использовать шаблон Note (Русский). В него также помещается информация, дающая более полные знания о чем-либо конкретном, но не относящемся напрямую к рассматриваемой теме. Другой пример использования - необходимость временно указать на что-либо, например, на изменившееся имя пакета.
  Этот шаблон также может использоваться для выделения информации, которая является важной
- Если описываемые действия могут привести к серьезным последствиям, например, сложности отмены изменений или повреждению системы, необходимо использовать шаблон Warning (Русский). Этот шаблон в целом указывает как на плохие варианты развития событий, так и на условия, способные привести к этому или помогающие этого избежать
- Шаблон Tip (Русский) указывает на действия, которые могут быть полезны или принесут пользу кому-либо, хотя и не нужны для завершения операции, и которые можно благополучно проигнорировать
- Если необходимо использовать два или более шаблона Note, Warning или Tip, идущих друг за другом в одном месте статьи, лучше сгруппировать их содержимое в список внутри одного шаблона, избегая при этом их нагромождения. Исключением является ситуация, в которой их содержимое не имеет друг к другу никакого отношения. Пример:

  Совет:
  - Пример совета №1
  - Пример совета №2

### Командные оболочки

Не предполагайте использование конкретной оболочки (например, bash), кроме тех случаев, когда это действительно необходимо: при написании или редактировании статей старайтесь по возможности использовать нейтральные к этому команды

### Использование гипертекста

- Старайтесь вставлять в ваши статьи настолько много внутренних ссылок, насколько это возможно, используя различные ключевые слова в тексте
- Для технических терминов, таких как системный вызов, не освещенных в статьях ArchWiki, давайте соответствующие ссылки на страницы Википедии
- При создании ссылок на другие статьи wiki не используйте полные URL-адреса, используйте все возможности специального синтаксиса для внутренних ссылок: `[[Статья Wiki]]`. В числе прочего, это позволит движку wiki отслеживать внешние ссылки и, соответственно, облегчит техническое обслуживание.
  Для получения более полной информации по использованию синтаксиса interwiki-ссылок, смотрите раздел Ссылки
- Старайтесь избегать использования скрытых ссылок там, где это возможно. Например, более предпочтительным является использование инструкций вида "Для получения дополнительной информации смотрите статью systemd" вместо "Для получения дополнительной информации загляните сюда"
- За исключением редких случаев вы не должны оставлять статью как "тупиковую страницу" (статья, в которой не содержится ссылок на другие статьи) или "страницу-сироту" (статья, на которую не ссылается ни одна другая статья)
- Перед тем, как описывать в статье специфичные действия или частные случаи, всегда проверяйте, существует ли другая статья, подробно описывающая это. Если она существует, создайте ссылку на нее вместо того, чтобы дублировать ее содержимое
- Если upstream-документация по предмету статьи хорошо написана и поддерживается, желательно описать лишь специфичные для Arch действия и создать ссылку на официальную документацию для получения основной информации
- Не используйте внутренние межъязыковые ссылки на локализованные страницы в тексте статей, поскольку они будут отображаться на страницах Ссылки сюда. Например, использование `[[ru:Main Page]]` в русской статье недопустимо, тогда как `[[Main Page (Русский)]]` - корректно.
  При этом использование таких ссылок между различными языками приемлемо, поскольку будет легче перемещать статьи в отдельные wiki в тех случаях, когда они будут созданы в будущем.
  Наконец, обратите внимание на отличие этого вида ссылок от межъязыковых: они не добавляются в соответствующую колонку слева

### Стилистика кода

- При добавлении команд или скриптов используйте единый стиль оформления кода во всей статье, по возможности соотносящийся с другими страницами, связанными с вашей. Придерживайтесь официальных и общих рекомендаций оформления кода для вашего языка
- Избегайте использования устаревших функций языка программирования/скриптов: например, используйте синтаксис `$()` для подстановки команды оболочки вместо обратных кавычек (````)

### Поддерживаемые версии ядра

Не удаляйте никаких пометок и рекомендаций, относящихся к версиям ядра, начиная с текущей версии пакета linux-lts в репозитории core и заканчивая самой свежей версией с установочного носителя

### Разделы "Советы и рекомендации"

- Разделы Советы и рекомендации предлагают дополнительные советы или примеры использования программного обеспечения
- Используйте только стандартный заголовок Советы и рекоммендации
- Различные Советы и рекоммендации должны быть разбиты на подразделы

### Разделы "Решение проблем"

- Разделы Решение проблем используются для ответов на часто задаваемые вопросы относительно программного обеспечения, а также описания методов решения общих проблем (они похожи на #Разделы "Известные ошибки")
- Используйте только стандартный заголовок Решение проблем. Возможны опечатки, которых следует избегать: Решениепроблем, Решение-проблем или Решение Проблем
- Вы также можете сообщить о временных способах решения проблем для известных багов, но в этом случае крайне желательно предоставить ссылку на багрепорт. Если багрепорта еще не существует, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен.
  Как для читателей, так и для редакторов есть большие преимущества в предоставлении ссылок на багрепорты:
  - Для читателей: Wiki не станет конечной точкой, непосредственно в источнике они смогут найти больше информации, которую могли бы упустить при поиске
  - Для редакторов Wiki: благодаря этому легче проводить очистку от ненужной информации за счет уменьшения усилий на выяснение того, исправлен баг или нет. Может случиться и так, что читатель найдет новую информацию и вернется к статье, чтобы ее отредактировать

### Разделы "Известные ошибки"

- Разделы Известные ошибки используются для описания известных багов или проблем, которые еще не решены (похоже на #Разделы "Решение проблем")
- Используйте только стандартный заголовок Известные ошибки
- Если для известной ошибки существует багрепорт, крайне желательно предоставить на него ссылку. Если багрепорта еще не существует, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен

### Разделы "Смотрите также"

- Разделы Смотрите также содержат список ссылок на руководства и источники для получения дополнительной информации
- В этом разделе каждый пункт начинается с символа `*`, создающего маркированный список MediaWiki
- Используйте только стандартный заголовок Смотрите также. Необходимо избегать использования похожих заголовков, таких как Внешние ссылки, Больше ресурсов и т.п.

### Недопустимое содержимое

- Пожалуйста, не подписывайте статьи и не представляйте авторов: ArchWiki создается благодаря усилиям всего сообщества, и истории изменений в каждой статье достаточно, чтобы узнать, кто принимал участие в ее написании.
  Однако, указание источников, использованных при написании статьи, является хорошей практикой. Используйте для этой цели раздел "Смотрите также"
- Обычным пользователям не разрешено загружать файлы и включать существующие изображения в статьи. Вместо этого вы можете добавлять ссылки на изображения или галереи, а если есть необходимость вставить простые диаграммы, можно воспользоваться редактором ASCII, таким как Asciiflow. Причины:
  - Обслуживание: в Arch используется модель rolling-release, и наличие изображений сделает обновление статей гораздо более сложным занятием
  - Необходимость: Arch не разрабатывает и не поддерживает никаких графических приложений, поэтому у нас нет необходимости предоставлять скриншоты
  - Модерация: возможность свободной загрузки изображений потребует затрат дополнительного времени, связанных с их удалением, например, если они будут слишком большими или неуместными
  - Доступность: мы обеспечиваем поддержку пользователям с медленными соединениями, текстовыми браузерами, программами чтения с экрана и т.д.
  - Эффективность: изображения значительно уменьшают пропускную способность сервера и свободное пространство на дисках
  - Простота: статьи, в которых используется только текст, смотрятся проще и опрятнее

### Языковые обороты

- Статьи должны писаться в формальном, профессиональном и лаконичном стиле
- Давайте ответы не только на вопросы "как?", но и на вопросы "почему?". Пояснения всегда помогают легче запомнить (а следовательно, и передать дальше) информацию, чем простой набор команд
- Не используйте сокращений, таких как "уст-ка", "обновл-е" и т.д. Постарайтесь избегать типичных нераспространенных сокращений "т.к.", "т.о." и им подобных: найдите другой способ сжимать ваши предложения (например, избавляя их от слов-паразитов)
- Избегайте ненужных укорочений слов. Например, вместо "репа", "дистр" и "конфиг" необходимо использовать "репозиторий", "дистрибутив" и "конфигурация".
  Таким же образом предпочтительным является использование длинных форм редких опций команд вместо их односимвольных аналогов
- Не пренебрегайте терминами, которые являются важными, чтобы передавать в предложениях точный и однозначный смысл. Например, всегда добавляйте слово "репозиторий", когда называете имя репозитория
- Пишите объективно: не включайте в статьи персональные комментарии, используйте для этого страницы обсуждений. В общем смысле, не пишите от первого лица

## Страницы обсуждений

- Создавайте новые обсуждения внизу страниц обсуждений и добавляйте соответствующий заголовок. Также можно использовать ссылку `+` вверху любой страницы обсуждения
- Делайте отступы при написании ответов, используя двоеточия в начале новых строк
- Не редактируйте ваши сообщения, если кто-либо уже ответил после вас, иначе вы можете запутать ход обсуждения и сделать его сложным для понимания. Допускается только зачеркивать (используя HTML-тэг `<s>`) слова или предложения, но даже при этом необходимо в обычном ответе давать объяснения подобным действиям
- Всегда добавляйте подписи (используя `~~~~`) к вашим правкам
- Страницы обсуждений не должны иметь категорий
- Необходимо быть осторожным при зачеркивании заголовков исчерпанных обсуждений с использованием HTML-тэгов `<s>`.
  Такие обсуждения должны удаляться не менее, чем через три дня после зачеркивания
- Смотрите также раздел Help:Editing (Русский)#Страницы обсуждений

## Страницы категорий

- Каждая категория должна быть включена хотя бы в одну соответствующую родительскую категорию, исключением являются лишь корневые категории.
  Корневыми категориями являются Category:DeveloperWiki, Category:Languages и Category:Sandbox
- Категория может быть включена не в одну, а в несколько категорий, при условии, что она не является родительской для других
- Избегайте круговых отношений: две категории не могут быть взаимно родительскими
- Не включайте категорию в саму себя (получится категория, родительская для самой себя)
- Категории должны находиться в верху страницы категорий
- Категории не должны являться перенаправлениями

## Страницы-перенаправления

- Страницы-перенаправления должны содержать лишь код перенаправления и ничего больше
- Создавайте перенаправления только на внутренние статьи: не используйте перенаправления на другие wiki

## Страницы шаблонов

Смотрите статью Help:Template.

## Страницы пользователей

- Страницы в пространстве имен User не подлежат категоризации
- Ссылки на страницы из пространства имен User можно создавать только со страниц пространств User и talk, кроме случаев, когда разрешение на подобные действия выдается администраторами

## Общие правила

### Краткое описание изменений

- Правки, вносимые в статьи в течение дня, храбро и добровольно отслеживают преданные патрульные, которым вы должны помогать, каждый раз проверяя, добавлена ли к вашей правке фраза-объяснение в поле "Описание изменений" на странице редактирования
  - Если правка является незначительной (например, исправление грамматических и орфографических ошибок или перефразирование), вполне достаточно простого описания вашего изменения
  - Если вы готовите серьезное изменение, такое как добавление, перемещение, изменение или удаление содержимого, помимо краткого описания необходимо объяснить, зачем вы отредактировали статью, хотя бы дав ссылку на обсуждение в wiki или на форумах, если оно существует
  - Объяснение на страницах обсуждений не является обязательным в тех случаях, когда ваши изменения очевидны.
    При удалении исчерпанного обсуждения, однако, необходимо написать несколько объясняющих слов (например, "обсуждение закрыто", "исправлено" и т.п.) и добавить его заголовок. В этом случае в истории будет видно, что вы сделали, и, возможно, вашу правку не потребуется проверять

    Совет: Взгляните на краткие описания изменений на странице свежих правок, чтобы понять, как их писать, но имейте в виду, что, к сожалению, не все пользователи уважительно относятся к этому правилу

- Если вы готовите серьезные изменения в статьях, лучше постарайтесь разделить вашу работу на несколько правок, основываясь на логике шагов, которые вам необходимо предпринять для завершения изменения.
  Особенно это касается перемещения разделов (внутри одной статьи или между разными статьями): вы должны избегать внесения изменений в их содержимое и перемещения в одной правке, иначе будет гораздо сложнее производить сравнение версий

### Теги HTML

- Использование тэгов HTML крайне не рекомендуется: всегда старайтесь использовать wiki-разметку или шаблоны, где это возможно. Смотрите статьи Редактирование и связанные с ней
- Когда есть соблазн использовать `<pre>код</pre>`, используйте `{{bc|код}}`. Когда есть соблазн использовать `<tt>текст</tt>` или `<code>текст</code>`, используйте `{{ic|текст}}`
- В особенности избегайте комментариев HTML (`<!-- комментарий -->`): вполне вероятно, что такая заметка может быть явно показана на странице обсуждения статьи.
  Вы можете добавить соответствующий шаблон состояния статьи вместо подобного комментария
- Используйте `<br>` только при необходимости: для создания нового абзаца или разрыва строки достаточно оставить одну пустую строчку.
  Типичные исключения из этого правила:
  - Разрыв строки в элементе списка и невозможность при этом использовать элемент более низкого уровня
  - Разрыв строки внутри шаблона и невозможность при этом использовать список

Categories:

- Help (Русский)
- Русский