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

From ArchWiki

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

Состояние перевода: На этой странице представлен перевод статьи Help:Style. Дата последней синхронизации: 21 декабря 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

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

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

Заголовок

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

Структура

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

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

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

Категории

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

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

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

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

  • Шаблоны состояния статьи, которые относятся ко всей статье целиком, должны быть помещены сразу после категорий (или межъязыковых ссылок, если они есть), перед введением (или блоком ссылок по теме, если он есть)
  • Шаблоны состояния статьи, которые относятся к определённой части статьи, должны быть размещены как можно ближе к этой части, но без разрыва абзацев, блоков кода или других имеющихся в статье шаблонов.
  • Всегда сопровождайте шаблон состояния несколькими поясняющими словами в предназначенном для этого поле (на страницах всех шаблонов есть примеры) и, при необходимости, создавайте обсуждение на странице обсуждений.

Блок ссылок по теме

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

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

  • Описывает предмет статьи.
    Вместо перефразирования или написания вашего собственного (возможно, предвзятого) описания программы или компонента, вы можете использовать описание, предоставленное самим автором. Обычно его можно найти на домашней странице проекта, если она существует. В качестве примера посмотрите на статью MediaTomb.
  • Располагается непосредственно перед первым разделом статьи.
  • Не имеет собственного раздела, текст идет сразу после заголовка статьи. Не создавайте разделов с названиями == Предисловие == или == Введение ==. Оглавление будет создано автоматически между предисловием и первым разделом, когда в статье будет достаточное количество разделов.
  • Для получения дополнительной информации смотрите статью Help:Writing article introductions.

Стандартные разделы

Раздел "Установка"
  • Используйте стандартный заголовок Установка и добавляйте этот раздел в начале статьи.
Раздел "Известные проблемы"
  • Разделы Известные проблемы используются для описания известных багов или проблем, которые еще не решены (в отличие от разделов "Решение проблем")
  • Используйте стандартный заголовок Известные проблемы и добавляйте этот раздел ближе к началу статьи.
  • Если для известной проблемы существует отчет об ошибке, крайне желательно предоставить на него ссылку. Если такой отчет еще не создан, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен.
  • По возможности старайтесь не упоминать даты и номера версий (например, "по состоянию на октябрь 2014 г. ядро Linux версии 3.17 не имеет поддержки устройства XYZ"). Вместо этого, опять же, рекомендуется предоставить ссылку на соответствующую информацию, например, отчет об ошибке.
Раздел "Советы и рекомендации"
  • Разделы Советы и рекомендации содержат дополнительные советы и примеры использования программного обеспечения.
  • Используйте только стандартный заголовок Советы и рекомендации.
  • Различные советы и рекомендации должны быть разбиты на подразделы.
Раздел "Решение проблем"
  • Разделы Решение проблем используются для ответов на часто задаваемые вопросы относительно программного обеспечения, а также для описания методов решения часто встречающихся проблем (похоже на #Раздел "Известные проблемы").
  • Используйте только стандартный заголовок Решение проблем.
  • Вы также можете сообщить о временных способах решения проблем для известных багов, но в этом случае крайне желательно дать ссылку на отчет об ошибке. Если отчета еще не существует, следует создать его самостоятельно, увеличив шанс того, что баг будет исправлен.
    По возможности старайтесь не упоминать даты и номера версий. Как для читателей, так и для редакторов есть большие преимущества в предоставлении ссылок на источники и, в частности, отчеты об ошибках:
    • Для читателей: статья не станет конечной точкой; пройдя по ссылке, читатели смогут найти больше информации, которую могли бы пропустить при самостоятельном поиске.
    • Для редакторов: благодаря этому легче проверять актуальность приведенной информации, просто посмотрев, исправлена ошибка или нет, и своевременно выполнять очистку статьи от нее. Может случиться и так, что читатель сам обнаружит изменение и вернется к статье, чтобы ее отредактировать.
Раздел "Смотрите также"
  • Разделы Смотрите также содержат список ссылок на руководства и источники дополнительной информации.
  • В этом разделе должен содержаться только маркированный список, в котором каждая ссылка начинается с символа *
  • Используйте только стандартный заголовок Смотрите также. Необходимо избегать использования похожих заголовков, таких как Ссылки, Внешние ссылки, См. также и т. п.

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

  • Заголовки разделов должны начинаться со второго (==) уровня, поскольку первый уровень зарезервирован для заголовков статей.
  • Не пропускайте уровни при создании подразделов, т. е., например, раздел уровня 2 может содержать только подразделы уровня 3.
  • В заголовках разделов должен использоваться режим набора предложений с большой буквы: Мой новый заголовок, а не Мой Новый Заголовок.
  • Не используйте ссылки в заголовках, поскольку они разрушают согласованность стиля и не выделяются достаточно хорошо. Обычно ничто не мешает указать ссылку в самом тексте раздела, а в противном случае вы всегда можете использовать простое предложение вида:
Для получения дополнительной информации смотрите статью Некая статья
По той же причине не используйте в заголовках HTML и вики-разметку, в том числе шаблоны форматирования кода. Смотрите также статью Help:Style/Formatting and punctuation

Форматирование

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

  • Используйте шаблон {{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) предваряйте каждую команду правильным символом приглашения: $ для команд, выполняемых от имени обычного пользователя, и # для команд, выполняемых от имени суперпользователя
    Примечание: Символ # также нередко используется в текстовых файлах как символ комментария, так что старайтесь избегать неоднозначности толкования, например, написав о необходимости выполнить команду или отредактировать файл
    • Предложение, предваряющее блок с кодом, всегда должно оканчиваться двоеточием (:)
    • За исключением случаев, в которых это действительно необходимо, используйте: 
      # команда
      вместо: 
      $ sudo команда
    • Не используйте вместе символ приглашения от имени суперпользователя и команду sudo, как в этом примере: 
      # sudo команда
      Единственное исключение — использование sudo с флагом -u: в этом случае символ приглашения может быть таким же, как и в других строках, либо используемым по умолчанию $
    • Не добавляйте комментарии в блоки с кодом, например, так: 
      # pacman -S foo #Установка пакета foo
    • Старайтесь не использовать чрезмерно длинные строки с командами, есть множество способов их разбиения
  • Не предполагайте, что на машине пользователя есть sudo и подобные ему утилиты (gksu, kdesu и т.д.)

Клавиши и их сочетания

  • Стандартным способом обозначения в статьях клавиш клавиатуры является использование шаблона 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
    • Up (а не ↑ или Up Arrow) – аналогично для остальных стрелок
    • PageUp
    • PageDown
    • Fn (not FN or fn) – клавиша Fn есть на многих ноутбуках

Блоки "Примечание", "Важно" и "Совет"

  • Блок «Примечание» (шаблон Note (Русский)) используется для информации, которая так или иначе расходится с тем, что пользователь ожидает в какой-то части статьи. В него также помещается информация, дающая более полные знания о чем-либо конкретном, но не относящаяся напрямую к рассматриваемой теме. Другой пример использования — необходимость временно указать на что-либо, например, на изменившееся имя пакета.
Этот блок также может использоваться для выделения важной информации, которую сложно заметить при чтении
  • Блок «Важно» (шаблон Warning (Русский)) следует использовать, если описываемые действия могут привести к серьезным последствиям, например, к повреждению системы или необратимым простыми способами изменениям. Этот блок в целом указывает как на плохие варианты развития событий, так и на условия, способные привести к этому или помогающие этого избежать.
Не злоупотребляйте блоками «Важно». Если вы не уверены, что выбрать, используйте блок «Примечание».
  • Блок «Совет» (шаблон Tip (Русский)) указывает на действия, которые могут быть полезны или принесут пользу кому-либо, хотя и не нужны для завершения операции, и которые можно благополучно проигнорировать
  • Если необходимо использовать два или более блока Обратите внимание, Важно или Совет, идущих друг за другом в одном месте статьи, лучше сгруппировать их содержимое в список внутри одного шаблона. Исключением является ситуация, в которой содержимое блоков слишком отличается по смыслу для группировки. Пример:
Совет:
  • Пример совета №1
  • Пример совета №2

Таблицы

Смотрите описание синтаксиса в статье MediaWiki:Справка:Таблицы.

  • Таблицы обычно должны иметь класс wikitable.
  • Таблицы сравнения также должны иметь дополнительный класс sortable.
  • Используйте заголовки таблиц и шаблоны ячеек таблиц по необходимости.
  • Заголовки таблиц должны использовать режим набора предложений с большой буквы.
  • В подписях к таблицам следует использовать списки определений и размещать их перед таблицами.

Инструкции

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

  • Не предполагайте использование конкретного редактора (nano, vim, emacs и т. п.), когда пишете инструкции по редактированию файлов, кроме тех случаев, когда это необходимо.
  • Старайтесь не использовать команды неявного редактирования файлов. Например, вместо $ echo -e "clear\nreset" >> ~/.bash_logout напишите:
Добавьте следующие строки в файл ~/.bash_logout:
clear
reset
Исключение — команды, которые генерируют сложный, специфичный для каждой системы вывод, например genfstab -U /mnt >> /mnt/etc/fstab.
При этом вы можете добавить ссылку на раздел Help:Чтение#Добавить, создать, редактировать, если считаете, что это будет полезно.

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

Официальные пакеты
  • Пожалуйста, избегайте использования примеров команд pacman для установки официальных пакетов. Это необходимо для простоты (каждый пользователь Arch должен знать статью pacman), а также во избежание ошибок вида pacman -Sy пакет или возможных (но никогда не заканчивающихся) споров о выборе между pacman -S пакет и pacman -Syu пакет. По другим причинам вы не должны советовать использование фронтендов или оберток для pacman.
Вместо всего этого используйте простые шаблонные фразы такого вида:
Установите пакет foobar.
Или, если, например, название приложения отличается от имени пакета:
МоеПриложение можно установить при помощи пакета my-app-pkg.
Инструкции по установке списка пакетов могут выглядеть так:
Установите пакеты foobar1, foobar2 и foobar3.
Для инструкций по установке группы пакетов вы можете использовать такую фразу:
Установите группу пакетов foobar.
Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
  • Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием шаблона Template:Pkg. Пример: {{Pkg|foobar}}.
Если речь идет о целой группе пакетов, вместо этого следует использовать шаблон Template:Grp. Пример: {{Grp|foobar}}.
  • В приведенных выше примерах используется ссылка установите (в викитексте это [[установите]]): рекомендуется использовать ее по крайней мере при первом предложении установки, особенно в статьях, которые ориентированы на новичков в Arch.
  • Если пакет находится в одном из репозиториев core, extra или community, не делайте каких-либо конкретных ссылок на них: это ничего не дает и только добавляет работы, когда пакет переносится в другой репозиторий. Однако, если пакет расположен в официальном репозитории, который выключен по умолчанию (multilib, testing и т. д.), его упоминание необходимо, например, подобным образом:
Установите пакет foobar из официального репозитория multilib.
Пакеты из AUR
  • Пожалуйста, избегайте использования примеров установки пакетов из AUR, как с использованием официального способа, так и с помощью инструментов AUR: каждый пользователь, устанавливающий неофициальные пакеты, должен прочесть статью Пользовательский репозиторий Arch и знать о всех возможных последствиях для его системы. Вместо этого используйте простые высказывания такого вида:
Установите пакет foobarAUR.
Вы в праве перефразировать это предложение для большего соответствия вашей статье, cмотрите дополнительные примеры в разделе #Официальные пакеты.
  • Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием шаблона Template:AUR. Пример: {{AUR|foobar}}
Неофициальные репозитории
  • Если вы предлагаете использовать неофициальный репозиторий для установки заранее собранного пакета, не предоставляйте инструкций по включению этого репозитория, но убедитесь, что он включен в список Unofficial user repositories и просто дайте на него ссылку. При этом, как и в случае с официальными пакетами, не добавляйте примеров команд pacman. Например:
Установите пакет foobar из репозитория пример.
Если пакет также доступен в AUR:
Установите пакет foobarAUR, также доступный в репозитории example
Если пакет при этом имеет разные имена:
Установите пакет aurpkgAUR, также доступный в репозитории example под именем builtpackage.
Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
  • Ссылка на статью Unofficial user repositories является обязательной и должна указывать на раздел, соответствующий конкретному репозиторию. Пример: [[Unofficial user repositories#example|example]].

Управление юнитами systemd

  • Не приводите примеров того, как включить, запустить или осуществить любую другую базовую операцию с юнитами systemd при помощи systemctl. Вместо этого используйте простые предложения, содержащие список затрагиваемых юнитов с указанием возможных зависимостей или конфликтов с другими юнитами, а также описание необходимых действий. Например:
Чтобы GDM запускался во время загрузки системы, включите службу gdm.service.
Или же, если, например, юнит является шаблоном, которому требуется указать аргумент:
Чтобы на беспроводном интерфейсе работало автоматическое переключение между профилями netctl, включите экземпляр службы netctl-auto@.service, добавив имя интерфейса, например, netctl-auto@wlan0.service.
Вы в праве перефразировать эти предложения для большего соответствия вашей статье.

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

  • Не предполагайте использование конкретной оболочки (например, Bash), кроме тех случаев, когда это действительно необходимо. При написании или редактировании статей старайтесь по возможности не использовать команды, специфичные для какой-то одной оболочки.

Метафора гипертекста

Информацию о синтаксисе смотрите в статье Help:Редактирование#Ссылки.

  • Старайтесь вставлять в ваши статьи как можно больше внутренних ссылок, выделяя различные ключевые слова в тексте.
  • Однако, приводите ссылки на новые статьи только после их создания: старайтесь не создавать ссылки на несуществующие страницы. Если вы встретили битую ссылку, попробуйте исправить её. Неработоспособные внешние ссылки отмечаются шаблоном Dead link (Русский).
  • Старайтесь избегать использования скрытых ссылок там, где это возможно. Более предпочтительным является использование выражений вида "Для получения дополнительной информации смотрите статью systemd (Русский)" вместо "Для получения дополнительной информации загляните сюда".

Ссылки можно использовать двумя способами:

  • Как ссылка на тему, когда ссылка является термином, частью текущего текста и подчиняется обычным правилам грамматики: при необходимости пропишите произвольный текст для ссылки; внутренние и интервики-ссылки должны указывать на перенаправление, если они доступны.
  • Как ссылка на страницу или раздел: по возможности не задавайте ссылке произвольный текст и помните про строчные заголовки там, где они используются. Если ссылка ведёт на другой раздел этой же статьи, не прячьте символ # способом наподобие [[#Метафора гипертекста|Метафора гипертекста]] — это лишь увеличивает количество викитекста и, кроме того, такой символ однозначно дает понять, что ссылка указывает на другой раздел этой статьи, а не на другую статью.

Примеры:

Ссылка на тему Ссылка на страницу/раздел
Чтобы ускорить аутентификацию, используйте SSH-агент Следуйте инструкциям в статье Ключи SSH#SSH agents для ускорения аутентификации
Субпиксельное отображение поддерживается большинством мониторов Включите субпиксельное отображение, как описано в статье Настройка шрифтов#Субпиксельное отображение
Имейте в виду, что клавиши мыши отключены по умолчанию Смотрите Wikipedia:Mouse keys для более подробной информации
У нас есть правила оформления ссылок Раздел #Метафора гипертекста описывает правила оформления ссылок
  • Перед тем, как описывать в статье конкретные действия или какие-то подробности, всегда проверяйте, существует ли другая статья, в которой содержится подобный текст. Если она существует, просто сошлитесь на нее вместо того, чтобы дублировать содержимое. Также:
    • Для технических терминов, не освещенных в статьях ArchWiki, давайте соответствующие ссылки на страницы Википедии.
    • Если в upstream документация по предмету статьи хорошо написана и поддерживается в актуальном состоянии, желательно привести лишь информацию, специфичную для Arch, при этом создав ссылку на официальную документацию как на основной источник.
Пример: "Во время загрузки системы параметры ядра используются для совершения системных вызовов; смотрите документацию ядра Linux, чтобы увидеть полный список"
В общем и целом поддерживайте согласованность с Help:Чтение#Организация.
  • За исключением редких случаев вы не должны создавать "тупиковые страницы" (страницы, которые не ссылаются на другие страницы) или "осиротевшие страницы" (страницы, на которыю не ссылаются другие страницы).
  • Не используйте в тексте статей интервики-ссылки для создания ссылок на локализованные страницы того же языка, что и редактируемая страница, поскольку они не будут отображаться на страницах Ссылки сюда. Например, использование ссылки вида [[:ru:Main page]] в русскоязычной статье недопустимо, тогда как [[Main page (Русский)]] — корректно.
При этом использование таких ссылок в тексте между страницами разных языков приемлемо, поскольку это облегчит перенос переводов на выделенные локализованные вики-сайты ArchWiki в случае их появления.
Наконец, обратите внимание на отличие этого вида ссылок от межъязыковых, которые не начинаются с двоеточия.
  • Старайтесь использовать полный интервики-префикс "Wikipedia:" вместо краткого "w:".

Страницы справочных руководств (man)

Оформление кода

  • При добавлении команд или скриптов используйте единый стиль написания кода во всей статье, по возможности соотносящийся с другими страницами, особенно связанными с вашей. Придерживайтесь официальных и общих рекомендаций по оформлению кода для вашего языка.
  • Избегайте использования устаревших функций языка программирования/скриптов: например, используйте синтаксис $() для подстановки команды оболочки вместо обратных кавычек (``).
  • Скрипты в статьях должны размещаться с единственной целью: сделать минимально необходимые действия для выполнения конкретной задачи максимально понятным способом. Они не должны иметь множество способов применения и возможности для расширения, вместо обычных переменных предпочтительным является использование псевдо-переменных. Не добавляйте излишнюю функциональность, например, парсинг аргументов или форматирование вывода.
  • Скрипты должны добавляться преимущественно с целью обучения, когда сложно четко и ясно объяснить необходимые действия в тексте статьи. Они могут быть полезны, например, чтобы показать, как обычно используется команда, или как связанные или независимые команды должны работать вместе.
  • Если в контексте статьи скрипт имеет значение, но не соответствует критериям, приведенным выше, можно добавить ссылку на сторонний ресурс, например, gist.
  • При указании имени или пути к каталогу в конце необходимо поставить слэш (/) или добавить однозначное указание на то, что это "каталог" или "папка", например:
  • "Удостоверьтесь, что каталог /sys/firmware/efi был создан", а не "Удостоверьтесь, что /sys/firmware/efi был создан".
  • "Положите файл .conf в /etc/modules-load.d/", а не "Положите файл .conf в /etc/modules-load.d".
  • Аргументы команд, в которых содержатся знаки пробела, необходимо заключать в двойные кавычки: например, cd "foo bar" вместо cd foo\ bar.

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

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

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

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

Правильное написание

  • Избегайте избыточных сокращений: например, вместо "см." пишите "смотрите". В англоязычном тексте вместо "don't", "isn't", "you've"; пишите: "do not", "is not", и "you have" и т. д.
  • Избегайте ненужных укорочений слов. Например, вместо "репа", "дистр" и "конфиг" пишите "репозиторий", "дистрибутив" и "конфигурация".
    Таким же образом предпочтительным является использование длинных форм редких опций команд вместо их односимвольных аналогов. Смотрите также Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties....
  • Названия проектов, приложений, исполняемых файлов и т.п. необходимо писать так, как это пишется в официальной документации; особенное внимание следует обращать на использование прописных и строчных букв. В том числе это относится к случаям, когда в документации они пишутся как обычное существительное, например, с прописной буквы в начале предложения и со строчной в других местах. Если единого стиля в официальной документации нет, придерживайтесь стилистики ArchWiki. Если название в ArchWiki еще не появлялось или до сих пор имеет разное написание, выберите тот вариант, который вам по душе и используйте его во всей статье, а можно даже обновить другие страницы, приведя необходимое название на них к вашему варианту. В качестве примера можно взять Git: вы можете писать его с прописной буквы ("Git"), когда имеется в виду проект или программное обеспечение в целом, но использовать строчные буквы и курсив ("git") при упоминании скомпилированной программы. Когда разное написание может привести к неоднозначости толкования, используйте страницу обсуждений для выработки правильного варианта. Смотрите также Help:Style/Formatting and punctuation#Executable/application names

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

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

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

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

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

  • Приветствуется создание перенаправлений для акронимов или различных грамматических вариантов написания существующих названий статей, а также для терминов или тем, обсуждаемых в отдельных разделах более общих статей. Примеры: ALSA, демон, AIGLX. Перенаправления упрощают викитекст, заменяя ссылки с метками. Сравните предыдущие примеры с этими: [[Advanced Linux Sound Architecture|ALSA]], [[daemons (Русский)|демон]], [[Xorg#Composite|AIGLX]].
  • Страницы-перенаправления должны содержать лишь директиву перенаправления и ничего больше. Допустимые исключения:
  • Создавайте перенаправления только на внутренние статьи: не используйте интервики-ссылки в перенаправлениях.
Перенаправления с использованием межъязыковых ссылок разрешаются лишь в исключительных случаях, в соответствии со статьей Help:i18n (Русский) и лишь с разрешения команды мэйнтейнеров ArchWiki.

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

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

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

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

Смотрите раздел ArchWiki:Внесение вклада#Три основных правила.

HTML-теги

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