Help:Style (Español)

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
Ayuda:Estilo/Formato y puntuación
Ayuda:Estilo/Espacio en blanco
Ayuda:Edición
Ayuda:Lectura
Ayuda:Discusión
Ayuda:Plantilla
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
Ayuda:Directrices de nomenclatura de artículos
para obtener más información.
Estructura
Los elementos de un artículo y su prelación se muestran como sigue:
Magic words
(opcional)
Categorías
Enlaces interlingüísticos
(opcional)
Plantillas sobre el estado del artículo
(opcional)
Artículos relacionados
(opcional)
Prólogo o introducción
Tabla de contenidos (generada automáticamente)
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.
Véase el artículo
Ayuda:Categoría
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 recuadro ú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»
La sección
Installation
(«Instalación») describe cómo instalar el software, consulte
#Instrucciones para la gestión de los paquetes
.
Utilice el título estándar de
Installation
y póngalo al principio del artículo.
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:
Véase
Algún artículo relacionado
para más información.
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 (Español)/Formatting and punctuation (Español)
.
Véase
Help:Effective use of headers (Español)
para obtener más información.
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
|Ayuda:Plantillas
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
—
Note (Español)
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
—
Warning (Español)
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
—
Tip (Español)
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 (Español)#Adjuntar, añadir, crear, editar
.
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
foobar
AUR
.
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 en
Unofficial user repositories
y luego simplemente enlazar con él. Por ejemplo:
Instale el
paquete
AUR
disponible en
Arch User Repository
o en el Repositorio
ejemplo
.
Si el paquete también está disponible en
AUR
:
Instale el paquete
foobar
AUR
, también disponible en el repositorio
ejemplo
.
Si el paquete está disponible en
AUR
con un nombre diferente:
Instale el paquete
aurpkg
AUR
, 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
netctl-auto@.service
con el nombre de la interfaz, por ejemplo
netctl-auto@wlan0.service
.
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 (Español)#Organización
.
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
Las
páginas de manual
deben ser referenciadas utilizando la plantilla
Template:man
.
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:
las páginas
archivadas
, que aunque de hecho son redirecciones, deben clasificarse en
Category:Archive
.
las
categorías renombradas
pueden contener la etiqueta
Template:Archive
.
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
.
Consulte
Help:Editing#Redirects
para obtener más información.
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
Véase
Las 3 reglas fundamentales
.
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.