Help:Style (Español)

From ArchWiki
Estado de la traducción: esta traducción de Help:Style fue revisada el 2019-09-15. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Prólogo o introducción

Artículos relacionados

Las siguientes normas de estilo están orientadas a conseguir artículos ordenados, organizados y coherentes visualmente. Siga las presentes directrices tan de cerca como le sea posible al editar artículos de ArchWiki.

Páginas de artículos

Título

  • Los títulos deben utilizar mayúsculas y minúsculas, por ejemplo, «Title for new page» es correcto, mientra que «Title for New Page» no lo es. Advierta que las palabras comunes que forman parte de un nombre propio o un acrónimo en mayúsculas deben ser capitalizados, por ejemplo «Advanced Linux Sound Architecture», no «Advanced Linux sound architecture».
    Los espacios de nombres no son considerados parte de los títulos, por lo que «ArchWiki:Example article» es correcto, minetras que «ArchWiki:example article» no lo es. Los nombres de las subpáginas deben comenzar con una letra mayúscula, por lo que «My page/My subpage» es correcto, mientras que «My page/my subpage» no lo es.
  • Por defecto, el nombre del tema en los títulos debe estar en forma singular; se utilzará la forma plural si representa un grupo o clase y es un sustantivo o actúa como tal.
  • Si el tema del artículo es comúnmente conocido, tanto con el nombre completo como por las siglas, se preferirá usar el nombre completo en el título del artículo. No incluya el nombre completo junto con las siglas (por ejemplo, en paréntesis) en el título, sino más bien utilice un enlace redirect para el acrónimo que apunte a la página titulada con el nombre completo.
  • Los títulos de páginas traducidas deben seguir el artículo Help:i18n (Español)#Títulos de los artículos.
  • Véase también Help:Article naming guidelines para obtener más información.

Estructura

  • Los elementos de un artículo y su prelación se muestran como sigue:
  1. Magic words (opcional)
  2. Categorías
  3. Enlaces interlingüísticos (opcional)
  4. Plantillas sobre el estado del artículo (opcional)
  5. Artículos relacionados (opcional)
  6. Prólogo o introducción
  7. Tabla de contenidos (generada automáticamente)
  8. Secciones específicas del artículo

Magic words

  • Los modificadores de comportamiento  — y en general, todas las palabras mágicas que modifican la visualización o comportamiento de un artículo, pero que no añaden contenido por sí mismas — , deben ir en la parte superior de los artículos.
    Esta regla se aplica en particular a la variable {{DISPLAYTITLE:title}} y a la plantilla Template:Lowercase title, que hace uso de la primera.

Categorías

  • Cada artículo debe clasificarse en, al menos, una categoría existente.
  • Un artículo puede pertenecer a más de una categoría, siempre que una no sea ascendente de las otras.
  • Las categorías deben ser colocadas en la parte superior de cada artículo.
    Nota: Esto es diferente de otros proyectos de MediaWiki, como Wikipedia, que incluyen las categorías en la parte inferior
  • No debe haber líneas en blanco entre las categorías y la primera línea del texto (o enlaces interlingüísticos, si están presentes), ya que ésto introduce un espacio adicional en la parte superior del artículo.
  • Consulte el artículo Help:Category (Español) para obtener más información.

Enlaces interlingüísticos

  • Si el artículo tiene traducciones en la wiki local o en una wiki de Arch Linux externa, debe incluir el enlace interlingüístico inmediatamente debajo de categorías y antes de la primera línea del texto.
    Advierta que los enlaces interlingüísticos se muestran realmente en la columna de la parte izquierda de la página.
  • No debe haber líneas en blanco entre los enlaces interlingüísticos y la primera línea del texto, ya que ésto introduce un espacio adicional en la parte superior del artículo.
  • Al agregar o editar un enlace interlingüístico hay que tener cuidado de repetir esta acción en todas las traducciones de los correspondientes artículos en otras lenguas ya existentes.
  • No añada más de un enlace interlingüístico para cada idioma a un artículo.
  • No añada un enlace interlingüístico para el mismo idioma del artículo.
  • Los enlaces interlingüísticos deben estar ordenados alfabéticamente por la etiqueta del idioma, no por el nombre local, así que, por ejemplo [[fi:Título]] es anterior a [[fr:Título]], aunque «Suomi» (Finlandia en finlandés) es posterior a «Français».
  • Véanse los artículos Help:i18n (Español) y Wikipedia::es:Ayuda:Enlace interlingüístico para obtener más información

Plantillas del estado del artículo

  • Las plantillas del estado del artículo que se refieren a todo el artículo debe ser incluido justo debajo de las categorías (o de los enlaces interlingüísticos, si están presentes) y encima del resumen del artículo.
  • Las platillas del estado del artículo también se pueden utilizar en el interior de las secciones del artículo, cuando corresponda.
  • Las platillas del estado del artículo siempre deben estar acompañadas de alguna explicación al respecto en la página de discusión.

Recuadro sobre artículos relacionados

  • Proporciona una simple lista de artículos internos relacionados con el tema.
  • Incluido opcionalmente justo debajo de las categorías (o enlaces interlingüísticos o plantillas estado del artículo, si están presentes).
  • El recuador únicamente puede estar compuesto por las plantillas Template:Related articles start —Template:Related articles start (Español) si se utiliza en un artículo traducido—, Template:Related y Template:Related articles end. Véanse también las directrices en dichas páginas.
  • Para artículos que no están en inglés puede hacerse uso de la plantilla Template:Related2 para traducir el texto del enlace.
  • Se utilizará también la sección #Sección «See also» para proporcionar una lista más completa y detallada, que incluye también las descripciones y enlaces interwiki o enlaces externos.

Prólogo o introducción

  • Sirve para explicar el tema o el argumento del artículo.
    En lugar de parafrasear o escribir su propia (tal vez demasiado subjetiva) descripción de un software determinado, puede utilizar la descripción del autor original, que se puede encontrar en su página principal o en el apartado about («acerca de») del sitio web oficial del proyecto, si lo hubiere. Un ejemplo es MediaTomb.
  • Se coloca justo encima de la primera sección del artículo.
  • No cree explícitamente una sección ==Prólogo== o ==Introducción==: el párrafo que escriba, a modo de prólogo o introducción, aparecerá por encima del título de la primera sección. Una tabla de contenidos se mostrará automáticamente entre el prólogo y la primera sección cuando haya encabezados suficientes en el artículo para generarla (al menos, cuatro encabezados o títulos).
  • Consulte Help:Writing article introductions para obtener más información.

Secciones estándar

Sección «Installation»
Sección «Known issues»
  • Contiene fallos conocidos o problemas de uso para los que no existe todavía una solución (compárese con #Sección «Troubleshooting»).
  • El título estándar es Known issues («Problemas conocidos»).
  • Si un informe de error existe para el problema conocido, es muy conveniente que se proporcione un enlace al mismo, de lo contrario, si no existe, debe informarlo por sí mismo, lo que aumentará las posibilidades de que el error se corrija.
  • Evite mencionar fechas o números de versión (por ejemplo, «el kernel de Linux kernel 3.17 no es compatible aún con el dispositivo XYZ a fecha de octubre de 2014») siempre que sea posible. De nuevo, es preferible vincular referencias, como informes de errores, para obtener información de seguimiento.
Sección «Tips and tricks»
  • Contienen sugerencias avanzadas o ejemplos sobre el uso del software.
  • El título estándar es Tips and tricks («Consejos y trucos»).
  • Los diversos consejos y trucos deberían organizarse en subsecciones.
Sección «Troubleshooting»
  • Contiene las preguntas más frecuentes sobre el software o las soluciones a problemas más comunes (compárese con #Sección «Known issues»).
  • El título estándar es Troubleshooting («Solución de problemas»); Errores ortográficos comunes que deben evitarse son Trouble shooting, Trouble-shooting, y TroubleShooting.
  • También puede reportar soluciones temporales para los errores conocidos, pero en este caso, es muy conveniente que proporcione un enlace al informe de fallo, y, en caso de que no se haya informado aún, debe intentar crearlo por sí mismo, lo que aumentará las posibilidades de que el error sea corregido correctamente. Abstenerse de mencionar fechas o números de versión siempre que sea posible. Enlazar un informe de externo reporta grandes beneficios para los lectores y editores:
    • Para los lectores, la Wiki no se convierta en un elemento estático: se puede encontrar más información cerca de la fuente que de otro modo hubieran pasado por alto por los esfuerzos que implica su búsqueda.
    • Para los editores de la Wiki, hace el mantenimiento más fácil al reducir el esfuerzo en la investigación al comprobar si el bug reportado sigue siendo un problema o se corrigió, lo que puede llevar incluso a una mayor autonomía si el lector encuentra información nueva y vuelve a editar la wiki.
Sección «See also»
  • Contiene una lista de enlaces a referencias y fuentes de información adicional.
  • Debería ser una lista en la que cada entrada se inicia con *.
  • El título estándar es See also («Véase también»), otros títulos similares como External links («Enlaces externos»), More resources («Más recursos»), etc. deben ser evitados.

Títulos de las secciones

  • Los títulos deben comenzar desde el nivel 2 (==), ya que el nivel 1 se reserva para los títulos de los artículos.
  • Evite saltarse niveles al crear subsecciones, por lo tanto, una subsección de un nivel 2 tendrá un título de nivel 3 y así sucesivamente.
  • Los encabezados de las secciones usan letras mayúsculas como en las oraciones normales: Mi nueva sección, y no Mi Nueva Sección.
  • Evite el uso de enlaces en las títulos, ya que rompen la coherencia de estilo y no destacan lo suficiente. Por lo general, el texto de enlace se puede colocar también en el contenido de la sección, de lo contrario se puede utilizar una frase tan simple como:
See Some related article for more information.
Por la misma razón, evite también el uso de cualquier tipo de etiquetas (html o wiki), incluyendo el #Formato del código.Véase también Help:Style/Formatting and punctuation.

Formato

Formato del código

  • Utilice Template:ic para representar, dentro de un párrafo u oración, líneas de código cortas, nombres de archivos, nombres de órdenes, nombres de variables y otros casos para representar en línea, por ejemplo:
    Ejecutar sh ./hello_world.sh en la consola.
  • Para líneas de código individuales (entrada o salida de línea de órdenes y contenido de archivos) puede representarse en un recuadro adecuado, haciendo simplemente que un carácter vaya precedido de un espacio en blanco. Consulte también Help:Editing#Code. Por ejemplo:
$ sh ./hello_world.sh

Hello World
  • Utilice Template:bc para represnetar varias líneas de código en un recuadro apropiado (entrada de línea de órdenes o código de salida y contenido de archivo), por ejemplo:
#!/bin/sh

# Demo
echo "Hello World"
  • Utilice Template:hc cuando sea necesario representar tanto la entrada como la salida de la línea de órdenes, por ejemplo:
$ sh ./hello_world.sh
Hello World
  • Cuando necesite representar el contenido de un archivo y considere que puede ser difícil para los lectores entender el archivo del que procede el código, también se puede utilizar Template:hc para mostrar el nombre del archivo en el título, por ejemplo:
~/hello_world.sh
#!/bin/sh

# Demo
echo "Hello World"
  • Para bloques de código, tales como un archivo de configuración, considere enfocar al lector hacia las líneas relevantes y meter en el símbolo: ( ...), cualquier contenido relacionado no relevante.
  • Consulte también Help:Template para obtener más información y para resolver los problemas surgidos con algunos caracteres que rompen las plantillas, como = o |.

Texto de línea de órdenes

  • Cuando se utiliza código en línea (Template:ic), no se debe representar ningún símbolo de aviso, pero cualquier nota sobre permisos debe agregarse explícitamente al texto relacionado.
  • Cuando se usa código de bloque (Template:bc o líneas que comienzan con un espacio en blanco), utilice el símbolo # como un indicador de las órdenes son utilizadas con privilegios de root.
    Nota: Dado que el símbolo # también se utiliza para comentar líneas en los archivos de texto, debe procurar evitar ambigüedades, dejando constancia de forma explícita cuándo se está ejecutando una órden o cuándo se está editando un archivo de texto.
    • La frase introduciendo una órden normalmente debe terminar con dos puntos :.
    • Es preferible usar: 
      # orden
      en lugar de escribir: 
      $ sudo orden
    • No utilice el prompt de root y la orden sudo juntos, como en: 
      # sudo orden
      La única excepción es cuando se usa sudo con la opción -u: en este caso, el prompt puede coincidir con otros del mismo bloque de código, o de forma predeterminada con $.
    • No agregue comentarios en el mismo recuadro de la orden, por ejemplo: 
      # pacman -S foo  #Instale el paquete foo
    • Evite escribir líneas de código excesivamente largas: use técnicas de salto de línea cuando sea posible.
  • No presuponga que el usuario utiliza sudo u otras utilidades para obtener los privilegios de root (por ejemplo, gksu, kdesu).

Teclas del teclado

  • La manera estándar para representar las teclas del teclado en los artículos es utilizando plantillas de Template:ic.
  • Las teclas de las letras deben estar representados en minúsculas: a. Para representar las letras mayúsculas, utilice Mayús+a en lugar de Mayús+A o A.
  • La forma correcta de representar combinaciones de teclas es hacer uso del símbolo + para unir las letras, sin espacios adicionales entre ellas, en una sola instancia de la plantilla: Ctrl+c.
    Ctrl + c, Ctrl+c, Ctrl-c no son formatos pertinentes, y se deben evitar.
  • Las siguientes son las formas estándar de representar algunas teclas especiales (en inglés):
    • Shift (no SHIFT)
    • Ctrl (no CTRL o Control)
    • Alt (no ALT)
    • Super (no Windows o Mod)
    • Enter (no ENTER o Return)
    • Esc (no ESC or Escape)
    • Space (no SPACE)
    • Backspace
    • Tab
    • Ins (no INS or Insert)
    • Del (no DEL or Delete)
    • PrintScreen
    • PageUp
    • PageDown
  • Tenga en cuenta que los nombres de las teclas en español son diferentes a las del inglés y deben traducirse en las traducciones:
    • Alt (no ALT)
    • AvPág (en lugar de PgDn)
    • Barra espaciadora (en lugar de Spacebar)
    • Bloq Despl (en lugar de Scroll Lock)
    • Bloq Mayús (en lugar de Caps Lock)
    • Bloq Num (en lugar de Num Lock)
    • Ctrl (no CTRL o Control)
    • Esc (no ESC o Escape)
    • Fin (en lugar de End)
    • Impr Pant (en lugar de Print Screen)
    • Inicio (en lugar de Home)
    • Ins (no INS o Insertar)
    • Intro (en lugar de Enter)
    • Mayús (en lugar de Shift)
    • Pausa (en lugar de Pause)
    • Pet Sis (en lugar de SysReq)
    • RePág (en lugar de PgUp)
    • Retroceso (en lugar de Backspace)
    • Super (no Windows o Mod)
    • Supr (en lugar de Del)
    • Tab

Notas, advertencias y sugerencias

  • Una plantilla Note —Nota para artículos traducidos— debe ser utilizada para proporcionar información que, de alguna manera, se aparta de lo que el usuario esperaría normalmente en un cierto punto del artículo. Esto incluye también la información que profundiza más en algo en particular que de otra manera sería considerado un poco ajeno al artículo. Otro ejemplo es cuando se necesita señalar un anuncio temporal, como por ejemplo un cambio en el nombre de un paquete. Una nota también se puede utilizar para resaltar la información que es importante, pero que pasaría por alto fácilmente por alguien nuevo en el tema.
  • Una plantilla Warning —Advertencia para artículos traducidos— se debe utilizar cuando el procedimiento descrito podría llevar a consecuencias graves, como ser razonablemente difícil de deshacer o que podría dañar el sistema. Las advertencias generales, deben indicar tanto los peores escenarios posibles, así como las condiciones que puedan dar lugar o evitar tales situaciones.
  • Una plantilla Tip —Sugerencia para artículos traducidos— debe indicar un método o procedimiento que podría ser útil y beneficioso para alguien, aunque no sea necesario para completar la operación de que se trate, y, por lo tanto, inócuo para la seguridad.
  • Cuando dos o más notas, advertencias o sugerencias aparecen una tras otra en el mismo punto de un artículo, es preferible agrupar sus textos en una lista dentro de un modelo único, evitando apilar las plantillas, a menos que traten asuntos completamente distintos. Por ejemplo:
Sugerencia:
  • Ejemplo de sugerencia #1.
  • Ejemplo de sugerencia #2.

Tablas

Consulte mw:Help:Tables/es para conocer la sintaxis.

  • Las tablas generalmente deben tener la clase wikitable.
  • Las tablas de comparación deben tener además la clase sortable.
  • Use encabezados de tabla y plantillas de celda de tabla cuando sea apropiado.
  • Los encabezados de tabla deben usar mayúscula la primera letra solo.
  • Las leyendas de las tablas deben usar listas de definición y colocarse antes que las tablas.

Instrucciones

Peticiones de edición de archivos

  • No presuponga el uso de un editor de texto específico (nano, vim, emacs, ...), cuando se solicite la edición de un archivo de texto, excepto cuando sea necesario.
  • No utilice las órdenes implícitas para solicitar la edición de archivos de texto, a menos que sea estrictamente necesario. Por ejemplo, en lugar de $ echo -e "clear\nreset" >> ~/.bash_logout sería mejor escribir:
Añada las siguientes líneas a ~/.bash_logout:
clear
reset
Una excepción común son las órdenes que implican la generación de una salida compleja, específica del sistema, por ejemplo genfstab -U /mnt >> /mnt/etc/fstab.
Donde pueda ser útil, se puede agregar un enlace a Help:Reading#Append, add, create, edit.

Instrucciones para la gestión de los paquetes

Paquetes oficiales
  • Procure evitar el uso de ejemplos de órdenes de pacman para dar instrucciones para la instalación de los paquetes oficiales: ésto se ha establecido así tanto por simplicidad (todos los usuarios de Arch deben preocuparse por conocer el artículo sobre pacman lo mejor posible), como para evitar errores como pacman -Sy paquete o posibles discusiones interminables sobre la elección entre pacman -S paquete y pacman -Syu paquete. Con mayor razón no debe sugerir el uso de interfaces de pacman, frontend o wrapper, para instalar paquetes oficiales.
En su lugar, solo se tiene que utilizar una simple declaración como:
Instale el paquete foobar.
O, si, por ejemplo, el nombre de la aplicación difiere del nombre del paquete:
MyApplication puede ser instalada con el paquete my-app-pkg.
Las instrucciones para la instalación de una lista de paquetes puede aparecer como:
Instale los paquetes paquete1, paquete2 y paquete3.
Si se refiere a un grupo de paquetes, puede usar:
Instale el grupo foobar.
Obviamente, tiene permitida la flexibilidad necesaria para adaptar la redacción a su artículo específico.
  • Los enlaces a los paquetes mencionados son obligatorios y deben ser creados usando Template:Pkg, por ejemplo {{Pkg|foobar}}.
Cuando se hace referencia a grupos de paquetes, se debe utilizar Template:Grp en su lugar, por ejemplo {{Grp|foobar}}.
  • Los ejemplos anteriores también hacen uso de un enlace a install (por ejemplo, [[install]]): se recomienda utilizarlo al menos en la primera aparición de una solicitud de instalación, especialmente en artículos que es más probable que sean visitados por usuarios novatos en Arch.
  • Si el paquete se encuentra alojado en core, extra o community, se evitará hacer referencia al repositorio, facilitando así el mantenimiento, ya que no es raro que un paquete sea trasladado a un repositorio diferente. Sin embargo, si el paquete se encuentra alojado en un repositorio oficial que no está activado por defecto (multilib, testing, etc.), indíquelo, utilizando una redacción como:
Instalar el paquete foobar disponible en el repositorio oficial multilib.
Paquetes de AUR
  • No dé ejemplos de cómo instalar paquetes de AUR, ni con el método oficial ni mencionando herramientas auxiliares de AUR: cada usuario que instala los paquetes no oficiales debería haber leído el artículo Arch User Repository y ser consciente de todas las consecuencias posibles para su sistema.
Utilice, en su lugar, una frase similar a la siguiente:
Instale el paquete foobarAUR.
Aunque, obviamente, está permitida la flexibilidad necesaria para adaptar la redacción al artículo en cuestión; consulte la sección #Paquetes oficiales para conocer ejemplos adicionales.
  • Los enlaces a los paquetes mencionados son obligatorios y deben ser creados usando la plantilla Template:AUR, por ejemplo {{AUR|foobar}}).
Repositorios no oficiales
  • Cuando se sugiere el uso de un repositorio no oficial para la instalación de un paquete precompilado, asegúrese de que tal repositorio está incluido enUnofficial user repositories y luego simplemente enlazar con él. Por ejemplo:
Instale el paqueteAUR disponible en Arch User Repository o en el Repositorio ejemplo.
Si el paquete también está disponible en AUR:
Instale el paquete foobarAUR, también disponible en el repositorio ejemplo.
Si el paquete está disponible en AUR con un nombre diferente:
Instale el paquete aurpkgAUR, también disponible como builtpackage presente en el repositorio ejemplo.
Tiene flexibilidad de adaptar la redacción a su artículo específico.
  • El enlace a Unofficial user repositories es obligatorio y debe apuntar a la sección del repositorio relevante, por ejemplo [[Unofficial user repositories#example|ejemplo]].

Operaciones con unidades de systemd

  • No proporcione ejemplos de cómo activar, iniciar o realizar cualquier operación básica con systemctl en unidades systemd. En su lugar, utilice una frase simple que enumere las unidades involucradas, señalando posibles dependencias o conflictos con otras unidades, y una descripción de las acciones a realizar. Por ejemplo:
Para lanzar GDM al tiempo del arranque, active el servicio gdm.service.
O, si, por ejemplo, la unidad es una plantilla que necesita creación de instancias:
Para activar el intercambio de perfiles de netctl en las interfaces inalámbricas, active una instancia de [email protected] con el nombre de la interfaz, por ejemplo [email protected].
Tiene flexibilidad de adaptar la redacción a su artículo específico.
  • Asegúrese de enlazar a la sección del artículo systemd#Using units, ya sea directamente, ya sea a través de una redirección adecuada, como [[start|iniciar]], [[enable|activar]] o [[stop|detener]].

Intérprete de órdenes

  • No presuponga que el usuario usa una shell en particular (por ejemplo bash), excepto cuando realmente es necesario: trate de ser lo más neutral posible respecto a la shell al escribir o editar artículos.

Metáfora del hipertexto

Consulte Help:Editing (Español)#Enlaces para conocer la sintaxis de los enlaces internos, externos e interwikis.

  • Intente relacionar su artículo con tantos otros como pueda, usando los enlaces como palabras en el texto.
  • Solo enlace a artículos existentes. Si encuentra un enlace roto, intente solucionarlo. Los enlaces externos que parezcan estar rotos deben marcarse con Template:Dead link.
  • Evite enlaces implícitos siempre que sea posible. Por ejemplo, prefiera instrucciones como «Consulte el artículo systemd para obtener más información», en lugar de «Consulte aquí para obtener más información».

Un enlace se puede usar de dos maneras:

  • Como una referencia de tema, donde el enlace es un término, parte del texto que se está escribiendo y sujeto a reglas de gramática regulares: utilice una etiqueta de enlace si es necesario; los enlaces internos/interwiki deben apuntar a redirecciones si están disponibles.
  • Como una referencia de página/sección: no ​​utilice una etiqueta de enlace, y escriba el título también de acuerdo con Template:Lowercase title donde se utiliza; en particular, no oculte el símbolo # a los enlaces de sección de la misma página, por ejemplo [[#Metáfora del hipertexto|Metáfora del hipertexto]].

Vea estos ejemplos:

Referencia a un tema Referencia a un artículo/sección
Utilice un SSH agent para acelerar la autenticación Siga SSH keys#SSH agents para acelerar la autenticación
La representación de subpixel es compatible con la mayoría de los monitores Active la representación de subpíxeles como se describe en Font configuration#Subpixel rendering
Incluya un keyfile en initramfs Las instrucciones se pueden encontrar en dm-crypt/Device encryption#Keyfiles
Tenga en cuenta que los botones del ratón están desactivados por defecto Consulte Wikipedia:Mouse keys para obtener más detalles
Tenemos reglas de estilo para los enlaces La sección #Metáfora del hipertexto tiene reglas de estilo para los enlaces
  • Antes de escribir un procedimiento específico en un artículo o describir algo en particular, verifique siempre si ya hay un artículo que trata esa parte en detalle: en ese caso, enlace ese artículo, en lugar de duplicar su contenido. También:
    • Para los términos técnicos no tratados por un artículo en ArchWiki, enlace a la página relevante de Wikipedia.
    • Si la documentación preliminar para el tema de su artículo está bien escrita y mantenida, prefiera simplemente escribir adaptaciones específicas de Arch y vincularlas a la documentación oficial para obtener información general.
Por ejemplo: «Los parámetros del kernel se utilizan para emitir llamadas al sistema en el arranque: consulte las documentación de «Linux kernel» para obtener una lista completa».
En general, mantenga la coherencia con Help:Reading#Organization.
  • Excepto en casos raros, no debe dejar un artículo como una página sin final (un artículo que no se vincula a ningún otro) o una página huérfana (un artículo que no está vinculado desde ningún otro).
  • No utilice enlaces interwiki para enlaces a páginas traducidas del mismo idioma del artículo que se está editando, porque no se mostrarán en las páginas Special:WhatLinksHere. Por ejemplo, utilizar [[:hu:Main page]] en un artículo húngaro es incorrecto, mientras que [[Main page (Magyar)]] es correcto.
    El uso de este tipo de enlaces entre diferentes idiomas es, en cambio, aceptable, ya que esto facilitaría mover los artículos a una wiki separada en caso de que se cree dicha wiki en el futuro.
    Por último, tenga en cuenta la diferencia de este tipo de enlaces con #Enlaces interlingüísticos, que no tienen los dos puntos al principio.
  • Es preferible el prefijo interwiki «Wikipedia:» antes que el prefijo más corto «w:».

Man pages

Estilo de codificación

  • Al añadir órdenes o scripts, utilice un estilo de codificación consistente en todo el artículo, también haciendo posibles referencias a otros artículos, especialmente si están relacionados. Si está disponible, respete las pautas de estilo de codificación oficiales o más comunes para el idioma.
  • Evite las características desaprobadas del lenguaje de programación/scripting que esté utilizando: por ejemplo, utilice la sintaxis $() para la sustitución de órdenes de shell, en lugar de la sintaxis de acentos graves (``).
  • Los scripts deben escribirse solo para mostrar lo que sea mínimamente necesario para realizar la tarea requerida de la manera más clara posible. No deben diseñarse para dar flexibilidad o expansión:es preferible usar pseudovariables antes que las variables reales. No agregue funcionalidad irrelevante, como el análisis de argumentos o el formato de salida.
  • Los scripts deben añadirse principalmente con fines educativos, cuando la explicación detallada en el texto del artículo no es suficientemente clara y concisa. Pueden ser útiles, por ejemplo, para mostrar cómo se pretende usar una orden compleja, o cómo se pretende que las órdenes relacionadas o interdependientes trabajen juntas.
  • Si se considera que un script agrega valor a un artículo, pero no cumple con los criterios anteriores, puede vincularse externamente, publicándolo si es posible como un gist.
  • Cuando represente el nombre o la ruta de un directorio, termínelo con una barra o agregue explícitamente un anexo como «directorio» o «carpeta», por ejemplo:
  • «Compruebe si se ha creado el directorio /sys/firmware/efi», no «Compruebe si se ha creado /sys/firmware/efi».
  • «Coloque un archivo .conf en /etc/modules-load.d/», no «Coloque un archivo .conf en /etc/modules-load.d».
  • Los argumentos que contienen espacios deben citarse entre comillas dobles, por ejemplo cd "foo bar" en lugar de cd foo\ bar.

Versiones de kernel soportadas

  • No retire cualquier nota o adaptación relativa a las versiones del kernel superiores o iguales a la versión mínima entre el linux-lts en curso y el kernel del último soporte de instalación.

Acciones no pertinentes

  • Por favor, no agregue su firma a los artículos, ni para agradecer o mencionar a los autores de un artículo: ArchWiki es un trabajo comunitario, y la historia de cada artículo es suficiente para reconocer los méritos de los que han contribuido. Sin embargo, es una buena práctica reportar las fuentes utilizadas para escribir un artículo: para este fin se puede utilizar la sección «Véase también».
  • La carga de archivos está deshabilitada para los usuarios normales, y no se le permite incluir imágenes en los artículos existentes. Como alternativa, puede incluir enlaces a imágenes externas o galerías, y si necesita dibujar diagramas simples puede utilizar un editor ASCII como Asciiflow y Template:Text art.

Justificación:

  • Mantenimiento: Arch es rolling release, y las imágenes hacen mucho más difícil la actualización de los artículos.
  • Necesidad: Arch no desarrolla ni mantiene ningún tipo de aplicación con una interfaz gráfica, por lo que no es necesario mostrar captura alguna de pantalla.
  • Moderación: cargar imágenes libres requeriría gastar excesivo tiempo para eliminar las imágenes de gran tamaño o inapropiadas.
  • Accesibilidad: apoyamos a los usuarios con conexiones lentas, navegadores de texto, lectores de pantalla, etc.
  • Eficiencia: las imágenes ocupan mucho ancho de banda del servidor y crean residuos en el espacio del disco.
  • Simplicidad: solo texto sin imágenes hace más simples y más ordenados los artículos.

Ortografía

  • Evite las contracciones: «don't», «isn't», «you've», etc. deberían ser «do not», «is not», y «you have», por ejemplo.
  • Evite abreviaturas innecesarias de las palabras: por ejemplo, en lugar de «repo», «distro» y «config» es preferible «repositorio», «distribución» y «configuración».
    De la misma manera, es preferible usar la forma larga de las opciones de órdenes «poco comunes» en lugar de su contraparte de un solo carácter. Consulte también Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties....
  • Los nombres de los proyectos, las aplicaciones, los ejecutables, etc. deben escribirse, especialmente en cuanto al uso de las mayúsculas y minúsculas, principalmente siguiendo su estilo de documentación oficial. Esto incluye el caso en el que la documentación trata el nombre como un nombre común, es decir, con una primera letra en mayúscula cuando aparece al comienzo de una oración, y en minúsculas en caso contrario. Si la documentación oficial no aplica un estilo consistente, siga el estilo ya utilizado en ArchWiki. Si el nombre no aparece en ArchWiki, o aún tiene una ortografía incoherente, elija un estilo y manténgalo a lo largo del artículo, actualizando también si es posible las otras páginas que mencionen el nombre. Tomemos como ejemplo Git: puede elegir escribir el nombre con la primera letra en mayúscula («Git») cuando habla del proyecto/software en general, y usar todas las letras en minúsculas y cursivas («git») cuando se refiera al programa compilado. Cuando las mayúsculas y minúsculas pueden generar controversia, abra una página de discusión para definir explícitamente un estilo en el artículo. Consulte también Help:Style/Formatting and punctuation#Executable/application names

Registro lingüístico

  • Los artículos deben ser escritos utilizando un lenguaje formal, profesional y conciso. Se debe tener cuidado para eliminar los errores gramaticales y ortográficos a través de revisiones
  • Recuerde que no debe responder solo al cómo, sino también al por qué. La información explicativa siempre debe tener por objetivo la transmisión de conocimientos y no solo dar instrucciones.
  • No omita los términos que son necesarios para dar un significado exacto e inequívoco a una oración. Por ejemplo, siempre agregue la palabra «repositorio» cuando mencione el nombre de un repositorio.
  • No utilice referencias de tiempo genérico como «actualmente», «al momento de escribir» o «pronto»; reemplácelos con expresiones concretas como «a partir de mayo de 2015», etc.
  • Escriba objetivamente: no incluya comentarios personales en los artículos; utilice las páginas de discusión para este propósito. En general, no escriba en primera persona.
  • Al modificar contenido, sea coherente con el estilo utilizado en el resto del artículo. Por ejemplo, si el lector siempre se dirige usando la segunda persona, este estilo debe ser adoptado por el contenido agregado; lo mismo ocurre si la tercera persona o la voz pasiva son claramente dominantes en todo el artículo.
  • Cuando se ofrece una elección entre diferentes opciones (piezas de software, métodos para hacer algo, etc.) no recomiende explícitamente una sobre las otras, sino que describa objetivamente las ventajas y desventajas de cada una, lo que ayudará al lector a tomar la mejor decisión para su caso personal.

Páginas de categorías

  • Cada categoría debe clasificarse a su vez en, al menos, una categoría padre, excepto las categorías de base, las cuales son: Category:Archive, Category:DeveloperWiki, Category:Languages, Category:Maintenance y Category:Sandbox.
  • Una categoría padre puede articularse en varias categorías, siempre y cuando ninguna sea a su vez categoría padre (o, en general, antecedentes) una de la otra.
  • Evite las relaciones circulares: dos categorías no pueden ser ascendente la una de la otra recíprocamente.
  • No clasifique una categoría consigo misma (categoría autocategorizadas ).
  • Las categorías deben ser colocadas en la parte superior de la página de categoría.
  • Las categorías no pueden hacer redirecciones, excepto temporalmente durante su renombre.
  • Por defecto, los nombres de las categorías deben estar en forma singular (categorías «temática», por ejemplo Category:Simulation); deben estar en forma plural si la forma singular se puede usar para describir «uno» de sus miembros (categorías «conjunto», por ejemplo Category:Boot loaders)).

Páginas de redirección

  • Se recomienda crear páginas de redirección para acrónimos o variantes gramaticales del título de un artículo existente, o para un término o tema discutido en una subsección de un artículo más genérico, por ejemplo ALSA, daemon o AIGLX. Los redireccionamientos pueden simplificar el texto de origen al reemplazar los enlaces etiquetados, compárense los ejemplos anteriores con [[Advanced Linux Sound Architecture (Español)|ALSA]], [[Daemons (Español)|daemon]] o [[Xorg#Composite|AIGLX]].
  • Las páginas de redirección deben contener solo el código de redirección y nada más. Las únicas excepciones son:
  • Redirigir solo a artículos internos; no utilizar redirecciones con enlaces interwiki.
Los redireccionamientos que utilizan enlaces interlingüísticos están excepcionalmente permitidos de acuerdo con Help:i18n y previa autorización del equipo de mantenedores.

Páginas de usuario

  • Las páginas en el espacio del nombre del usuario no se pueden categorizar.
  • Las páginas en el espacio de nombres del usuario solo se pueden vincular a otras páginas del espacio del nombre de usuario o talk, a menos que los Administradores den la autorización para hacer otra cosa.

Reglas comunes

Resumen de edición

Consulte ArchWiki:Contributing#The 3 fundamental rules.

Etiquetas HTML

  • El uso de etiquetas HTML es generalmente desaconsejado: siempre es preferible utilizar el código wiki o plantillas (templates) cuando sea posible, consulte Help:Editing (Español) y artículos relacionados.
  • Cuando se esté tentado de usar <pre>código</pre>, use mejor {{bc|código}} en su lugar. En vez de usar <tt>texto</tt> o <code>texto</code>, use siempre {{ic|texto}}.
  • Evite especialmente los comentarios HTML (<!-- comment -->): es preferible que una nota añadida en un comentario HTML sea mostrada explícitamente en la página de discusión del artículo. Se puede agregar una adecuada plantilla del estado del artículo en lugar del comentario.
  • Use la etiqueta <br> solo cuando sea necesario: para empezar un párrafo nuevo o un salto de línea, basta poner una línea en blanco debajo de ella.
    Las excepciones más comunes a esta regla son cuando hay que romper una línea en un elemento de una lista y no se puede utilizar un subelemento, o dentro de una plantilla y no se puede utilizar una lista.