Help:Style (Español)

From ArchWiki
Revision as of 10:39, 27 July 2013 by Pedro (Talk | contribs) (Estructura: Actualizar)

Jump to: navigation, search
Sumario help replacing me
Esta página proporcina las líneas maestras para la estandarización del estilo en los artículos de ArchWiki.
Relacionado
Help:Editing (Español)
Help:Reading (Español)

Las siguientes convenciones 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.

Artículos

Título

  • 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 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
  3. Enlaces interlenguas
  4. Plantillas del estado del artículo (opcional)
  5. Sumario (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í mismos, 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.

Sumario

  • Contiene el sumario o resumen de la estructura y el alcance del artículo.
  • Elemento opcional que se incluye justo debajo de las categorías (o enlaces interlenguas o plantillas del estado del artículo, si están presentes).
  • Se visualizará en la columna derecha de la página del artículo.
  • Los resúmenes del artículo se estructuran en un conjunto de plantillas que, a parte de incluir el sumario propiamente dicho ("summary text"), se incluyen otras plantillas como el "summnary heading", donde se suele colocar, por lo general, o bien una descripción del artículo donde se hace una breve reseña sobre algún dato relevante o de interés del tema tratado proporcionándonos así una visión más general y coherente del asunto, y/o bien artículos relacionados donde se enumeran una serie de enlaces internos a otros artículos de la wiki que están relacionados con el tema tratado y cuyo conocimiento nos proporcionará una visión más comprensiva y sistemática de Arch.
  • Consulte también Writing Article Overviews.

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 del sitio web oficial del proyecto, si los hubiere. Un ejemplo es MediaTomb.
  • Se coloca justo debajo del sumario (o de las plantillas de estado del artículo o de los enlaces interlenguas o de la categoría(s), en su defecto).
  • 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.

Líneas en blanco

  • Evite el uso de múltiples líneas en blanco para separar párrafos o secciones.
  • Consulte el artículo sobre líneas en blanco para más información.

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 comandos, nombres de variables, y similares, por ejemplo:
    foo código bar.
  • 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 comandos y contenido de los archivos), por ejemplo:
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0    unassociated  ESSID:""
         Mode:Managed  Channel=0  Access Point: Not-Associated
         Bit Rate:0 kb/s   Tx-Power=20 dBm   Sensitivity=8/0
         Retry limit:7   RTS thr:off   Fragment thr:off
         Power Management:off
         Link Quality:0  Signal level:0  Noise level:0
         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
         Tx excessive retries:0  Invalid misc:0   Missed beacon:0
#!/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 comandos, por ejemplo:
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0    unassociated  ESSID:""
         Mode:Managed  Channel=0  Access Point: Not-Associated
         Bit Rate:0 kb/s   Tx-Power=20 dBm   Sensitivity=8/0
         Retry limit:7   RTS thr:off   Fragment thr:off
         Power Management:off
         Link Quality:0  Signal level:0  Noise level:0
         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
         Tx excessive retries:0  Invalid misc:0   Missed beacon:0
  • 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"
  • Para obtener instrucciones acerca de Template:Keypress, consulte #Keyboard keys.
  • 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 comandos

  • Use el símbolo $ como un aviso para los comandos que se pueden ejecutar como usuario normal; use # como un indicador de comandos utilizados 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 un comando o cuándo se está editando un archivo de texto.
  • La frase introduciendo un comando normalmente debe terminar con dos puntos :.
  • Es preferible usar # command en lugar de escribir $ sudo command, 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 command es siempre un error.
  • No agregue comentarios en el mismo recuadro de un comando (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 los comandos implícitos 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

Instrucciones para la gestión de los paquetes

Paquetes oficiales

  • Procure evitar el uso de ejemplos de comandos 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, sólo 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.
  • Los ejemplos de comandos de pacman están comunmente aceptados y recomendados, incluso, en la Guía de principiantes y sus subpáginas.
  • 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 paquete disponible en el repositorio oficial [multilib].

Paquetes de AUR

  • Para solicitar la instalación de los paquetes de AUR utilice una redacción como:
    Instalar paqueteAUR disponible en Arch User Repository.
    El código wiki para ésto es Instalar {{AUR|paquete}} disponible en [[Arch User Repository]]. Obviamente, tiene permitida la flexibilidad necesaria para adaptar la redacción a su artículo específico, aunque siempre se debe dejar claro que el paquete no es oficial.
  • 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.

Operaciones con los módulos del Kernel

  • Proporcionar ejemplos de cómo agregar módulos a la matriz MODULES en /etc/rc.conf es una práctica en desuso: la fórmula estándar consiste simplemente en listar los módulos implicados, señalando, en su caso, las dependencias o conflictos con otros módulos y un enlace a los módulos del kernel.
  • Proporcionar ejemplos de cómo cargar, eliminar, incluir en blacklist o realizar cualquier otra operación básica con los módulos es una práctica en desuso: la fórmula estándar consiste en describir 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 agregar los demonios a la matriz DAEMONS en /etc/rc.conf es una práctica en desuso: la fórmula estándar consiste simplemente en listar los demonios implicados, señalando, en su caso, las dependencias o conflictos con otros demonios, y un enlace a Daemon.
  • Dar ejemplos de cómo iniciar, reiniciar o detener demonios es una práctica en desuso: la fórmula estándar consiste en describir las acciones a realizar, y un enlace a Daemon. Sin embargo, si la acción solicitada no afecta directamente a uno de ellos, proporcionar ejemplos es aceptable, y debe hacer uso del comando rc.d en lugar de utilizar la ruta completa del comando /etc/rc.d/daemon.
  • La Guía para principiantes y sus subpáginas son las únicas excepciones a las reglas anteriores.

Plantillas sobre Notas, Advertencias y Tips (consejos)

  • La plantilla 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.
  • La plantilla 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.
  • La plantilla Tip 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 tips 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:Página principal]] desde un artículo español está mal, mientras que [[Página Principal (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, lo cuales no tienen los dos puntos al principio.

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: Sólo 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 sólo 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 sólo 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 las categorías lingüísticas, como Category:English y algunas otras categorías especiales: Category:DeveloperWiki, Category:Sandbox y Category:Template.
  • 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.

Redirigir las páginas

  • Las páginas redirigidas deben contener sólo el código de redirección, nada más.
  • Redirigir sólo a artículos internos, no utilizar redirecciones con enlaces interwiki.

Páginas de template

Páginas de usuario

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

Normas generales

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.
Tip: 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> sólo 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.