stringtranslate.com

Discusión de plantilla: Aircontent

Subtítulos

Actualmente, esta plantilla agrega una serie de subtítulos pseudo usando texto en negrita y el marcado de fuente <big>. En mi opinión, eso crea un problema estético que me gustaría resolver. Técnicamente, el uso del marcado de fuente <big> también es un poco problemático, por razones de estándares HTML (deberíamos usar CSS), aunque ese es un problema bastante menor en mi opinión.

Así pues, actualmente la plantilla ofrece:

Ejemplo de subtítulo

Mi pensamiento es que, dado que la plantilla agrega una lista con viñetas, deberíamos usar el formato de encabezado de lista/elemento de lista normal, lo que significa usar el formato de lista de punto y coma/dos puntos, que proporciona:

Ejemplo de subtítulo
Artículo 1
Artículo 2
Artículo 3

Como alternativa, podríamos conservar los elementos con viñetas, que se verían así:

Ejemplo de subtítulo

Por supuesto, hay otras opciones de formato disponibles, pero el formato algo estandarizado que proporciona el punto y coma me parece adecuado. ¿Opiniones? ¿Sugerencias? ¿Alternativas?
—  V = IR ( Discusión  •  Contribuciones ) 19:13 1 jun 2011 (UTC) [ responder ]

Me gustaría ver una maqueta en un artículo, pero básicamente la última me parece bien. Tengo un tamaño de fuente mínimo establecido en mis navegadores, por lo que hacerla más pequeña no es un problema para mí. La plantilla está bloqueada para edición: solo los administradores pueden editarla. - Ahunt ( discusión ) 19:18, 1 de junio de 2011 (UTC) [ responder ]
Correcto, solo hay que usar {{ editprotected }} , pero necesitamos mostrar algún tipo de consenso para avanzar y que un administrador no involucrado venga y cumpla con la solicitud. Comenzaré un sandbox de plantillas (si aún no hay una) y crearé una plantilla modificada propuesta. Eso hace que sea más fácil para el administrador que viene a cumplir con la solicitud de edición, independientemente. ps.: Los tamaños de fuente en realidad dependen de la apariencia que uses. o, al menos, deberían. El uso del punto y coma aplica una clase CSS al texto, que puede ser diferente para diferentes apariencias. La etiqueta <big>, por otro lado, es una constante (que se define en CSS en estos días, pero no es fácil de cambiar ya que no es parte del CSS de las apariencias).
—  V = IR ( Discusión  •  Contribuciones ) 19:30, 1 de junio de 2011 (UTC) [ responder ]
Es cierto que el tipo de lista compuesto por punto y coma y dos puntos crea una lista de definiciones CSS. Encontrará que tenemos un par de administradores en el proyecto de la aeronave que probablemente ayudarán cuando llegue el momento, pero veamos primero el modelo en acción y lleguemos a un consenso sobre esa base. - Ahunt ( discusión ) 19:35, 1 de junio de 2011 (UTC) [ responder ]
El primer intento de cambio se puede ver en Template:Aircontent/testcases . Me voy a ocupar de algunas cosas en este momento, pero volveré más tarde.
—  V = IR ( Discusión  •  Contribuciones ) 19:42 1 jun 2011 (UTC) [ responder ]
A mí me parece bien, veamos si alguien más tiene alguna objeción. - 20:04, 1 de junio de 2011 (UTC)

Por favor, cambie la plantilla para utilizar lo que está en la zona de pruebas, según la discusión anterior. Saludos,
—  V = IR ( Discusión  •  Contribuciones ) 11:52, 2 de junio de 2011 (UTC) [ responder ]

 Hecho — Martin ( MSGJ  ·  discusión ) 13:33 3 jun 2011 (UTC) [ responder ]
¡Gracias!
-  V = IR ( Discusión  •  Contribuciones ) 20:27, 3 de junio de 2011 (UTC) [ respuesta ]

El apartado "Aeronaves comparables" no aparece en la plantilla de los artículos. - BilCat ( discusión ) 14:03 30 jun 2011 (UTC) [ responder ]

Titulares

¿Hay alguna razón por la que no se utilicen titulares? Curb Chain ( discusión ) 06:15 10 jul 2011 (UTC) [ responder ]

Creo que la codificación de la plantilla sí producía encabezados de nivel 4 antes del cambio mencionado anteriormente, aunque no estaban pensados ​​para que aparecieran en la tabla de contenidos, si es eso a lo que te refieres. Un problema evidente ahora es que los "encabezados" utilizan un tamaño de fuente mucho más pequeño, que rara vez se utiliza en artículos sobre aeronaves, y se ve muy extraño al lado de los otros encabezados estándar. Nimbus (Cumulus nimbus flota) 08:17, 10 de julio de 2011 (UTC) [ responder ]
Mmm, gracias. Bueno, parece que este cambio (arriba) no generó mucha discusión. Si crees que la fuente (tamaño) no es estándar o no está en armonía con los demás artículos, creo que deberíamos cambiarla. También propongo que se (re)introduzcan los titulares en el nivel 3 porque ==Ver también== es un nivel 2, ¿no? (Y, por supuesto, esto debería aparecer en la tabla de contenidos). Curb Chain ( discusión ) 06:38 12 jul 2011 (UTC) [ responder ]
El cambio se produjo después de que se rechazara otra sugerencia sobre ahorrar espacios en blanco; creo que no estuve de acuerdo con ambos cambios sugeridos. Creo que la sensación general sería que no aparecieran subtítulos de la sección "ver también" en la tabla de contenidos si se revirtiera el cambio. Por otra parte, algunos editores están "quitando los encabezados" de las subsecciones "notas" y "bibliografía" de "referencias", lo que hace que sea menos fácil reciclar fuentes para artículos que utilizan los mismos libros/enlaces web. No creo que mucha gente esté viendo esta página; puede que sea por eso que el cambio se realizó tan fácilmente. Si te parece muy importante, una publicación en WT:AIR podría atraer más atención. Nimbus (Cumulus nimbus flota) 08:52, 12 de julio de 2011 (UTC) [ responder ]
Analicemos por qué no se debería usar la sección en ==Ver también==. En comparación con ==Referencias==, la sección de ===Notas al pie==- y ===Anotaciones=== no es ideal porque idealmente todas las fuentes deberían estar en línea, pero no veo ninguna razón para no seccionar ==Ver también==. Lo publicaré en la página de discusión del wikiproyecto para ver si tienen alguna razón para no seccionar ==Ver también==. Curb Chain ( discusión ) 10:51 12 jul 2011 (UTC) [ responder ]
Además, ¿podrías indicarme la sugerencia sobre cómo ahorrar espacios en blanco? Curb Chain ( discusión ) 10:56 12 jul 2011 (UTC) [ responder ]
Hmm, he notado en la discusión sobre la eliminación de esta plantilla que el nom mencionaba que "esta plantilla no permite la edición libre de la sección "ver también", que es necesaria para cumplir con el MOS. FA no aceptará esto". Estoy proponiendo exactamente y únicamente el cambio a la plantilla para permitir la edición libre, o lo que dije anteriormente, titulares. También he notado arriba en una sección (Template_talk:Aircontent#Whitespace) que se tomaron capturas de pantalla del supuesto espacio en blanco. No tengo ningún problema con el diseño, o con cómo deberían aparecer los enlaces, pero considero que poder dividir estos enlaces en titulares de sección y luego editarlos sería muy útil. Curb Chain ( discusión ) 11:02 12 jul 2011 (UTC) [ responder ]
El uso de la plantilla no es obligatorio, aunque se puede aplicar a miles de artículos sobre aeronaves y motores de aviación. Cualquiera puede crear sus propios encabezados de sección "véase también" ingresándolos manualmente y sin usar la plantilla. Lo ideal sería que fueran los mismos que los sugeridos en Wikipedia:WikiProject Aircraft/page content#See also (que es lo que produce esta plantilla). Nimbus (Cumulus nimbus flotando) 14:19, 12 de julio de 2011 (UTC) [ responder ]
Para responder a la primera pregunta, los encabezados de nivel 3 son superfluos para las pocas entradas que se esperarían en un artículo de tipo "véase también". La creación de subsecciones tiene sentido para navegar en un artículo extenso (el Ministerio de Ciencia y Tecnología dice "Las secciones y subsecciones muy cortas o muy largas en un artículo se ven desordenadas e inhiben el flujo de la prosa" y "Los párrafos cortos y las oraciones individuales generalmente no justifican su propio subtítulo; en tales circunstancias, puede ser preferible utilizar viñetas"), pero el artículo de tipo " véase también " debe ser breve y directo. GraemeLeggett ( discusión ) 15:55 17 jul 2011 (UTC) [ responder ]

Véase también

¿Alguien ha considerado que esta plantilla alienta a los editores a incluir en la sección Ver también contenido que ya puede estar presente en el cuerpo del artículo? Esto entra en conflicto con la directriz WP:SEEALSO , que alienta a los editores a evitar la repetición de enlaces y esforzarse por escribir artículos de alta calidad que normalmente no tienen una sección Ver también por ese motivo. Intenté eliminar los enlaces redundantes en el artículo F-35 , pero esas modificaciones se revirtieron sobre la base de que esta plantilla es un estándar utilizado por WP:AIRCRAFT . Pensé que lo mencionaría aquí. -- GoneIn60 ( discusión ) 02:21, 3 de junio de 2013 (UTC) [ responder ]

Ese es un buen punto. Esta plantilla también ha dado lugar a adiciones nacionalistas de aeronaves no muy comparables en el pasado y muchos de nosotros ya no la añadimos a los nuevos artículos sobre tipos de aeronaves a medida que se crean. - Ahunt ( discusión ) 12:05, 3 de junio de 2013 (UTC) [ responder ]
Lo añado cuando lo considero necesario, pero soy cauto en cuanto a lo que constituye una "similaridad" y elimino los añadidos nacionalistas si los veo. El desarrollo relacionado no siempre se menciona en el artículo fuera del cuadro de información y la Lista de... es generalmente válida. Pero traer el tema a colación aquí es evitar el principal terreno de debate en WP:Aircraft. GraemeLeggett ( discusión ) 18:08 3 jun 2013 (UTC) [ responder ]
Sí, estoy de acuerdo, esto debería debatirse más ampliamente en la discusión de Wikipedia:WikiProject Aircraft . - Ahunt ( discusión ) 19:12 3 jun 2013 (UTC) [ responder ]
El texto de WP:SEEALSO es: Como regla general, la sección "Ver también" no debe repetir enlaces que aparecen en el cuerpo del artículo o en sus cuadros de navegación . No está prohibido repetir enlaces y es criterio editorial si se repiten enlaces importantes donde a veces pueden perderse en un mar de texto. ¿Estamos hablando específicamente de la sección "Ver también" de esta plantilla o de la repetición de tipos de aeronaves en las otras secciones? Algunos lectores (incluido yo mismo) saltan directamente a la sección "Ver también" desde la tabla de contenidos cuando buscan artículos relacionados, omitiendo el texto por completo, en este caso no hay una repetición aparente. Eliminar enlaces relevantes de esta sección sería desmantelar la wiki. Los cuadros de navegación mencionados muy a menudo repiten enlaces (generalmente tipos de aeronaves o motores) utilizados en las secciones "Ver también" de los artículos, esto también rompe la directriz, pero no puedo ver cómo se podría hacer de otra manera sin perder su gran beneficio obvio (¿todos los lectores usan los cuadros de navegación?). Hay artículos destacados con enlaces repetidos en la sección "Ver también", que se aceptan en la revisión de la candidatura cuando el nominador ha explicado por qué están allí. Nimbus (Cumulus nimbus flotando) 21:05, 3 de junio de 2013 (UTC) [ responder ]
Gracias por todos los comentarios. Puedo ver cómo los enlaces pueden ser útiles, particularmente en artículos largos sobre aeronaves y para visitantes que pueden no estar muy familiarizados con los cuadros de navegación. También entiendo que es una "regla general" que no prohíbe explícitamente el acto, aunque yo diría que las excepciones deberían considerarse raras por la forma en que está redactada la directriz (en realidad no describe qué se considera una excepción, solo que existen). Dejaré de lado la preocupación por ahora y la plantearé en el WikiProject principal en caso de que surja la necesidad. ¡Gracias! -- GoneIn60 ( discusión ) 23:01, 3 de junio de 2013 (UTC) [ responder ]

Propuesta

Estoy de acuerdo con GoneIn60 . El problema de que los editores utilicen esta plantilla para repetir enlaces que ya están en el cuerpo no solo es un desafío para SEEALSO, sino también para WP:OVERLINKING . Todos sabemos que los proyectos tienen libertad. Todo bien. Pero... tomemos el ejemplo de Airbus A330neo , que actualmente tiene tres enlaces de Airbus A330 en el cuerpo y un enlace de Airbus A330 de esta plantilla estándar de proyecto. Como el cuadro de información tiene "Desarrollado a partir de Airbus A330 ", es peor que redundante (es menos específico) que esta plantilla diga "Desarrollo relacionado con Airbus A330 ". (y sí, he utilizado cuatro enlaces a Airbus A330 para demostrar mi punto). Mi punto más importante no es ver también/enlace adicional, ya que todos estamos de acuerdo en que esta información parece útil. Como los enlaces tienen estructura, el Ver también ordenado alfabéticamente es una ubicación deficiente (y la plantilla lo soluciona con encabezados en negrita feos). Una estructura semántica es mejor. Entonces, la pregunta es ¿se podría ubicar mejor la información? Candidatos/ejemplos:

El cuadro de información es el candidato obvio, pero en artículos más grandes, un cuadro de navegación de pie de página como un cuadro de sucesión también puede ser útil. La adopción de una coherencia de este tipo en todo el proyecto puede ser más útil para todas las partes y eliminar una carga de mantenimiento de la defensa del proyecto que no va a desaparecer. [1] [2] [3] + otros mencionados anteriormente. ¿Opiniones? Ping Usuario:BilCat , Usuario:Marc Lacoste . Widefox ; discusión 11:39, 16 de septiembre de 2016 (UTC) [ responder ]

Esta plantilla WP:SEEALSO es útil no solo para desarrollos relacionados, sino principalmente para la concurrencia de aeronaves. Para el A330, son todos los aviones de fuselaje ancho modernos, podríamos ir desde el B767 al B747, o incluso los modelos Douglas o rusos que se usan actualmente. Sería demasiado, y los editores se preocupan. Se pueden hacer referencias, por ejemplo: [4]. Es como una plantilla de base para la concurrencia, pero variable para cada modelo.
WP:OVERLINKING establece que un enlace debe aparecer solo una vez en un artículo, pero si es útil para los lectores, un enlace puede repetirse en los cuadros de información, tablas, títulos de imágenes, notas al pie, notas de sombrero y en la primera aparición después del encabezado . En el artículo 330neo, hay un enlace A330 en el encabezado, una vez en la sección *Desarrollo*, al -200 y -300 en *Variantes* (aunque debería ser un enlace profundo), y en *Ver también* como en una nota al pie. Esto cumple con WP:OVERLINKING. No es que estemos abrumados. -- Marc Lacoste ( discusión ) 14:33 16 septiembre 2016 (UTC) [ responder ]
Vale, estoy intentando entender... ¿No es una concurrencia como una versión diferente de un cuadro de sucesión? ¿No sería una concurrencia de todos modos de una fuente, a la que no es posible hacer referencia en un Véase también, pero sí con los candidatos anteriores?
En cuanto a OVERLINK, sí, cuatro no están enviando a nadie a la cárcel (y el cuadro de navegación y los subtítulos no cuentan según WP:CAPTION / sentido común), pero en realidad no ayudan, sino que obstaculizan (ver la investigación en OVERLINK). WP:REPEATLINK "... sólo una vez ..." (énfasis importante). El punto es que hay un presupuesto más limitado con el ver también, pero menos con los candidatos anteriores. Evita el problema. Widefox ; discusión 20:29, 16 de septiembre de 2016 (UTC) [ responder ]
Gracias por plantear el problema aquí, Usuario:Widefox , y por hacer sugerencias constructivas de alternativas. (A menudo, otros usuarios simplemente quieren eliminar los enlaces directamente). No estoy seguro de si un cuadro de sucesión sería realmente útil, y no estoy seguro de cómo funcionaría exactamente un cuadro de navegación con la misma flexibilidad de la sección de enlaces "ver también". Hemos discutido esa solución de pasada antes, pero no pudimos encontrar una solución que funcione. En cuanto al cuadro de información actual en la parte superior de cada artículo, contiene enlaces a variantes y desarrollos relacionados. Sin embargo, dudaría en agregar más enlaces, como para aeronaves comparables, y honestamente eso parece funcionar mejor en la parte inferior de la página. Tenga en cuenta que la plantilla y el formato se utilizan en más de 10,000 artículos de aeronaves y motores, todos los cuales tendrían que actualizarse. Además, la plantilla Aircontent actual está un poco restringida a lo que solía ser, ya que fue creada originalmente por el proyecto Aircraft antes de que se establecieran las pautas MOS actuales sobre las secciones Ver también, o al menos se aplicaran en su forma actual. Estoy de acuerdo en que el método actual puede requerir mucho mantenimiento y ser propenso a conflictos de edición polémicos en algunos casos. - BilCat ( discusión ) 04:50, 17 de septiembre de 2016 (UTC) [ responder ]
Sí, estoy de acuerdo. El avión comparable es un elemento tangencialmente relacionado que tiene una buena posibilidad de no estar ya en el artículo, por lo que Ver también es una ubicación natural. Como se trata de información estructurada y beneficiaría una referencia, en mi humilde opinión, una mejor ubicación es eliminarlo visualmente del Ver también no estructurado y estructurarlo visualmente en un cuadro, digamos a la derecha (comparar con el cuadro de sucesión y , ambos ubicados en la parte inferior). La plantilla podría permanecer en su lugar como las plantillas de portal. Todos los artículos técnicos tienen necesidades similares en esto, solo creo que la aviación está por delante de los demás. Solo un "cuadro de sucesión/comparable" personalizado un poco como un para el estado del campo. No estoy seguro de cuánto trabajo sería... es posible que solo se necesite cambiar la plantilla, tal vez un poco de edición del bot también (para extraer el ver también y tal vez colocar la plantilla más arriba). Parece trivial, pero fácilmente podría estar equivocado. Ya sabes, en mi humilde opinión, esto es inevitable a largo plazo, pero a corto plazo es una fuerza irresistible y un objeto inamovible. Es tu proyecto y eres libre de ignorarme. Te daré un ejemplo similar que encontré... Medicine Project no permitía referencias en las columnas hace un año. La única pregunta es si esto es mucho trabajo , pero si es mejor , y si el cambio se vuelve fácil o más difícil en el futuro . Creo que debería salir en este punto, saludos Widefox ; discusión 12:50, 17 de septiembre de 2016 (UTC) [ responder ]{{Geographic location}}{{Geographic location}}
Eh, un cuadro de información más formal está esperando interminables guerras de edición sobre lo que está bien o mal incluir, y si el espacio es limitado, sería peor. No hay una definición definitiva para una competencia de aeronaves. Por ejemplo, el Piper Malibu Meridian, un turbohélice monomotor presurizado de 6 asientos, compite con el TBM700 y el PC-12, pero es más barato, por lo que compite en costo con los monomotores de turbina no presurizados, pero también en misiones con dos pistones presurizados; también están los modelos más antiguos que ya no se producen y los futuros que aún no se producen, ¡y el Malibu también es un avión de 6 asientos no presurizado con su propia competencia! La forma actual más simple evita demasiadas tonterías. -- Marc Lacoste ( discusión ) 15:47, 22 de septiembre de 2016 (UTC) [ responder ]

Cambiar el marcado de punto y coma a negrita de wikitexto

Actualmente, esta plantilla crea pseudotítulos mediante el uso de un marcado de punto y coma (por ejemplo, ;Related development). No hay nada de malo en usar un pseudotítulo aquí, pero el método de punto y coma viola la norma MOS:PSEUDOHEAD . La razón es que estropea los lectores de pantalla y similares al llamar a listas de descripción. La solución adecuada que ofrece la directriz de accesibilidad es usar el marcado de negrita de wikitexto ( '''Related development'''). Ambos funcionan de manera idéntica con la tabla de contenidos (es decir, estos encabezados no se muestran en la tabla de contenidos). Visualmente son casi imperceptibles:

Desarrollo relacionado

Desarrollo relacionado

Espero que podamos llegar a un consenso sobre este pequeño cambio para poder avisar a los editores de plantillas. –  Finnusertop ( discusión ⋅ contribuciones ) 17:28, 26 de mayo de 2018 (UTC) [ responder ]

Teniendo en cuenta el problema del lector de pantalla, esto tiene sentido. - Ahunt ( discusión ) 02:06, 27 de mayo de 2018 (UTC) [ responder ]

Por favor, cambie esta plantilla para utilizar negrita en lugar de punto y coma para lograr pseudotítulos para los cuatro títulos, según el consenso anterior (por ejemplo, '''Related development'''). –  Finnusertop ( discusión ⋅ contribuciones ) 17:14, 2 de junio de 2018 (UTC) [ responder ]

 Hecho Galobtter ( pingó mió ) 17:29, 2 de junio de 2018 (UTC) [ respuesta ]

MOS:PSEUDOCABEZAviolaciones

Esta plantilla actualmente marca los encabezados en negrita, pero esto no es apropiado para la accesibilidad y la semántica HTML adecuadas. En su lugar, se deben utilizar subtítulos adecuados, emitiendo <h3>etiquetas (que estarían ===en el wikitexto). Opencooper ( discusión ) 19:03, 20 de octubre de 2019 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 12 de octubre de 2021

En WikiProject Aircraft hay consenso en que el marcado eliminado en esta edición no era un pseudoencabezado (punto y coma), sino simplemente negrita. Además, la falta de cualquier tipo de encabezado en la revisión actual le da a la plantilla una sensación extraña, y era mejor así.

Solicito que se revierta esta edición. Si el marcado en negrita causa problemas de accesibilidad para una minoría de dispositivos, seguramente haya una mejor solución que emular esos problemas de accesibilidad en todos los dispositivos. - ZLEA T \ C 15:38, 12 de octubre de 2021 (UTC) [ responder ]

He revertido el cambio. He puesto encabezados de tercer nivel en el sandbox. Echa un vistazo a Template:Aircontent/testcases para ver la diferencia. Si la plantilla siempre está precedida por un encabezado "Ver también" de segundo nivel, entonces los encabezados de tercer nivel tienen sentido dentro de la plantilla. Se mostrarán un poco más grandes y aparecerán en la tabla de contenidos del artículo. – Jonesey95 ( discusión ) 17:11, 12 de octubre de 2021 (UTC) [ responder ]
Realmente no sé qué decir sobre el uso de encabezados verdaderos. Una parte de mí quiere decir que tiene sentido, pero otra parte dice que Ericg eligió no usar encabezados por alguna razón, y que los encabezados más grandes dominan las listas y me distraen un poco (pero esa es solo mi opinión). Como Ericg no ha editado en casi un año, le preguntaré a BilCat , Ahunt , Steelpillow y Nimbus227 (los usuarios involucrados en la discusión) qué piensan. - ZLEA T \ C 22:07, 12 de octubre de 2021 (UTC) [ responder ]
No creo que necesitemos encabezados verdaderos, ya que harían que la tabla de contenidos fuera demasiado larga en muchos artículos sobre aeronaves. Pero si a los demás usuarios les parece bien, respeto ese consenso. BilCat ( discusión ) 22:48 12 oct 2021 (UTC) [ responder ]
Estoy de acuerdo, no necesitamos encabezados verdaderos en la plantilla, porque no los necesitamos en la tabla de contenidos, el uso de negrita es una solución superior. - Ahunt ( discusión ) 23:09, 12 de octubre de 2021 (UTC) [ responder ]
Para que conste, no tengo ninguna opinión sobre este asunto. Solo soy un editor de plantillas que fue convocado aquí por la solicitud de edición. – Jonesey95 ( discusión ) 02:46, 13 de octubre de 2021 (UTC) [ responder ]
Por favor, vuelva a la última versión estable. Nimbus (Cumulus nimbus flota) 09:14, 13 de octubre de 2021 (UTC) [ responder ]
¿No se ha hecho ya esto? — Saludos, Steelpillow ( Discusión ) 13:30 13 oct 2021 (UTC) [ responder ]

Representando la semántica

Existe una clara distinción entre un encabezado de sección ( representado por los elementos HTML h1, h2,...) por un lado y un encabezado localizado, por ejemplo, para una columna de tabla (th) o un nombre o término de lista de descripción (dt). Todos estos elementos se resaltan en negrita en Wikipedia; vea aquí arriba el h3 en acción, y los otros ejemplos son:

Término de lista de descripción
Se utiliza a menudo para preguntas frecuentes y, por aquí, a veces para variantes de aeronaves, etc.

Estas distinciones son perfectamente inteligibles para las herramientas de accesibilidad, como los lectores de pantalla. Un pseudoencabezado es cuando alguien estropea la semántica al utilizar un término de una lista de descripción como encabezado de subsección, que no es lo que estamos haciendo aquí. El texto simple en negrita no tiene semántica implícita, lo que claramente tampoco resulta útil para el lector de pantalla.

Lo que queremos hacer es, en esencia, anidar listas con viñetas (ul) dentro de una lista de descripción (dl). Esto se puede hacer insertando cada ul como el contenido de un valor de descripción (dd). Esto funciona perfectamente bien en mi navegador web compatible con estándares y debería funcionar igualmente bien en cualquier herramienta de accesibilidad. Lograr esto en Wiktext debe codificarse con bastante precisión:

;Término:*tonto:*bar;Otro término:*voilá

Lo que produce el código html apropiado (copiado y pegado después de ser servido por Wikipedia):

<dl><dt>Término</dt><dd><ul><li>foo</li><li>barra</li></ul></dd></dl><dl><dt>Otro término</dt><dd><ul><li>listo</li></ul></dd></dl>

Lo cual se traduce como:

Término
  • comida
  • bar
Otro término
  • listo

¿Puedo sugerir que modifiquemos la plantilla en consecuencia? — Saludos, Steelpillow ( Discusión ) 07:48, 13 de octubre de 2021 (UTC) [ responder ]

El sandbox está disponible para experimentación. No estoy seguro de cómo las 9000 transclusiones existentes serían compatibles con la propuesta anterior, y no veo cómo, semánticamente, estas listas desordenadas serían listas de descripción (pero no soy un experto en semántica HTML). – Jonesey95 ( discusión ) 14:41, 13 de octubre de 2021 (UTC) [ responder ]
El truco técnico aquí se llama anidación. Cada lista desordenada se coloca (anida) dentro de un elemento de lista de descripción, específicamente dentro de su contenedor dd. La estructura se vuelve más clara si el código se sangra de la manera convencional:
<dl> <dt>Término</dt> <dd> <ul> <li>foo</li> <li>barra</li> </ul> </dd></dl><dl> <dt>Otro término</dt> <dd> <ul> <li>voilá</li> </ul> </dd></dl>
En realidad, esto también demuestra que el analizador de wikitexto carece de precisión y trata el ejemplo como dos listas de descripciones consecutivas, cada una con una sola entrada. Pero logra que la semántica anidada sea correcta, por lo que eso no preocuparía a los lectores de pantalla.
Existe un marcado un poco más simple que se puede utilizar si no se quieren viñetas y la sangría por sí sola es suficiente. De cualquier manera, no sería necesario cambiar el marcado de la página existente, en ninguna de esas 9000 páginas, y la visualización sería efectivamente la misma que en la actualidad; solo es necesario modificar la plantilla para que su código de salida sea semánticamente compatible, como se indica más arriba. — Saludos, Steelpillow ( Discusión ) 16:04, 13 de octubre de 2021 (UTC) [ responder ]
Mmm. Según WP:TEMPLATE , parece que la única forma de implementar esto sin romper las listas existentes es anteponer cada una *con :, as :*, antes de renderizarla en html. En teoría, esto se podría hacer usando la #invokefunción para llamar a un módulo Lua. Eso está fuera de mi zona de confort, pero intentaré seguirlo. — Saludos, Steelpillow ( Discusión ) 13:13, 14 de octubre de 2021 (UTC) [ responder ]
De ahí mi comentario anterior ( no estoy seguro de cómo... ). Puede que haya una forma de hacerlo, pero aún no la veo. – Jonesey95 ( discusión ) 13:42, 14 de octubre de 2021 (UTC) [ responder ]
Hay un módulo llamado String que puede realizar búsquedas y reemplazos. La plantilla contendría algo como esto:
#invoke:String|replace|[marcado de origen]|*|:*
pero necesitaría comprobar cómo pasa el texto a la llamada de función y cómo tanto el wikitext como la propia función manejan los saltos de línea. La documentación del módulo insinúa oscuramente expresiones regulares. Alegría, oh alegría sin límites, como solía decir Stanley Unwin . — Saludos, Steelpillow ( Discusión ) 17:37, 14 de octubre de 2021 (UTC) [ responder ]

¡Vaya! Parece que funciona. Lo he codificado en Template:Aircontent/sandbox . Sin embargo, sangra un poco más las listas con viñetas; esa es una consecuencia inevitable de anidar listas aquí. Ver Template:Aircontent/testcases#Testing sandbox version . Perdón por ser tan técnico, ¿alguien ha podido mantenerse despierto aquí? — Saludos, Steelpillow ( Discusión ) 19:05, 14 de octubre de 2021 (UTC) [ responder ]

Inteligente. Tenemos que comprobar que el asterisco esté al principio de la línea y reemplazarlo solo en esos casos. Consulta la página de casos de prueba. Aparte de eso, creo que podría funcionar. [Actualización: creo que lo he solucionado. Sería útil tener algunos casos de prueba reales adicionales, cuanto más extraños, mejor, de artículos reales.] – Jonesey95 ( discusión ) 19:35, 14 de octubre de 2021 (UTC) [ responder ]
Tu corrección ha cambiado la semántica de la lista html. El html alterna los encabezados de la lista de descripción con listas con viñetas, no hay anidación. Este uso de los encabezados de la lista de descripción (wikitext punto y coma ";" ) es exactamente lo que prohíbe WP:PSEUDOHEAD . Probé una expresión regular en su lugar y eso no solucionó el html. No tengo idea de por qué el analizador no logra anidar ninguna de las correcciones. Por otro lado, agregué algunos asteriscos en línea a los casos de prueba y mi código anidado lo estropea al agregar dos puntos, por lo que esa tampoco es una solución viable. El texto en negrita actual es el marcado preferido para un pseudoencabezado, por lo que si queremos solucionar el problema de accesibilidad, una opción podría ser pasar a una introducción de texto simple más parecida a una oración a cada lista con viñetas. Así que lo agregué como un tercer ejemplo de prueba. — Saludos, Steelpillow ( Discusión ) 09:42, 15 de octubre de 2021 (UTC) [ responder ]
Tienes razón. Lo he mejorado un poco ahora, pero aún no lo he solucionado. – Jonesey95 ( discusión ) 12:33, 15 de octubre de 2021 (UTC) [ responder ]
Algo extraño está pasando con el analizador/conversor de mediawiki, la extensión parserfunctions, el módulo String y/o la forma en que Lua maneja las expresiones regulares. Uno tiene que preguntarse por qué " find \n* and replace with \n:* " se comporta de manera diferente como separador de elementos de lista que " find * and replace with :* ". Francamente, ya no me importa un carajo lo que sea (File System cheCK); estoy empezando a apreciar la sabiduría del marcado simple-bold actual. — Saludos, Steelpillow ( Discusión ) 17:59, 15 de octubre de 2021 (UTC) [ responder ]