Help:Style (Русский)
Ссылки по теме
Приведенные здесь правила призваны способствовать созданию кратких, легко читаемых статей и поддержанию единого стиля. Следуйте им как можно тщательнее, редактируя статьи на ArchWiki.
Contents
-
1 Страницы статей
- 1.1 Заголовок
- 1.2 Структура
- 1.3 Магические слова
- 1.4 Категории
- 1.5 Межъязыковые ссылки
- 1.6 Шаблоны состояния статьи
- 1.7 Блок "Ссылки по теме"
- 1.8 Предисловие или введение
- 1.9 Заголовки разделов
- 1.10 Форматирование кода
- 1.11 Текст командной строки
- 1.12 Инструкции по редактированию файлов
- 1.13 Клавиши и их сочетания
- 1.14 Инструкции по управлению пакетами
- 1.15 Управление юнитами systemd
- 1.16 Блоки Обратите внимание, Важно и Совет
- 1.17 Командные оболочки
- 1.18 Метафора гипертекста
- 1.19 Оформление кода
- 1.20 Поддерживаемые версии ядра
- 1.21 Разделы "Советы и рекомендации"
- 1.22 Разделы "Решение проблем"
- 1.23 Разделы "Известные проблемы"
- 1.24 Разделы "Смотрите также"
- 1.25 Недопустимое содержимое
- 1.26 Языковые обороты
- 2 Страницы категорий
- 3 Страницы-перенаправления
- 4 Страницы пользователей
- 5 Общие правила
Страницы статей
Заголовок
- Регистр букв в заголовках должен соответствовать режиму набора предложений с большой буквы: например, написание "Title for new page" является правильным, а "Title for New Page" — нет. При этом, если в заголовке присутствуют общие слова, которые являются частью имени собственного или аббревиатурой с написанием в верхнем регистре, они должны писаться прописными буквами: например, "Advanced Linux Sound Architecture", а не "Advanced Linux sound architecture".
- Пространства имен не считаются частью заголовков, поэтому написание "ArchWiki:Новая статья" является правильным, а "ArchWiki:новая статья" — нет.
- Имена подстраниц должны начинаться с прописной буквы: например, написание "Моя страница/Моя подстраница" является правильным, а "Моя страница/моя подстраница" — нет.
- По умолчанию, подлежащее в названии должно быть в единственном числе. Однако, следует использовать множественное число, если оно является исчисляемым и подразумевает собой группу/класс сущностей.
- Если предмет статьи широко известен как под своим полным именем, так и в аббревиатуре, предпочтительным является использование в названии статьи полного имени. Не включайте и полное имя, и аббревиатуру (например, в скобках) в название статьи — используйте перенаправление со страницы с аббревиатурой на страницу с полным названием.
- Для получения дополнительной информации смотрите Help:Указания по выбору имен статей.
Структура
- Используйте следующий порядок элементов в статье:
- #Магические слова (необязательно)
- #Категории
- #Межъязыковые ссылки
- #Шаблоны состояния статьи (необязательно)
- #Блок ссылок по теме (необязательно)
- #Предисловие или введение
- Оглавление (генерируется автоматически, если есть достаточное количество разделов)
- Специфичные для статьи разделы
Магические слова
- Переключатели поведения, и, в общем, все магические слова, изменяющие отображение или поведение статьи, но при этом не добавляющие в нее какого-либо содержимого, всегда должны находиться в самом начале страницы.
- В частности, это правило применяется также к
{{DISPLAYTITLE:title}}
и Template:Lowercase title.
Категории
- Любая статья должна относиться хотя бы к одной существующей категории.
- Статья может быть отнесена к нескольким категориям, если они не являются родительскими друг для друга.
- Категории должны быть перечислены в самом начале статьи, сразу после любых магических слов.
- Во избежание появления лишнего пустого пространства вверху страницы, между категориями и первой строкой текста (или межъязыковыми ссылками, если они есть) не должно быть пустых строк.
- Для получения дополнительной информации смотрите статью Help:Категория.
Межъязыковые ссылки
- Если у статьи имеются переводы на другие языки (в т. ч. и на выделенных языковых сайтах ArchWiki), сразу за категориями и перед первой строкой текста должны быть добавлены межъязыковые ссылки.
- Обратите внимание, что они появятся в соответствующей колонке в левой части страницы.
- Во избежание появления лишнего пустого пространства вверху страницы, между межъязыковыми ссылками и первой строкой текста не должно быть пустых строк.
- При добавлении или редактировании межъязыковых ссылок вы должны позаботиться о том, чтобы продублировать ваши действия на страницах других переводов.
- Не добавляйте в статьи более одной ссылки для одного языка.
- Не добавляйте на страницу межъязыковую ссылку, которая ведет на нее саму же (то есть, имеет тот же язык).
- Межъязыковые ссылки должны быть отсортированы в алфавитном порядке на основе языковых тегов, а не на основе местных названий: например, ссылка
[[fi:Название]]
должна идти перед[[fr:Название]]
, даже если в местном языке слово "Suomi" идет после "Français". - Для получения дополнительной информации смотрите Help:i18n (Русский) и Wikipedia:ru:Википедия:Интервики#Ссылки на статьи в иноязычных разделах по той же теме.
Шаблоны состояния статьи
- Шаблоны состояния статьи могут быть помещены после категорий (или межъязыковых ссылок, если они есть) и перед введением (или блоком ссылок по теме, если он есть).
- При необходимости можно добавлять шаблоны состояния в текст разделов.
- Всегда сопровождайте шаблон состояния несколькими поясняющими словами в предназначенном для этого аргументе шаблона (примеры есть на страницах соответствующих шаблонов), при этом, возможно, создав обсуждение на talk-странице.
Блок "Ссылки по теме"
- Представляет собой простой список связанных статей по какой-то теме.
- Рекомендуется размещать блок сразу после категорий (либо после межъязыковых ссылок/шаблонов состояния статьи, если они есть).
- Для ее создания необходимо использовать только Template:Related articles start (Русский), Template:Related и Template:Related articles end. Смотрите указания по применению на страницах этих шаблонов.
- Используйте #Раздел "Смотрите также" для создания более полного и детального списка, в который также можно включить описания, интервики- и внешние ссылки.
Предисловие или введение
- Описывает предмет статьи.
- Вместо перефразирования или написания вашего собственного (возможно, предвзятого) описания программы или компонента, вы можете использовать описание, предоставленное самим автором. Обычно его можно найти на домашней странице проекта, если она существует. Например, посмотрите MediaTomb.
- Располагается непосредственно перед первым разделом статьи.
- Не имеет собственного раздела, текст идет сразу после заголовка статьи. Не создавайте разделов с названиями
== Предисловие ==
или== Введение ==
. Оглавление будет создано автоматически между предисловием и первым разделом, когда в статье будет достаточно разделов. - Для получения дополнительной информации смотрите Help:Написание введений для статей.
Заголовки разделов
- Заголовки должны начинаться со 2 (
==
) уровня, поскольку первый уровень (соответствующий тегу<h1>
) зарезервирован для заголовков статей. - Не пропускайте уровни при создании подразделов, т. е. раздел уровня 2 может содержать только подразделы уровня 3.
- В заголовках должен использоваться режим набора предложений с большой буквы: "Мой новый заголовок", а не "Мой Новый Заголовок".
- Не используйте ссылки в заголовках, поскольку они разрушают согласованность стиля и не выделяются достаточно хорошо. Обычно, ничто не мешает указать ссылку в самом тексте раздела.
- По той же причине не используйте HTML, вики-разметку, и шаблоны форматирования кода. Смотрите также статью Help:Стиль/Форматирование и пунктуация.
- Для получения дополнительной информации смотрите статью Help:Эффективное использование заголовков.
Форматирование кода
- Используйте шаблон
{{ic|код}}
для небольших строк кода, имен файлов, названий команд, имен переменных и т. п., если они должны находиться внутри предложения. Например:
- Выполните
sh ./hello_world.sh
в консоли.
- Выполните
- Для единичных строк кода (ввода или вывода командной строки и содержимого файлов), которые должны располагаться в отдельном блоке, просто добавьте в начале строки один символ пробела (смотрите также Help:Редактирование#Код). Например:
$ 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:ic) не нужно указывать символ приглашения (
$
или#
). При необходимости, замечания о необходимых правах доступа должны быть явно указаны в тексте. - При использовании блоков с кодом (оформленных с помощью отступов или шаблона Template:bc), предваряйте каждую команду правильным символом приглашения:
$
для команд, выполняемых от имени обычного пользователя, и#
для команд, выполняемых от имени суперпользователя.
- Блоки с кодом следует располагать после текста объяснения, заканчивающегося двоеточием (
:
). - Используйте
# command
вместо$ sudo command
, если только использование sudo не является действительно необходимым. - Не используйте вместе символ приглашения от имени суперпользователя и команду sudo, как в этом примере:
# sudo команда
Единственное исключение — использование sudo с флагом-u
: в этом случае символ приглашения может быть таким же, как и в других строках, либо используемым по умолчанию$
. - Не добавляйте комментарий после команды в той же строке (например,
# pacman -S foo #Установка пакета foo
). - Не используйте чрезмерно длинные строки с командами, есть множество способов их разбиения.
- Блоки с кодом следует располагать после текста объяснения, заканчивающегося двоеточием (
- Не предполагайте, что на машине пользователя есть sudo и подобные ему утилиты (gksu, kdesu и т.д.).
Инструкции по редактированию файлов
- Не предполагайте использование конкретного редактора (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
.
- Правильный способ указания последовательностей нажатий клавиш — либо в виде явного изложения (например, "нажмите клавишу
g
, а затемShift+t
"), либо кратко, с разделением одинарным пробелом клавиш, указываемых в разных блоках шаблона:g
Shift+t
. - В этом списке перечислены стандартные способы указания некоторых специальных клавиш:
-
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
) -
PrintScreen
-
PageUp
-
PageDown
-
Инструкции по управлению пакетами
Официальные пакеты
- Пожалуйста, избегайте использования примеров команд pacman, вместо этого давайте ссылки на инструкции по установке официальных пакетов. Это необходимо для простоты (каждый пользователь Arch должен знать большинство команд из статьи pacman), а также во избежание ошибок вида
pacman -Sy пакет
или возможных (но никогда не заканчивающихся) споров о выборе междуpacman -S пакет
иpacman -Syu пакет
. По другим причинам вы не должны советовать использование фронтендов или оберток для pacman.
- Вместо всего этого используйте простые шаблонные фразы такого вида:
- Или, если, например, название приложения отличается от имени пакета:
- Установите MyApplication с пакетом my-app-pkg, доступном в официальных репозиториях.
- Инструкции по установке списка пакетов могут выглядеть так:
- Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
- Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием Template:Pkg. Пример:
{{Pkg|пакет}}
. - В приведенных выше примерах используются неявные ссылки на статьи pacman (Русский) (например,
[[Установите]] ...
) и Official Repositories (Русский) ([[Official Repositories (Русский)|официальные репозитории]]
): рекомендуется использовать их по крайней мере при первом предложении установки, особенно в статьях, которые ориентированы на новичков в Arch. - Примеры команд pacman, тем не менее, принято и даже рекомендуется использовать в статье Руководство для новичков.
- Если пакет находится в репозиториях core, extra или community, не делайте каких-либо конкретных ссылок на них: это ничего не дает и только добавляет работы, когда пакет переносится в другой репозиторий. Однако, если пакет расположен в официальном репозитории, который выключен по умолчанию (multilib, testing и т. д.), его упоминание необходимо, например, подобным образом:
- Установите пакет из официального репозитория multilib.
Пакеты из AUR
- Пожалуйста, избегайте использования примеров установки пакетов из AUR, как с использованием официального способа, так и с помощью инструментов AUR: каждый пользователь, устанавливающий неофициальные пакеты, должен прочесть статью Arch User Repository (Русский) и знать о всех возможных последствиях для его системы.
- Вместо этого используйте простые высказывания такого вида:
- Вы в праве перефразировать это предложение для большего соответствия вашей статье.
- Смотрите дополнительные примеры в разделе #Официальные пакеты.
- Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием Template:AUR. Пример:
{{AUR|пакет}}
- Вы всегда должны явно указывать на то, что пакет является неофициальным, предоставляя ссылку на статью Arch User Repository (Русский) или одно из ее перенаправлений, например, AUR (Русский).
Неофициальные репозитории
- Если вы предлагаете использовать неофициальный репозиторий для установки заранее собранного пакета, не предоставляйте инструкций по включению этого репозитория, но убедитесь, что он включен в список Unofficial user repositories и просто дайте на него ссылку. При этом, как и в случае с официальными пакетами, не добавляйте примеров команд pacman. Например:
- Установите пакет из репозитория пример.
- Если пакет также доступен в AUR:
- Если пакет имеет разные имена:
- Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
- Ссылка на Unofficial user repositories является обязательной и должна указывать на раздел, соответствующий конкретному репозиторию. Пример:
[[Unofficial user repositories#example|пример]]
.
Управление юнитами systemd
- Не приводите примеров того, как включить, запустить или осуществить любую другую базовую операцию с юнитами systemd при помощи systemctl. Вместо этого используйте предложения, содержащие список затрагиваемых юнитов с указанием возможных зависимостей или конфликтов с другими юнитами, а также описание необходимых действий. Например:
- Чтобы GDM запускался во время загрузки системы, включите службу
gdm.service
.
- Чтобы GDM запускался во время загрузки системы, включите службу
- Или же, если, например, юнит является шаблоном, которому требуется указать аргумент:
- Чтобы на беспроводном интерфейсе работало автоматическое переключение между профилями netctl, включите экземпляр службы
netctl-auto@.service
, добавив имя интерфейса, например,netctl-auto@wlan0.service
.
- Чтобы на беспроводном интерфейсе работало автоматическое переключение между профилями netctl, включите экземпляр службы
- Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
- Удостоверьтесь, что вы привели ссылку на раздел systemd (Русский)#Использование юнитов, либо прямую, либо при помощи специального перенаправления (например,
[[запустите]]
,[[включите]]
или[[остановите]]
). - Тем не менее, приведение примеров команд systemctl в статье Руководство для новичков допустимо и желательно.
Блоки Обратите внимание, Важно и Совет
- Для информации, которая так или иначе расходится с тем, что пользователь ожидает в какой-то части статьи, необходимо использовать блок "Обратите внимание" (шаблон Note (Русский)). В него также помещается информация, дающая более полные знания о чем-либо конкретном, но не относящемся напрямую к рассматриваемой теме. Другой пример использования — необходимость временно указать на что-либо, например, на изменившееся имя пакета.
- Этот блок также может использоваться для выделения информации, которая является важной, но ее легко упустить из внимания.
- Если описываемые действия могут привести к серьезным последствиям, приводящим к повреждению системы либо необратимым простыми способами изменениям, необходимо использовать блок "Важно" (шаблон Warning (Русский)). Этот блок в целом указывает как на плохие варианты развития событий, так и на условия, способные привести к этому или помогающие этого избежать.
- Не злоупотребляйте блоками Важно. Если вы не уверены, что выбрать, используйте блок Обратите внимание.
- Блок "Совет" (шаблон Tip (Русский)) указывает на действия, которые могут быть полезны или принесут пользу кому-либо, хотя и не нужны для завершения операции, и которые можно благополучно проигнорировать.
- Если необходимо использовать два или более блока Обратите внимание, Важно или Совет, идущих друг за другом в одном месте статьи, лучше сгруппировать их содержимое в список внутри одного шаблона. Исключением является ситуация, в которой содержимое блоков слишком отличается по смыслу для группировки. Пример:
Командные оболочки
- Не предполагайте использование конкретной оболочки (например, bash), кроме тех случаев, когда это действительно необходимо. При написании или редактировании статей старайтесь по возможности не использовать команды, специфичные для какой-то одной оболочки.
Метафора гипертекста
- Старайтесь вставлять в ваши статьи как можно больше внутренних ссылок, выделяя различные ключевые слова в тексте.
- Не создавайте ссылки на несуществующие страницы, даже если вы уверены, что такие страницы скоро будут созданы.
- Для технических терминов, таких как системный вызов, не освещенных в статьях ArchWiki, давайте соответствующие ссылки на страницы Википедии.
- При создании ссылок на другие статьи ArchWiki не используйте полные URL-адреса. Всегда оформляйте их как внутренние ссылки:
[[Статья Wiki]]
. Это просто удобно, а также позволит вики-движку отслеживать внешние ссылки и, соответственно, облегчит контроль над статьями.
- Для получения более полной информации по использованию синтаксиса интервики-ссылок, смотрите раздел Help:Редактирование#Ссылки.
- Старайтесь избегать использования скрытых ссылок там, где это возможно. Более предпочтительным является использование выражений вида "Для получения дополнительной информации смотрите статью systemd" вместо "Для получения дополнительной информации загляните сюда".
- За исключением редких случаев вы не должны создавать "тупиковые страницы" (страница, которая не ссылается на другие страницы) или "осиротевшие страницы" (страница, на которую не ссылаются другие страницы).
- Перед тем, как описывать в статье конкретные действия или какие-то подробности, всегда проверяйте, существует ли другая статья, в которой содержится подобный текст. Если она существует, просто сошлитесь на нее вместо того, чтобы дублировать содержимое.
- Если основная документация по предмету статьи хорошо написана и поддерживается, желательно привести лишь информацию, специфичную для Arch, при этом создав ссылку на официальную документацию как на основной источник.
- Не используйте внутренние межъязыковые ссылки на локализованные страницы в тексте статей, поскольку они будут отображаться на страницах Ссылки сюда. Например, использование
[[ru:Main Page]]
в русской статье недопустимо, тогда как[[Main Page (Русский)]]
— корректно.
- При этом использование таких ссылок в тексте между страницами на разных языках приемлемо, поскольку это облегчит перенос переводов на выделенные локализованные вики-сайты ArchWiki в случае их появления.
- Наконец, обратите внимание на отличие этого вида ссылок от межъязыковых, которые не начинаются с двоеточия.
Оформление кода
- При добавлении команд или скриптов используйте единый стиль написания кода во всей статье, по возможности соотносящийся с другими страницами, связанными с вашей. Придерживайтесь официальных и общих рекомендаций оформления кода для вашего языка.
- Избегайте использования устаревших функций языка программирования/скриптов: например, используйте синтаксис
$()
для подстановки команды оболочки вместо обратных кавычек (``
).
Поддерживаемые версии ядра
Не удаляйте из статей важных замечаний, которые относятся к версиям ядра, начиная с текущей версии пакета linux-lts в репозитории core и заканчивая самой свежей версией с установочного образа.
Разделы "Советы и рекомендации"
- Разделы Советы и рекомендации содержат дополнительные советы и примеры использования программного обеспечения.
- Используйте только стандартный заголовок Советы и рекомендации.
- Различные советы и рекомендации должны быть разбиты на подразделы.
Разделы "Решение проблем"
- Разделы Решение проблем используются для ответов на часто задаваемые вопросы относительно программного обеспечения, а также описания методов решения общих проблем (они похожи на #Разделы "Известные проблемы").
- Используйте только стандартный заголовок Решение проблем.
- Вы также можете сообщить о временных способах решения проблем для известных багов, но в этом случае крайне желательно дать ссылку на баг-репорт. Если баг-репорта еще не существует, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен.
- Как для читателей, так и для редакторов есть большие преимущества в предоставлении ссылок на баг-репорты:
- Для читателей: статья не станет конечной точкой, пройдя по ссылке, читатели смогут найти больше информации, которую могли бы пропустить при самостоятельном поиске.
- Для редакторов: благодаря этому легче проверять актуальность приведенной информации, просто просмотрев, исправлен баг или нет, и своевременно выполнять очистку статьи от нее. Может случиться и так, что читатель сам обнаружит это и вернется к статье, чтобы ее отредактировать.
Разделы "Известные проблемы"
- Разделы Известные проблемы используются для описания известных багов или проблем, которые еще не решены (в отличие от #Разделы "Решение проблем").
- Используйте только стандартный заголовок Известные проблемы.
- Если для известной проблемы существует баг-репорт, крайне желательно предоставить на него ссылку. Если баг-репорт еще не создан, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен.
Разделы "Смотрите также"
- Разделы Смотрите также содержат список ссылок на руководства и источники дополнительной информации.
- В этом разделе содержится только маркированный список, таким образом, каждая ссылка начинается с
*
. - Используйте только стандартный заголовок Смотрите также. Необходимо избегать использования похожих заголовков, таких как Ссылки, Внешние ссылки, См. также и т. п.
Недопустимое содержимое
- Пожалуйста, не подписывайте статьи и не представляйте авторов: ArchWiki создается благодаря усилиям всего сообщества, и истории изменений в каждой статье достаточно, чтобы узнать, кто принимал участие в ее написании.
- Однако, указание источников, использованных при написании статьи, является хорошей практикой. Используйте для этой цели раздел "Смотрите также".
- Обычным пользователям не разрешено загружать файлы и включать существующие изображения в статьи. Вместо этого вы можете добавлять ссылки на изображения или галереи, а если есть необходимость вставить простые диаграммы, можно воспользоваться ASCII-редактором, например Asciiflow. Обоснование:
- Обслуживание: в выпусках Arch Linux используется модель rolling-release, и наличие изображений усложнит обновление статей.
- Необходимость: Arch не разрабатывает и не поддерживает никаких графических приложений, поэтому у нас нет необходимости предоставлять скриншоты.
- Модерация: возможность свободной загрузки изображений потребует затрат дополнительного времени, связанных с их удалением, например, если они будут слишком большими или неуместными.
- Доступность: мы обеспечиваем поддержку пользователям с медленными соединениями, текстовыми браузерами, программами чтения с экрана и т. д.
- Эффективность: изображения значительно уменьшают пропускную способность сервера и свободное пространство на дисках.
- Простота: статьи, в которых используется только текст, смотрятся проще и опрятнее.
Языковые обороты
- Статьи должны писаться в формальном, профессиональном и лаконичном стиле. Следует позаботиться об удалении грамматических и орфографических ошибок, специально вычитывая их текст.
- Давайте ответы не только на вопросы "как?", но и на вопросы "почему?". Пояснения всегда помогают легче запомнить (а следовательно, и передать дальше) информацию, чем простой набор команд.
- В англоязычном тексте не используйте сокращений вроде "don't", "isn't", "you've"; пишите: "do not", "is not", и "you have" и т. д.
- Избегайте ненужных укорочений слов. Например, вместо "репа", "дистр" и "конфиг" пишите "репозиторий", "дистрибутив" и "конфигурация".
- Таким же образом предпочтительным является использование длинных форм редких опций команд вместо их односимвольных аналогов.
- Также избегайте сокращений вроде "уст-ка", "обновл-е" и т. д. Постарайтесь избегать типичных нераспространенных сокращений "т. к.", "т. о." и им подобных: найдите другой способ сжимать ваши предложения (например, избавляя их от слов-паразитов).
- Не пренебрегайте терминами, которые являются важными, чтобы передавать в предложениях точный и однозначный смысл. Например, всегда добавляйте слово "репозиторий", когда называете имя репозитория.
- Пишите объективно: не включайте в статьи персональные комментарии, используйте для этого страницы обсуждений. Не пишите статьи от первого лица.
Страницы категорий
- Каждая категория должна быть включена хотя бы в одну соответствующую родительскую категорию, исключениями являются лишь корневые категории.
- Корневыми категориями являются Category:DeveloperWiki, Category:Languages и Category:Sandbox.
- Категория может быть включена сразу в несколько категорий, при условии, что она не является родительской для других.
- Избегайте круговых отношений: две категории не могут быть взаимно родительскими.
- Не включайте категорию в саму себя (получится категория, родительская для самой себя).
- Список родительских категорий должен располагаться наверху страницы категории.
- Категории не должны являться перенаправлениями.
- По умолчанию, подлежащее в заголовке категории должно быть указано в единственном числе для тематических категорий (Category:Kernel), и в множественном — для категорий-списков (Category:Stacking WMs).
Страницы-перенаправления
- Страницы-перенаправления должны содержать лишь директиву перенаправления и ничего больше.
- Создавайте перенаправления только на внутренние статьи: не используйте интервики-ссылки в перенаправлениях.
Страницы пользователей
- Страницы в пространстве имен User не должны быть включены в какую-либо категорию.
- Ссылки на страницы из пространства имен User можно создавать только со страниц пространств User, Talk, и *_talk, кроме случаев, когда разрешение на подобные действия выдается администраторами.
Общие правила
Краткое описание изменений
Смотрите ArchWiki:Внесение вклада#Три основных правила.
HTML-теги
- Использование HTML-тегов крайне не рекомендуется: всегда старайтесь использовать вики-разметку или шаблоны везде, где это возможно. Смотрите Help:Редактирование и связанные статьи.
- Когда хочется написать
<pre>код</pre>
, используйте{{bc|код}}
. Когда хочется написать<tt>текст</tt>
или<code>текст</code>
, используйте{{ic|текст}}
. - В особенности избегайте комментариев HTML (
<!-- комментарий -->
): вполне вероятно, что такая заметка может быть явно показана на странице обсуждения статьи.
- Вы можете добавить соответствующий шаблон состояния статьи вместо подобного комментария.
- Используйте
<br>
только при необходимости: для создания нового абзаца или разрыва строки достаточно оставить одну пустую строчку.
- Типичные исключения из этого правила:
- Для разрыва строки в пункте списка, когда не хочется при этом создавать подпункты.
- Для разрыв строки внутри шаблона, когда не хочется при этом использовать список.