# Help:Style (Español)

Artículos relacionados

- Help:Style/Formatting and punctuation
- Help:Style/White space
- Help:Editing (Español)
- Help:Reading (Español)

Las siguientes normas de estilo están orientadas a conseguir artículos ordenados, organizados y coherentes visualmente. A todos los colaboradores se les invita a seguir las presentes directrices tan de cerca como les sea posible al editar artículos de ArchWiki.

## Páginas que contienen 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.
- 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.
- Véase también Help:Article naming guidelines.

### Estructura

- Los elementos de un artículo y su prelación se muestran como sigue:

1. Magic words (opcional)
2. Categorías[broken link: invalid section]
3. Enlaces interlenguas[broken link: invalid section]
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 interlenguas, si están presentes), ya que ésto introduce un espacio adicional en la parte superior del artículo.
- Véase también Recategorizing Pages.

### Enlaces interlenguas

- Si el artículo tiene traducciones en la wiki local o en una wiki de Arch Linux externa, debe incluir el enlace interlengua inmediatamente debajo de categorías y antes de la primera línea del texto.
  Advierta que los enlaces interlenguas se muestran realmente en la columna de la parte izquierda de la página.
- No debe haber líneas en blanco entre los enlaces interlengua 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 interlengua 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 interlengua para cada idioma a un artículo.
- No añada un enlace interlengua para el mismo idioma del artículo.
- Los enlaces interlengua 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éase también Help:I18n (Español) y Wikipedia:Ayuda:Enlace interlingüístico.

### Plantillas del estado del artículo

- Las plantillas del estado del artículo pueden incluirse justo debajo de las categorías (o enlaces interlenguas, 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.
- Se visualiza en el cuerpo central de la página del artículo, en los mismos términos que el resto del contenido del texto.
- 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 interlengua o plantillas estado del artículo, si están presentes).
- Únicamente puede estar compuesta por las plantillas Template:Related articles start (Español), 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 Véase también para proporcionar una lista más completa y detallada, que también incluye 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 los 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 también Writing Article Introductions.

### 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: Vea también esta página.
  Por la misma razón, evite también el uso de cualquier tipo de etiquetas (html o wiki), incluyendo las plantillas de formato del código.
- Consulte el artículo sobre uso efectivo de encabezados.

### Plantillas de formato del código

- Use `{{ic|código}}` 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 similares, por ejemplo:
  Ejecutar `sh ./hello_world.sh` en la consola.
- Use `{{bc|código}}` para representar en un bloque separado una o varias líneas de código (entrada o salida de la línea de órdenes y contenido de los archivos), por ejemplo:

    $ sh ./hello_world.sh

    Hello World

    #!/bin/sh

    # Demo
    echo "Hello World"

  Para enmarcar líneas de código cortas, basta con que vengan precedidas de un espacio en blanco en lugar de utilizar la etiqueta `{{bc|código}}` (consulte Help:Editing (Español)).

- Use `{{hc|entrada|salida}}` 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 usar `{{hc|nombre-del-archivo|contenido}}` para mostrar el nombre del archivo en el título, por ejemplo:

    ~/hello_world.sh

    #!/bin/sh

    # Demo
    echo "Hello World"

- 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

- Use el símbolo `$` como un aviso para las órdenes que se pueden ejecutar como usuario normal; use `#` como un indicador de órdenes utilizadas como 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`, a menos que sea realmente necesario.
- No presuponga que el usuario utiliza `sudo` u otras utilidades para obtener los privilegios de root (por ejemplo, `gksu`, `kdesu`).
- `# sudo orden` es redundante y debe ser evitado. La única excepción es cuando sudo se utiliza con la opción -u: en este caso el prompt puede coincidir con otros símbolos del mismo bloque de código, o por defecto con `$`.
- No agregue comentarios en el mismo recuadro de una orden (por ejemplo, `# pacman -S foo #Instala el paquete foo`).
- Evite escribir líneas excesivamente largas de código: en estos casos use técnicas de saltos de línea cuando sea posible.

### 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

### 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. Tenga en cuenta que los nombres de las teclas en español son diferentes a las del inglés y deben traducirse:
  - `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`

### 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:
  Instalar paquete de los repositorios oficiales. 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, disponible en los repositorios oficiales.
  Las instrucciones para la instalación de una lista de paquetes puede aparecer como:
  Instalar paquete1, paquete2 y paquete3 disponible en los repositorios oficiales. 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|paquete}}`.
- Observe que los ejemplos anteriores hacen también uso de un vínculo implícito al artículo de pacman (por ejemplo `[[pacman|Instale]] ...`) y uno a Official repositories (`[[Official repositories|repositorios oficiales]]`): se recomienda utilizar esta fórmula, al menos en la primera aparición de una solicitud de instalación, sobre todo en artículos que tienen más posibilidades de ser visitados por los principiantes de 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 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.
  Use, en su lugar, una frase similar a la siguiente:
  Instalar el paqueteAUR, disponible en el Arch User Repository.
  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|paquete}}`.
- Siempre se debe dejar en claro que el paquete no es oficial, aunque enlazándolo al artículo Arch User Repository o a una de sus redirecciones, por ejemplo AUR.

#### 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[broken link: invalid section].
  No proporcione más instrucciones para activar el repositorio directamente en el artículo.
- El enlace a Unofficial user repositories es obligatorio y debe apuntar a la sección del repositorio correspondiente, por ejemplo `[[Unofficial User Repositories#example|ejemplo]]`.

### Operaciones con los módulos del Kernel

- Proporcionar ejemplos de cómo cargar, eliminar, incluir en blacklist o realizar cualquier otra operación básica es una práctica en desuso: la fórmula estándar consiste en listar los módulos implicados, posiblemente señalando las dependencias o conflictos con otros módulos, una descripción de las acciones a realizar, y un enlace a los módulos del kernel.
- La Guía para principiantes y sus subpáginas son las únicas excepciones a las reglas anteriores.

### Operaciones con los demonios

- Dar ejemplos de cómo activar, iniciar o realizar cualquier otra operación con demonios es una práctica en desuso: la fórmula estándar consiste en listar los demonios implicados, posiblemente señalando las dependencias o conflictos con otros demonios, una descripción de las acciones a realizar, y un enlace a systemd

- La Guía para principiantes y sus subpáginas son las únicas excepciones a las reglas anteriores.

### Notas, advertencias y sugerencias

- Una Nota 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 Advertencia 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 Sugerencia 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.

### Shell

- 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

- Trate de crear enlaces recíprocos entre el propio artículo y otros tantos como sea posible, utilizando las distintas palabras clave en el texto.
- Para conocer los términos técnicos como llamada al sistema que no están tratados en ningún artículo en ArchWiki, cree un enlace a la correspondiente página de Wikipedia.
- Cuando se enlaza a otros artículos de la wiki no use direcciones URL completas, sino que aproveche la sintaxis especial para enlaces internos: `[[Artículo de la Wiki]]`. Este método también permitirá que el motor wiki haga un seguimiento de los enlaces internos para así facilitar el mantenimiento.
  Véase Help:Editing (Español)#Enlaces para obtener información detallada y usos más avanzados de la sintaxis de los enlaces interwiki.
- Excepto en raras ocasiones, no se debe dejar un artículo como una página sin salida o una página huérfana (esto es, un artículo que no está vinculado a ningún otro).
- Antes de escribir un procedimiento específico en un artículo, o describir algo en particular, verifique siempre que no existe un artículo que trate esa parte en detalle: en ese caso, cree un vínculo con dicho artículo en lugar de duplicar su contenido.
- Si la documentación del autor original para el tema de su artículo está bien escrito y mantenido, es preferible simplemente escribir adaptaciones específicas para Arch y crear un enlace a la documentación oficial para la información general.
- No utilice enlaces interlinks para conectar páginas locales de la misma lengua del artículo que se está editando, ya que no se muestra en las páginas Special:WhatLinksHere. Por ejemplo, el uso del enlace a `[[:es:Main Page]]` desde un artículo español está mal, mientras que `[[Main Page (Español)]]` es la forma correcta.
  En cambio el uso de este tipo de enlaces entre artículos de diferentes lenguas es aceptable, ya que esto haría más fácil mover los artículos a una wiki externa en caso de que sea creada. Por último, advierta la diferencia de este tipo de enlaces con los enlaces interlenguas[broken link: invalid section], los cuales no tienen los dos puntos al principio.

### Estilo de codificación

- Al agregar órdenes o scripts, utilice un estilo de codificación coherente en todo el artículo, quizás refiriéndose también a otros artículos, especialmente si están relacionados. Si es posible, respete las directrices de estilo de codificación más comunes u oficiales por el lenguaje utilizado.
- Evite características obsoletas por el lenguaje de programación/scripting que esté utilizando: por ejemplo, use la sintaxis `$()` para sugerir la orden de la shell en lugar de la sintaxis ````.

### 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.

### Secciones «Consejos y trucos»

- Contienen sugerencias avanzadas o ejemplos sobre el uso del software.
- El título estándar es Consejos y trucos.
- Los diversos consejos y trucos deberían organizarse en subsecciones.

### Secciones «Solución de problemas»

- Contiene las preguntas más frecuentes sobre el software o las soluciones a problemas más comunes (compárese con #Secciones «Problemas conocidos»).
- El título estándar es Solución de problemas; el uso de la voz inglesa Troubleshooting, no es considerada adecuada conforme a esta guía.
- 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. Enlazar un informe de error 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.

### Secciones «Problemas conocidos»

- Contiene fallos conocidos o problemas de uso para los que no existe todavía una solución (comparar con #Secciones «Solución de problemas»).
- El título estándar es 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.

### Secciones «Véase también»

- 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 Véase también, otros títulos similares como Enlaces externos, Más recursos, etc. deben ser evitados.

### 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.

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.

### Registro lingüístico

- Los artículos deben ser escritos utilizando un lenguaje formal, profesional y conciso.
- 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.
- Evite las construcciones personales, por ejemplo, el uso de la segunda persona («instala», «tienes que instalar»). Como alternativa, se recomienda el uso del imperativo («instale»), formas en infinitivo («instalar»), impersonales («debe instalar») o pasivas («se debe instalar»).
- Evite abreviaturas innecesarias de las palabras: por ejemplo, en lugar de «repo», «distro» y «config» es preferible «repositorio», «distribución» y «configuración».
- Escriba objetivamente: no incluya comentarios personales en los artículos, utilice la página de discusión a ese propósito. En general, no escriba en primera persona.

## Páginas de discusión

- Para añadir nuevas discusiones coloque su mensaje al final de la página de discusión, a continuación de la última aportación, y con un título apropiado. También puede hacer uso de la etiqueta `+` situada en la parte superior de cada página de discusión.
- Utilice texto sangrado para sus respuestas a una pregunta, colocando dos puntos en el comienzo de las nuevas líneas, de esa forma se jerarquizan las distintas aportaciones y es más fácil seguirlas y visualizarlas.
- No edite sus mensajes si alguien ya ha respondido en términos similares, de lo contrario se pierde el ritmo de la discusión y puede hacer difícil que otros respondan más. Para llamar la atención es admisible marcar una palabra o frase (usando la etiqueta `<s>`), pero la explicación subsiguiente debe venir como una respuesta normal.
- Termine siempre su intervención con la firma del usuario (`~~~~`).
- Las páginas de discusión no pueden ser categorizadas.
- Hay que recordar marcar el título de los debates agotados usando la etiqueta `<s>`.
  Las discusiones terminadas se eliminarán después de un tiempo prudencial.
- Véase también Help:Editing (Español)#Páginas de discusión.

## Páginas de la categoría

- Cada categoría debe clasificarse a su vez en, al menos, una categoría padre, excepto las categorías de base.
  Categorías base son: Category:DeveloperWiki, Category:Languages 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 auto-categorizadas ).
- Las categorías deben ser colocadas en la parte superior de la página de categoría.
- Las categorías no pueden hacer redirecciones.

## Páginas de redirección

- Las páginas que redirigen a otras deben contener solo el código de redirección, nada más.
- Redirigir solo a artículos internos; no utilizar redirecciones con enlaces interwiki.

## Páginas de template

- Véase Help:Template.

## Páginas de usuario

- Las páginas de usuario no se pueden clasificar.

## Reglas comunes

### Resumen de edición

- Los cambios realizados a diario en los artículos son revisados ​​con dedicación por colaboradores, a quienes se debe facilitar el trabajo asegurándonos de que todas las ediciones que realicemos van acompañadas de algunas palabras explicativas en el campo «Resumen» de la página editada.
  - Si la edición es menor, por ejemplo, correcciones gramaticales u ortográficas o una nueva reformulación de una frase, una simple descripción de la modificación será perfectamente suficiente.
  - Si va a realizar un cambio importante, por ejemplo, agregar, mover, modificar o eliminar el contenido, además de resumir la edición, debe facilitar las razones por las que ha hecho falta dicho cambio en el artículo, incluso proporcionando un enlace a la discusión en la wiki o los foros, si es que existen.
  - Una explicación no es obligatoria en las páginas de discusión, donde el por qué debería ser ya evidente. Al eliminar discusiones agotadas, sin embargo, se requieren algunas palabras explicativas (por ejemplo, «debate cerrado», «resuelto», etc.) y que incluyan también el título de la discusión para poder recuperarla en el historial en el caso de que el debate necesite ser reabierto.

  Sugerencia: Consulte los resúmenes de edición en Cambios recientes para tener una idea de lo que se debe escribir en el resumen, pero tenga en cuenta que, por desgracia, no todos los usuarios respetan estas directrices

- Cuando se realizan cambios importantes en uno o más artículos, lo mejor sería tratar de dividir su obra en ediciones múltiples, basándose en los pasos lógicos seguidos para completar la operación.
  Especialmente cuando se mueven secciones completas (tanto en el mismo artículo como entre artículos distintos), se debe evitar cambiar el contenido de la edición misma, de lo contrario será más difícil de verificar la consiguiente diferencia.

### 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.

Category:

- Help (Español)

Hidden category:

- Pages with broken section links