Existen algunas técnicas avanzadas de codificación de plantillas para mejorar la visualización o edición de plantillas en Wikipedia . También existen algunas tácticas para depurar parámetros de plantilla en el lenguaje de marcado de MediaWiki . Si existe la posibilidad, es mejor utilizar módulos lua .
Muchos errores están asociados con la dificultad de manejar algunas características extrañas en el lenguaje de marcado que conducen a errores de codificación. Los metacaracteres desequilibrados son una fuente importante de errores. Por ejemplo, la codificación {{1}}}en lugar de {{{1}}}hace que actúe como si fuera {{1}} }, invocando así Template:1 + "}".
Existen algunas diferencias en el formato wiki de los contenidos de los parámetros cuando se encuentran dentro de expresiones #if, pero no cuando se encuentran fuera. Las plantillas que deben sustituirse necesitan un manejo especial. También se aborda la cuestión de proporcionar valores predeterminados o alias de parámetros.
Dentro de una sola plantilla, el límite de anidación es de 40 expresiones anidadas, como 40 expresiones múltiples "if-then-else-if..." . En la palabra clave "if" anidada número 41, puede aparecer un mensaje de error como: "Límite de anidación excedido" . Sin embargo, cuando no se anida más allá de 40 niveles, una plantilla puede contener cientos de expresiones if y ramas switch, pero no todas anidadas dentro de las otras.
Algunas plantillas contienen cálculos condicionales complejos anidados en 23 niveles de profundidad desde hace años. Además, algunas plantillas contienen cientos de expresiones if desde hace años, pero NO todas anidadas como una sola: if-then-else-else-else-else-else... .
Un problema que complica el procesamiento de plantillas, para los parámetros, es el formato wiki del contenido de los parámetros cuando se encuentran dentro de una lógica if (como #if o #ifeq) o #switch (o lc:, lcfirst:, uc:, ucfirst:). A partir de mayo de 2012 [actualizar], el analizador de marcado de MediaWiki sigue dando formato wiki al contenido de los parámetros cuando se encuentran dentro de expresiones #if (pero no fuera). Esto significa que los parámetros que contienen espacios, punto y coma inicial, dos puntos (:) o almohadilla ("#") pueden cambiar sus valores mientras se encuentran dentro de las cláusulas if (¡sorpresa!). Por ejemplo, un parámetro {{{4}}}cuando se encuentra fuera de un #if puede mostrarse de forma diferente que dentro de él . El peor impacto es cuando el parámetro 4 contiene un punto y coma inicial, lo que hace que el formato se convierta en la antigua línea de encabezado de punto y{{#ifeq:{{{1}}}=0|{{{4}}} ...}} coma en negrita :
TEST 1: {{#if:{{{4|}}}|{{{4|;}}} <== yes, semicolon|no, 4=empty}}TEST 2: {{#if:{{{4|;}}}|{{{4|;}}} <== yes, semicolon|no, 4=empty}}El problema se produce dentro de expresiones de marcado #if, #ifexpr, #ifeq o #switch. Si el parámetro está precedido por texto, en cualquiera de las cláusulas then/else, no se produce el formato wiki dentro del parámetro.
TEST 3: {{#ifexpr:{{{1|7}}}=7|<b></b>{{{4|;}}} equals 7|not 7}}TEST 4: {{#ifexpr:{{{1|7}}} < 9|{{{4|#}}} LESS THAN 9|not<9}}TEST 5: {{#ifexpr:{{{1|7}}} < 9| {{{4|#}}} LESS THAN 9|not<9}}TEST 6: "{{#ifexpr:{{{1|7}}} < 9| {{{4|#}}} LESS THAN 9|not<9}}"En la PRUEBA 4, el signo de almohadilla inicial "#" activó la numeración automática de la línea (sangrada con "1"). La situación de tener un punto y coma, dos puntos o "#" iniciales puede ser relativamente rara, pero esto es solo un recordatorio: para mostrar el contenido real de un parámetro de plantilla, intente mostrar un parámetro fuera del comienzo de cualquier cláusula de declaración if, o muestre otro texto antes del parámetro dentro de la lógica if, o bien prepárese para algunos resultados impactantes cuando un parámetro esté formateado en wiki para mostrarse dentro de la lógica if.
Si no se pretende formatear el resultado de #if, etc., utilizar #, :, y ;en lugar de #, :, y ;funcionará bien.
TEST 7: {{#ifexpr:{{{1|7}}} < 9|{{{4|#}}} LESS THAN 9|not<9}}Muchos errores de codificación se pueden depurar más fácilmente si se intenta aislar la sección del código en la que es más probable que se produzcan. La corrección intensiva del flujo lógico suele ser la solución más rápida, como la comprobación de errores de sintaxis típicos (consulte a continuación: "Errores de codificación comunes"). A veces, una sección de código problemático se puede copiar en una página de prueba corta y, a continuación, mediante la vista previa de edición, probar allí por separado. Sin embargo, si editar esa ventana de página adicional parece demasiado esfuerzo, considere simplemente copiar el código en la parte superior de la plantilla actual. De manera similar, se puede desarrollar una plantilla, en las primeras etapas, como múltiples secciones de código, cada una para depurar por separado y luego finalmente unirlas, como secciones anidadas con if-then-else-if.
A modo de revisión de esas opciones, considere:
La estrategia básica: aislar la sección de código a depurar.
A continuación, la prueba de cada sección del código es crucial. Hay algunos viejos refranes que hay que tener en cuenta:
Quizás se podría incluir una variedad de ejemplos en la subpágina de documentación de cada plantilla para ayudar a detectar problemas en las primeras fases del desarrollo. Sin embargo, en el caso de plantillas complejas, la página de discusión o una subpágina especial "/testcases" debería contener una sección con numerosos ejemplos (una gran cantidad de ellos) para demostrar el alcance completo de las características de la plantilla.
Al desarrollar secciones de marcado que utilicen parámetros de plantilla, intente siempre configurar cada parámetro con un valor predeterminado, especialmente dentro de expresiones o codificación if-logic:
{{#expr: 109.75 / {{{1|1}}} }}→ predeterminado {1} como 1 y no cero.{{#ifeq: {{{answer|y}}}|y|show yes}}Si a un parámetro particular se le asigna el mismo valor predeterminado en toda la página, entonces ese valor se puede cambiar fácilmente, en un editor de texto, mediante una sustitución de cadena de búsqueda y reemplazo global , para cambiar el valor predeterminado a algún otro valor, para probar cada caso.
Si no se asignan valores predeterminados a esos parámetros, no se podrán probar esas secciones de código durante la vista previa de edición mientras se edita la plantilla. Cualquier parámetro sin un valor predeterminado se convertirá en el texto literal entre llaves triples (como los 7 caracteres literales: ), y los parámetros que no sean valores predeterminados no se podrán evaluar en expresiones o lógica if durante una vista previa de edición de la página de la plantilla.{{{x}}}
Existen varios errores de codificación comunes que pueden causar problemas al procesar plantillas. La siguiente lista de verificación se puede utilizar para ayudar a depurar problemas cuando una plantilla parece actuar de forma extraña:
{{{1}}}}<!--al principio de un comentario HTML puede provocar resultados extraños, sin mensaje de error. Olvidar el signo de exclamación es muy común: should be .<--<!---->al final de un comentario HTML puede generar resultados extraños, sin mensaje de error.{{#ifexpr {{{1|y}}}=0|then zero|else not}}Tenga en cuenta que esos errores de codificación comunes podrían haberse detectado fácilmente con un simple verificador de sintaxis, como la advertencia de que las llaves 3 y 2 podrían ser un problema: se trata como "{Template:Size" que intenta pasar 180px como parámetro debido a solo 2 llaves finales.{{{size|180px}}
Nuevamente, siempre verificar primero los errores comunes, como primer paso, puede ahorrar tiempo buscando "errores complejos" que en realidad nunca existieron. Recuerde: el lenguaje de marcado MediaWiki es extremadamente propenso a errores, por eso ocurren tantos errores de codificación, y por eso:
Muchos problemas horribles en realidad son simplemente correcciones de sintaxis de un minuto.
En casos excepcionales, puede ser necesario reescribir una plantilla para permitir la sustitución de texto (según WP:SUBST ), donde los resultados de ejecutar una plantilla se guardarán en la página durante una operación de edición-GUARDAR. En ese caso, el prefijo safesubst debe insertarse en cada función de marcado utilizada dentro de esa plantilla, en cada nivel de lógica anidada. Además, cada comentario HTML debe estar rodeado por etiquetas "noinclude": . [a] De lo contrario, todos los comentarios HTML activados se almacenarán dentro de la página GUARDADA, en la secuencia ejecutada al ejecutar la plantilla. NOTA: Todos los "noinclude" y palabras clave adicionales probablemente requerirán que el marcado de la plantilla se vuelva a sangrar en el interior, para que quepa todo ese texto insertado adicional, lo que ampliará y abarrotará el estilo de marcado original.<noinclude><!--HTML comment HERE--></noinclude>safesubst:<noinclude/>
En concreto, para modificar una plantilla y permitir la sustitución de texto, el prefijo debe insertarse dentro de la doble llave de apertura de cada función de marcado dentro de esa plantilla. Algunos ejemplos de inserción del prefijo safesubst dentro del marcado de una plantilla:safesubst:<noinclude/>{{
Total articles now: {{NUMBEROFARTICLES}}→ 6.903.617Total articles was: {{ subst:NUMBEROFARTICLES}}→ 3.953.715{{ safesubst:<noinclude/>#ifeq:{{{1|AX}}}|AX|yes}}{{ safesubst:<noinclude/>lc:THIS LOWERCASE TEXT}}→ este texto en minúsculasEn general, cada función de marcado que comienza con una doble llave {{debe modificarse para insertar el prefijo safesubst largo (sin espacio después). [b] La acción de la palabra clave "safesubst" es permitir la sustitución condicional del marcado, cuando se invoca toda la plantilla como {{subst:MyTemplate|...}}. En esencia, la palabra clave "safesubst" podría llamarse "ifsubst" con el significado de "si se utilizó 'subst:' para invocar esta plantilla, entonces sustitúyala aquí también".safesubst:<noinclude/>
Recuerde: el prefijo safesubst debe insertarse en cada función de marcado dentro de esa plantilla, excepto en la lógica de prueba que nunca se utiliza en una página real. Cualquier marcado que omita "safesubst" fallará si la plantilla se ejecuta mediante el modo subst, "{{subst:MyTemplate|...}}". Los parámetros no se modifican, por lo que permanecerían sin cambios sin un prefijo safesubst.{{{1}}}
Excepciones: Solo la lógica que nunca se almacenaría en una página podría omitir "safesubst", como la lógica de prueba que se activa con valores de parámetros especiales que nunca se usan dentro de una página almacenada. Cualquier marcado que omita "safesubst" solo funcionará durante la transclusión regular, pero fallará si la plantilla se ejecuta utilizando el prefijo de modo subst "subst:". Para obtener más ejemplos y explicaciones técnicas adicionales, consulte: WP:Substitution .
Sangría de líneas largas: todo el texto añadido con prefijo safesubst ensanchará las líneas, por lo que, para mejorar la legibilidad, se podrían dividir y sangrar antes de cualquiera de los prefijos. Por ejemplo:safesubst:<noinclude/>
{{ safesubst:<noinclude/>#ifeq:{{safesubst:<noinclude/>padleft:|1|{{{1}}} }}|A|Begins with "A"}}En ese estilo de sangría, el texto "safesubst:<noinclude/>" comienza la siguiente línea. Evite colocar una línea después del prefijo porque varias funciones de marcado podrían no funcionar correctamente a menos que el prefijo safesubst se adjunte inmediatamente antes de la palabra clave, comosafesubst:<noinclude/>{{ safesubst:<noinclude/>#ifeq:...}}
Al intentar realizar operaciones más complejas o intrincadas, puede existir un temor instintivo de que las plantillas no puedan ser tan grandes como se necesita. Sin embargo, hay muchas plantillas muy grandes que se han estado ejecutando, durante años, en Wikipedia, por ejemplo:
El formateador de notas al pie de fuente, Template:Citation/core , muestra un formato de cita estandarizado, tal como lo invocan varias plantillas contenedoras que pasan cientos de parámetros, donde la lógica central verifica 621 valores de parámetros, en las expresiones de marcado condicional.
La página Special:ExpandTemplates toma algo de wikitexto y expande todo lo que está entre llaves dobles de forma recursiva: plantillas, funciones de analizador como {{#if:...}} y variables como {{CURRENTDAY}}
<noinclude>etiquetas.([^{]){{([^{])y reemplázalo con\1{{ safesubst:<noinclude/>\2s/([^{]){{([^{])/\1{{ safesubst:<noinclude/>\2/g