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 MediaWiki . Si existe la posibilidad, es mejor utilizar módulos lua .
Muchos errores están asociados con la dificultad para manejar algunas características incómodas en el lenguaje de marcado que conducen a errores de codificación. Los metacaracteres desequilibrados son una fuente importante de errores. Por ejemplo, codificar {{1}}}en lugar de {{{1}}}hace que actúe como si fuera {{1}} }, invocando así Plantilla:1 + "}".
Hay algunas diferencias en el formato wiki del contenido de los parámetros cuando están dentro de #expresiones-if, pero no cuando están fuera. Las plantillas que deben sustituirse requieren un tratamiento especial. También se cubre el suministro de parámetros predeterminados o alias de parámetros.
Dentro de una sola plantilla, el límite de anidamiento es de 40 expresiones anidadas, como 40 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 está anidada más allá de 40 niveles, una plantilla puede contener cientos de expresiones if y ramas de cambio, pero no todas anidadas dentro de las demás.
Algunas plantillas han contenido cálculos condicionales complejos anidados en 23 niveles de profundidad durante años. Además, algunas plantillas han contenido cientos de expresiones if, durante años, pero NO todas anidadas como una sola, gigante: if-then-else-else-else-else-else... .
Un problema que complica el procesamiento de plantillas, para parámetros, es el formato wiki del contenido de los parámetros cuando están dentro de if-logic (como #if o #ifeq) o #switch (o lc:, lcfirst:, uc:, ucfirst:) . En mayo de 2012 [actualizar], el analizador de marcado de MediaWiki todavía da formato wiki al contenido de los parámetros cuando están dentro de expresiones #if (pero no fuera). Esto significa que los parámetros que contienen espacios, punto y coma, dos puntos (":") o signo de libra ("#") pueden cambiar sus valores mientras están dentro de las cláusulas if (¡sorpresa!). Entonces, por ejemplo, un parámetro {{{4}}}cuando está fuera de #if puede mostrarse de manera diferente que dentro {{#ifeq:{{{1}}}=0|{{{4}}} ...}}. La peor sorpresa es cuando el parámetro 4 contiene un punto y coma inicial, lo que activa el formato para que se convierta en la antigua línea de encabezado de punto y 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 ocurre dentro de las expresiones de marcado #if, #ifexpr, #ifeq o #switch. Si el parámetro está precedido por texto, en cualquiera de las cláusulas then/else, entonces el formato wiki dentro del parámetro no ocurre.
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 "#" activó la numeración automática de la línea (sangría con "1"). La situación de tener un punto y coma, dos puntos o "#" al principio puede ser relativamente rara, pero esto es sólo un recordatorio: para mostrar el verdadero contenido de un parámetro de plantilla, intente mostrar un parámetro fuera del inicio de cualquier cláusula de declaración if, o mostrar otro texto antes del parámetro dentro de la lógica if, o prepararse para algunos resultados impactantes cuando un parámetro tenga formato wiki para mostrarse dentro de la lógica if.
Si el resultado de #if, etc. no está pensado para ser formateado, usar #, :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, intentando aislar la sección de código donde es más probable que se produzcan errores de codificación. La revisión intensiva del flujo lógico suele ser la solución más rápida, como comprobar errores de sintaxis típicos (ver más abajo: "Errores de codificación comunes"). A veces, una sección de código problemático se podía copiar en una página de prueba breve y luego, mediante la vista previa de edición, se podía 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 podría desarrollar una plantilla, en las primeras etapas, como múltiples secciones de código, cada una de las cuales se depuraría por separado y luego, eventualmente, se unirían, como secciones anidadas con if-then-else-if.
Como revisión de esas opciones, considere:
La estrategia básica: aislar la sección de código que se va a depurar.
A continuación, la prueba de cada sección de código es crucial. Hay algunos viejos adagios a los que debemos prestar atención:
Quizás incluya una variedad de ejemplos en la subpágina de documentación de cada plantilla para ayudar a detectar problemas en las primeras etapas del desarrollo. Sin embargo, para plantillas complejas, la página de discusión, o una subpágina especial "/testcases", debe contener una sección de numerosos ejemplos (muchos de ellos) para demostrar el alcance completo de las características de la plantilla.
Al desarrollar secciones de marcado que utilizan parámetros de plantilla, intente establecer siempre cada parámetro con un valor predeterminado, especialmente dentro de expresiones o codificación de lógica if:
{{#expr: 109.75 / {{{1|1}}} }}→ predeterminado {1} como 1, 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 podría cambiarse fácilmente, en un editor de texto, mediante una sustitución de cadena global de búsqueda y reemplazo , para cambiar el valor predeterminado a algún otro valor, por ejemplo. probando cada caso.
Si esos parámetros no reciben valores predeterminados, entonces esas secciones de código no se pueden probar 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 de triple llave (como los 7 caracteres literales: ), y los parámetros no predeterminados no se pueden evaluar, en expresiones o lógica if, durante una vista previa de edición de la página de plantilla.{{{x}}}
Hay varios errores de codificación comunes que causarán problemas al procesar plantillas. Lo siguiente se puede utilizar como lista de verificación para ayudar a depurar problemas cuando una plantilla parece actuar de manera extraña:
{{{1}}}}<!--al comienzo de un comentario HTML puede provocar resultados extraños, sin ningún mensaje de error. Olvidar el signo de exclamación es muy común: debería ser .<--<!---->al final de un comentario HTML puede provocar 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 advertir que 3 y 2 llaves podrían ser un problema: se trata como "{Template:Size" al intentar pasar 180 px como parámetro debido a que solo hay 2 llaves finales .{{{size|180px}}
Una vez más, comprobar siempre primero los errores comunes, como primer paso, puede evitar tener que buscar "errores complejos" que en realidad nunca existieron. Recuerde: el lenguaje de marcado de MediaWiki es extremadamente propenso a errores, por eso ocurren tantos errores de codificación, y es por eso:
Muchos problemas horribles en realidad son correcciones de sintaxis de solo 1 minuto.
En casos excepcionales, es posible que sea 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 y 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: Es probable que todas las palabras clave y "noinclude" adicionales requieran que se vuelva a sangrar el marcado de la plantilla para que quepa en todo ese texto adicional insertado, lo que ampliará y saturará el estilo de marcado original.<noinclude><!--HTML comment HERE--></noinclude>safesubst:<noinclude/>
Específicamente, para modificar una plantilla para 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 cómo insertar el prefijo safesubst dentro del marcado de una plantilla:safesubst:<noinclude/>{{
Total articles now: {{NUMBEROFARTICLES}}→ 6.857.515Total articles was: {{ subst:NUMBEROFARTICLES}}→ 3.953.715{{ safesubst:<noinclude/>#ifeq:{{{1|AX}}}|AX|yes}}{{ safesubst:<noinclude/>lc:THIS LOWERCASE TEXT}}→ este texto en minúsculaEn general, cada función de marcado que comienza con doble llave {{debe modificarse para insertar el prefijo seguro largo (sin espacios 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 denominarse "ifsubst", ya que significa "si se usó '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 usa 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án sin cambios, sin un prefijo de subst seguro.{{{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 mediante 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 normal, pero fallará si la plantilla se ejecuta utilizando el prefijo del modo subst "subst:". Para obtener más ejemplos y explicaciones técnicas adicionales, consulte: WP:Substitution .
Sangría de las líneas largas: todo el texto agregado del prefijo de subst seguro ensanchará las líneas, por lo que, para mejorar la legibilidad, se pueden 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 ajustar una línea después del prefijo porque varias funciones de marcado pueden 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 surgir el 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 origen, Plantilla:Citation/core , muestra un formato de cita estandarizado, 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 Especial:ExpandTemplates toma algo de wikitexto y expande todo entre llaves dobles de forma recursiva: plantillas, funciones del analizador como {{#if:...}} y variables como {{CURRENTDAY}}
<noinclude>etiquetas.([^{]){{([^{])y reemplácelo con\1{{ safesubst:<noinclude/>\2s/([^{]){{([^{])/\1{{ safesubst:<noinclude/>\2/g