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

From ArchWiki
Jump to: navigation, search
Состояние перевода: На этой странице представлен перевод статьи Help:Style. Дата последней синхронизации: 28 февраля 2016. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

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

Contents

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

Заголовок

  • Регистр букв в заголовках должен соответствовать режиму набора предложений с большой буквы: например, написание "Заголовок новой статьи" является правильным, а "Заголовок Новой Статьи" — нет. При этом, если в заголовке присутствуют общие слова, которые являются частью имени собственного или аббревиатурой с написанием в верхнем регистре, они должны писаться прописными буквами: например, "Advanced Linux Sound Architecture", а не "Advanced Linux sound architecture".
Пространства имен не считаются частью заголовков, поэтому написание "ArchWiki:Новая статья" является правильным, а "ArchWiki:новая статья" — нет. Точно так же имена подстраниц должны начинаться с прописной буквы: например, написание "Моя страница/Моя подстраница" является правильным, а "Моя страница/моя подстраница" — нет.
  • По умолчанию, подлежащее в названии должно быть в единственном числе. Однако, следует использовать множественное число, если оно является исчисляемым и подразумевает под собой группу/класс сущностей.
  • Если предмет статьи широко известен как под своим полным именем, так и в аббревиатуре, предпочтительным является использование в названии статьи полного имени. Не включайте и полное имя, и аббревиатуру (например, в скобках) в название статьи: используйте перенаправление со страницы с аббревиатурой на страницу с полным названием.
  • Для получения дополнительной информации смотрите статью 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 (Русский) и Wikipedia:ru:Википедия:Интервики#Ссылки на статьи в иноязычных разделах по той же теме.

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

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

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

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

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

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

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

  • Заголовки разделов должны начинаться со второго (==) уровня, поскольку первый уровень зарезервирован для заголовков статей
  • Не пропускайте уровни при создании подразделов, т. е. раздел уровня 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 и т.д.)

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

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

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

  • Стандартным способом обозначения в статьях клавиш клавиатуры является использование шаблона 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.
Вместо всего этого используйте простые шаблонные фразы такого вида:
Установите пакет foobar.
Или, если, например, название приложения отличается от имени пакета:
МоеПриложение можно установить при помощи пакета my-app-pkg.
Инструкции по установке списка пакетов могут выглядеть так:
Установите пакеты foobar1, foobar2 и foobar3.
Для инструкций по установке группы пакетов вы можете использовать такую фразу:
Установите группу пакетов foobar.
Вы в праве перефразировать эти предложения для большего соответствия вашей статье.
  • Ссылки на соответствующие пакеты являются обязательными и должны создаваться с использованием шаблона Template:Pkg. Пример: {{Pkg|foobar}}.
Если речь идет о целой группе пакетов, вместо этого следует использовать шаблон Template:Grp. Пример: {{Grp|foobar}}.
  • В приведенных выше примерах используется ссылка установите (в викитексте это [[установите]]): рекомендуется использовать ее по крайней мере при первом предложении установки, особенно в статьях, которые ориентированы на новичков в Arch.
  • Примеры команд pacman, тем не менее, принято и даже рекомендуется использовать в статье Руководство для новичков.
  • Если пакет находится в одном из репозиториев core, extra или community, не делайте каких-либо конкретных ссылок на них: это ничего не дает и только добавляет работы, когда пакет переносится в другой репозиторий. Однако, если пакет расположен в официальном репозитории, который выключен по умолчанию (multilib, testing и т. д.), его упоминание необходимо, например, подобным образом:
Установите пакет foobar из официального репозитория multilib.

Пакеты из AUR

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

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

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

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

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

Блоки Обратите внимание, Важно и Совет

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

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

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

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

  • Старайтесь вставлять в ваши статьи как можно больше внутренних ссылок, выделяя различные ключевые слова в тексте.
  • Не создавайте ссылки на несуществующие страницы, даже если вы уверены, что такие страницы скоро будут созданы.
  • Для технических терминов, таких как системный вызов, не освещенных в статьях ArchWiki, давайте соответствующие ссылки на страницы Википедии.
  • При создании ссылок на другие статьи ArchWiki не используйте полные URL-адреса. Всегда оформляйте их как внутренние ссылки: [[Статья Wiki]]. Это просто удобно, а также позволит вики-движку отслеживать внешние ссылки и, соответственно, облегчит контроль над статьями.
Для получения более полной информации по использованию синтаксиса интервики-ссылок смотрите раздел Help:Редактирование#Ссылки.
  • Старайтесь избегать использования скрытых ссылок там, где это возможно. Более предпочтительным является использование выражений вида "Для получения дополнительной информации смотрите статью systemd (Русский)" вместо "Для получения дополнительной информации загляните сюда".
  • За исключением редких случаев вы не должны создавать "тупиковые страницы" (страницы, которые не ссылаются на другие страницы) или "осиротевшие страницы" (страницы, на которыю не ссылаются другие страницы).
  • Перед тем, как описывать в статье конкретные действия или какие-то подробности, всегда проверяйте, существует ли другая статья, в которой содержится подобный текст. Если она существует, просто сошлитесь на нее вместо того, чтобы дублировать содержимое.
  • Если в upstream документация по предмету статьи хорошо написана и поддерживается в актуальном состоянии, желательно привести лишь информацию, специфичную для 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" и т. д.
  • Избегайте ненужных укорочений слов. Например, вместо "репа", "дистр" и "конфиг" пишите "репозиторий", "дистрибутив" и "конфигурация".
Таким же образом предпочтительным является использование длинных форм редких опций команд вместо их односимвольных аналогов
  • Не пренебрегайте терминами, которые являются важными, чтобы передавать в предложениях точный и однозначный смысл. Например, всегда добавляйте слово "репозиторий", когда называете имя репозитория
  • Не используйте неопределенных указаний на время, таких как "на данный момент", "на момент написания статьи" или "скоро". Заменяйте их на конкретные выражения вроде "по состоянию на май 2015 г." и тому подобные
  • Пишите объективно: не включайте в статьи персональные комментарии, используйте для этого страницы обсуждений. Не пишите статьи от первого лица

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

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

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

  • Страницы-перенаправления должны содержать лишь директиву перенаправления и ничего больше. Допустимые исключения:
  • Создавайте перенаправления только на внутренние статьи: не используйте интервики-ссылки в перенаправлениях.
Перенаправления с использованием межъязыковых ссылок разрешаются лишь в исключительных случаях, в соответствии со статьей Help:I18n (Русский) и лишь с разрешения команды мэйнтейнеров ArchWiki

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

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

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

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

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

HTML-теги

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