stringtranslate.com

Discusión de plantilla: Especificaciones de la aeronave

Hacer

En función del uso que se haga en los artículos, se deberían corregir o actualizar los siguientes elementos:

Anteriormente se utilizaba la plantilla:Aerospecs
Anteriormente se utilizaba la plantilla:Especificaciones de aeronaves

Para actualizar

Actualmente no hay ninguna plantilla de especificaciones

Categoría:Aeronaves sin especificaciones adecuadas

Actualmente se utiliza la plantilla:Aerospecs
Actualmente se utiliza la plantilla:Especificaciones de la aeronave

Discusión sobre fusiones de plantillas, un bot y una posible nueva funcionalidad para esta plantilla

Hay una discusión sobre esta plantilla en Wikipedia talk:WikiProject Aircraft#Template:Aircraft specs merger bot De particular preocupación para esta plantilla es cómo manejar la información de carga útil y peso cargado de {{ Especificaciones de la aeronave }}, lo que puede implicar agregar nuevos campos a esta plantilla y cambiar el sistema de conversión para no realizar conversiones automáticas para unidades donde se proporciona un valor manualmente. -- Trialpears ( discusión ) 15:50, 8 de agosto de 2019 (UTC) [ responder ]

Cambios en las subpáginas de conversión para evitar conversiones innecesarias

He realizado cambios en las subpáginas de conversión Template:Aircraft specs/convert/sandbox , Template:Aircraft specs/eng/sandbox , Template:Aircraft specs/length/sandbox , Template:Aircraft specs/range/sandbox y Template:Aircraft specs/speed/sandbox que hacen uso de parámetros de unidad adicionales si se proporcionan, en lugar de convertirlos desde otra unidad. Esto se hace principalmente para evitar conversiones de unidades adicionales al convertir instancias de {{ aircraft specs }} a esta plantilla, lo que reduce la precisión de nuestros valores. También será útil para anular la conversión cuando muestre la cantidad incorrecta de cifras significativas. Consulte también las discusiones en Wikipedia talk:WikiProject Aircraft#Template:Aircraft specs merger bot y Wikipedia:Templates for discussion/Log/2019 March 20#Template:Aerospecs .

He probado todas las funciones de estas plantillas, tanto las nuevas como las antiguas, y no he encontrado ningún problema. Los casos de prueba funcionan y la nueva funcionalidad funciona correctamente en las conversiones de prueba de {{ Especificaciones de la aeronave }} . Las plantillas de conversión de velocidad y alcance parecen comportarse de manera extraña, ya que los paréntesis no se muestran de la misma manera que las otras plantillas, por lo que he hecho que el formato sea coherente con las otras plantillas. Si su formato actual (como se ve en los casos de prueba) fue intencional, con gusto volveré a ese. -- Trialpears ( discusión ) 12:12, 10 de agosto de 2019 (UTC) [ responder ]

No está terminado por ahora: hay una serie de "necesidades de un número" que aparecen en los primeros casos de prueba en Template:Aircraft specs/sandbox . ¿Son intencionales? Izno ( discusión ) 17:52, 18 de agosto de 2019 (UTC) [ responder ]
Izno No. Eso se debe a un error de copiar y pegar que ya está solucionado. He realizado algunas pruebas más para estar seguro y no he encontrado más problemas. -- Trialpears ( discusión ) 18:11, 18 de agosto de 2019 (UTC) [ responder ]
Done Izno ( discusión ) 22:33 25 ago 2019 (UTC) [ responder ]

@Trialpears : Algunos artículos están en la categoría:Errores de conversión . Lo siento, no tengo tiempo en este momento para investigar los cambios recientes, pero espero que alguien sepa cómo manejar el problema. No hay problema. Sé que es difícil predecir cómo se usan las plantillas y no importa si los artículos son imperfectos durante un día o dos mientras se encuentran los factores comunes. Intentaré volver en unas horas y ver si algún truco con la conversión podría ayudar. Johnuniq ( discusión ) 05:34, 26 de agosto de 2019 (UTC) [ responder ]

Johnuniq Espero que se solucione en el entorno sandbox, pero no puedo probarlo más desde que comienzan las clases. -- Trialpears ( discusión ) 05:55, 26 de agosto de 2019 (UTC) [ responder ]
Sincronice los entornos de prueba {{ Aircraft specs/length }} y {{ Aircraft specs/eng }} . Ahora se encarga de casos extremos que no están presentes en los casos de prueba y debería solucionar la mayoría de los errores de conversión. -- Trialpears ( discusión ) 09:49, 26 de agosto de 2019 (UTC) [ responder ]
@Trialpears : Listo, gracias , funciona mucho mejor. Verifique los errores de conversión de Categoría para ver si quedan algunos problemas. Observé estos:
  • En Famà Kiss 209 , ceiling m=3100da error de conversión El valor "exterior" debe ser un número .
  • En MAI-223 , ceiling m=5500da un error de conversión El valor "servicio" debe ser un número .
  • He corregido un texto wiki en Martin Jetpack y ya no muestra un error. Sin embargo, muestra "Performanceat 152 m" sin espacio antes de "at". ¿Cómo se supone que funciona?
Johnuniq ( discusión ) 10:33 26 ago 2019 (UTC) [ responder ]
Johnuniq ¡ Todos los errores ya están corregidos, gracias a Nigel Ish por su ayuda! Los errores "Value X must be a number" se debían a que las palabras outside o service estaban en un parámetro numérico. El error Martin Jetpack se debía a que se usaba una nota de velocidad de crucero sin una velocidad de crucero. -- Trialpears ( discusión ) 12:07, 26 de agosto de 2019 (UTC) [ responder ]
Algunos se debieron al uso de caracteres fraccionarios en lugar de caracteres de marcado. Nigel Ish ( discusión ) 12:14 26 ago 2019 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 31 de agosto de 2019

Actualmente, en todos los parámetros de velocidad de met se muestra "km" en lugar de "km/h", lo cual no es correcto. Lo he intentado en una edición de sandbox, pero obviamente no estoy haciendo lo que se necesita. ¿Alguien puede ayudar? Petebutt ( discusión ) 16:42 31 ago 2019 (UTC) [ responder ]

Petebutt ¿Puedes darme un artículo de ejemplo en el que se produzca este problema? -- Trialpears ( discusión ) 16:54, 31 de agosto de 2019 (UTC) [ responder ]
Pilatus PC-9 es uno de ellos, básicamente cualquier artículo en el que |prime units?=met . Parece estar presente en todos los ejemplos del sandbox /speed, así que no sé si eso rompió la plantilla. Nigel Ish ( discusión ) 17:03 31 ago 2019 (UTC) [ responder ]
Marinens Flyvebaatfabrikk MF11 - Petebutt ( discusión ) 17:05, 31 de agosto de 2019 (UTC) [ respuesta ]
Se solucionó el problema en el sandbox de /speed. Ahora solo se debe sincronizar con un editor de plantillas. ¡Gracias por decírmelo! -- Trialpears ( discusión ) 17:50, 31 de agosto de 2019 (UTC) [ responder ]
 Done Izno ( discusión ) 01:41 1 sep 2019 (UTC) [ responder ]

Error de alcance y ambigüedad del motor

Mientras estamos aquí, he encontrado el peor error hasta ahora: ocultar el rango si se usa kts como unidad principal, ya que estaba buscando NMI (configuré mis casos de prueba bajo la misma suposición incorrecta). Corrección en la zona protegida. -- Trialpears ( discusión ) 13:55, 1 de septiembre de 2019 (UTC) [ responder ]

También hubo un problema con la interacción entre en-kw y en-shp, que ahora se solucionó en el entorno de pruebas. -- Trialpears ( discusión ) 22:47 1 septiembre 2019 (UTC) [ responder ]
 Done Izno ( discusión ) 23:23 1 sep 2019 (UTC) [ responder ]

¿Planta motriz?

Para Cierva C.6#Especificaciones (C.6) y todas las demás, Powerplant parece extraño. Sería difícil colocar un motor en cualquier avión. Plantilla:Especificaciones de aeronaves/doc#motores. ¿Podría ser posible cambiar la salida de " |eng name=" a engine ?
Peter Horn Discusión de usuario 02:13, 23 de octubre de 2019 (UTC) [ responder ]

Ups, Powerplant redirige a propulsión y no debe confundirse con power plant . Peter Horn Discusión de usuario 02:25, 23 de octubre de 2019 (UTC) [ responder ]

¿Añadir sugerencia sobre el formato de |más entradas?

Descubrí que tenía que aplicar mi propio formato al agregar una |moreentrada. Si eso es cierto y se acepta como una buena práctica, entonces podría valer la pena mencionarlo en los documentos. En otras palabras, solo digo

|más general=Portavasos: 2

no funciona, tienes que decir algo como

|más general=<br>*'''Portavasos:''' 3<br>*'''Faros antiniebla:''' 2

para que se renderice correctamente. (Para mí fue el artículo de Ford Trimotor , pero creo que se aplicaría en general). ¡Gracias! 73.3.56.178 (discusión) 05:58, 7 de julio de 2020 (UTC) [ responder ]

Subsección "Rendimiento" rota @Junkers Ju 390

Así es como se ve ahora la subsección "Rendimiento" en el Junkers Ju 390 (al menos para mí):

Rendimiento a [ sic ] 6.200 m (20.340 pies) a [ sic ] 2.500 m (8.200 pies)
Alcance : 8.000 km (4.970 mi, 4.320 nmi) Ju 390 V1 con 10.000 kg (22.046 lb) de carga útil y 34.096 l (9.007 galones estadounidenses; 7.500 galones imperiales) de combustible a 330 km/h (210 mph; 180 nudos) y 2.000 m (6.500 pies)
Alcance de combate : 9.704 km (6.030 mi, 5.240 nmi) (misión de reconocimiento)
Alcance de combate (misión de bombardero) : 9.254 km (5.750 mi; 4.997 nmi) con Carga de bombas de 1.930 kg (4.255 lb)

Además, las siguientes líneas de datos de plantilla reales son invisibles en el artículo en sí:
|velocidad máxima km/h=505
|velocidad máxima nota=at {{cvt|20340|ft|order=flip}}
|velocidad de crucero km/h=357
|velocidad de crucero nota=at {{cvt|8200|ft|order=flip}}

No he notado este problema en particular en ningún otro artículo. Las formas de usar las plantillas suelen ser un misterio para mí, pero realmente no tengo idea de por qué:

Supongo que hay un error extraño en la codificación de la plantilla en sí y/o algo relacionado con la forma en que se ingresaron estos datos.
(También publicado en Talk:Junkers Ju 390 .)

Grant | Discusión 03:55, 28 de febrero de 2020 (UTC) [ responder ]

Ya arreglado, gracias Usuario:Nigel Ish .
Grant | Discusión 02:39, 29 de febrero de 2020 (UTC) [ responder ]

Formateo de potencia con y sin recalentamiento

El empuje y el empuje del postquemador no tienen el mismo formato que las plantillas anteriores. En lugar de estar en forma de viñetas debajo del motor, aparece una oración parcial (desordenada). GraemeLeggett ( discusión ) 15:57 28 feb 2020 (UTC) [ responder ]

Algunas adiciones/ajustes que me gustaría ver

Puedo apoyar la capacidad de aceite (¿siguiendo la capacidad de combustible en la presentación?), el PS como una opción (pero no como opción predeterminada), la velocidad de aterrizaje, pero la pista del tren de aterrizaje es un paso demasiado lejos en mi opinión; no podemos incluir todo y el manejo en tierra debería describirse en el texto del artículo, ya que el diseñador puede haber mitigado o incluido aún más la pista que se utilizó. Y es probable que haya algunos aviones con un tren de aterrizaje inusual para el cual la pista no se puede proporcionar como una dimensión sencilla; si algo he aprendido con los aviones es que hay muchos casos extremos.
Creo que la capacidad de combustible puede dejarse mejor como un campo de formato libre, la capacidad de combustible en las fuentes parece venir a menudo con calificadores o vaguedades que requieren que uno ponga, por ejemplo, "15 litros (3,3 galones imperiales) con una reserva adicional de 15 minutos" o "250 galones estadounidenses (950 L) con un 30 galones estadounidenses (110 L) opcional instalado", y hay una plantilla que hace conversiones con bastante facilidad. GraemeLeggett ( discusión ) 11:19, 27 de marzo de 2020 (UTC) [ responder ]
Solo una pequeña cantidad de aeronaves necesitarían la potencia en PS, y solo como un campo para ingresar en lugar de usar hp o kw, no como un número adicional para mostrar, ya que no es una unidad común en inglés. Las fuentes de ciertas épocas y países solo brindan la potencia en PS, lo que nos deja en la incómoda posición de tener que convertir (incluso si solo es de 1 a 2), solo para ingresarla en un campo, o usar una fuente posterior, menos precisa o completa para ese número. Es más un ejercicio de contabilidad, al igual que por qué no permitimos conversiones manuales en otros lugares.
Hablando de eso, ¿hay alguna razón por la que no podamos calcular automáticamente la carga alar y la carga de potencia a partir de los campos correspondientes? Creo que parece ser común encontrar estos números solo para las variantes más desconocidas, y no para la que se necesita para la sección, por lo que generalmente terminan dejándose vacíos.
El mejor lugar para la capacidad de aceite es justo después del combustible. ¿Por qué no un campo adicional para el combustible como el campo de notas que se usa en todos los parámetros de rendimiento para las cosas raras? Los casos raros no deberían dominar la discusión cuando pueden caber en un campo de notas, y rompe la coherencia, ya que diferentes personas pueden ingresar los datos de diferentes maneras. No veo por qué este campo debería ser la excepción a lo que funciona bien para todos los demás campos donde esto es un problema. Divídalo en |capacidad de combustible L= |capacidad de combustible impgal= |capacidad de combustible USgal= y |capacidad de combustible notas= donde el último cubrirá esos tanques de reserva de 15 minutos y cualquier otra cosa extraña que surja (como el combustible externo).
La pista no es tan importante con un 737 como lo es con un Buhl. He estado trabajando en muchos aviones estadounidenses del año 30 recientemente y todos tienen la pista de rueda provista en las especificaciones y por la razón que sugerí. Ya tenemos un montón de campos opcionales, por lo que uno más no nos costará un ojo de la cara. - NiD.29 ( discusión ) 13:49, 27 de marzo de 2020 (UTC) [ responder ]

Número de pala de la hélice

¿Debería ser realmente necesario el número de pala de la hélice para mostrar cualquier información sobre la hélice? Creo que debería ser opcional. -- Trialpears ( discusión ) 12:07, 24 de junio de 2020 (UTC) [ responder ]

Probablemente no debería ser necesario, pero no veo ningún problema porque esa es generalmente la única información que se conoce sobre una hélice. - ZLEA T \ C 12:36, 24 de junio de 2020 (UTC) [ responder ]
Suele ser así, pero he visto algunos casos en los que ha sido un problema al convertir plantillas de especificaciones de aeronaves. Por ejemplo, hubo algunos aviones muy antiguos en los que el material y el fabricante de la hélice eran constantes, pero probaron varios tipos de hélices y números de palas y casos en los que la información de la hélice se completó por completo, pero no se mostró nada porque no usaron ese parámetro. Como no veo ninguna desventaja, estas pequeñas ventajas justifican este pequeño cambio. -- Trialpears ( discusión ) 13:20, 24 de junio de 2020 (UTC) [ responder ]
No tengo objeciones al cambio. - ZLEA T \ C 17:12, 24 de junio de 2020 (UTC) [ responder ]

Perfil del ala

He estado trabajando en la conversión de {{ Aerospecs }} a {{ Aircraft specs }} y la mayoría de los casos restantes (455 de ellos) utilizan un parámetro de perfil de ala. Creo que esto debería agregarse aquí, pero quiero asegurarme de que haya consenso antes de hacerlo. -- Trialpears ( discusión ) 21:53, 24 de julio de 2020 (UTC) [ responder ]

Trialpears El parámetro equivalente en la plantilla:Especificaciones de la aeronave es "perfil aerodinámico". - ZLEA T \ C 23:01, 24 de julio de 2020 (UTC) [ responder ]
Gracias. Me siento un poco estúpido ahora... -- Trialpears ( discusión ) 23:09 24 jul 2020 (UTC) [ responder ]
No, me llevó un tiempo darme cuenta por mí mismo. - ZLEA T \ C 23:12, 24 de julio de 2020 (UTC) [ responder ]

Limitar la conversión de decimales

En el artículo de GAF Jindivik , las dimensiones métricas convertidas actuales muestran hasta cinco decimales, esto es una precisión falsa , está tratando de convertir pasos de 1/8 de pulgada, lo que en sí mismo es una tontería, pero si eso es lo que dice la fuente, entonces tiene que serlo.

No estoy autorizado a editar esta plantilla, de lo contrario lo haría yo mismo. Recomiendo revisar todos los ajustes de decimales en toda la plantilla para comprobar la coherencia y, además, recomendaría limitar la cantidad de decimales a dos para todos los parámetros, a menos que haya una buena razón para hacer lo contrario. Nimbus (Cumulus nimbus flota) 12:45, 16 de agosto de 2020 (UTC) [ responder ]

Estoy de acuerdo en que parece una tontería, pero no estoy convencido de que las medidas sean correctas de todos modos. Otras fuentes, por ejemplo, dicen que la altura es de 8 pies y 6 pulgadas cuando está en un carrito, y la longitud de 23 pies y 4 pulgadas. Tal vez si tuviéramos medidas imperiales más sensatas, podría ayudar. MilborneOne ( discusión ) 13:01, 16 de agosto de 2020 (UTC) [ responder ]
Probablemente sea cierto, volví a revisar el artículo en busca de vandalismo, pero parecen ser valores ingresados ​​​​genuinos. Iba a tomarme la libertad de redondearlos a la pulgada más cercana, pero alguien me habría dado una bofetada. De todos modos, se debe revisar la codificación de la plantilla, ya tenemos suficientes problemas con los editores que crean su propia precisión falsa usando calculadoras. Nimbus (Cumulus nimbus flota) 18:20, 16 de agosto de 2020 (UTC) [ responder ]
La trama se complica, parece que los aviones australianos usan unidades métricas primarias (conducen usando kilómetros, otros artículos de la wiki sobre aviones australianos usan primero el sistema métrico). Tengo el directorio Jane's 82-83 que tiene las unidades métricas primero para el Jindivik. Supongo que alguien ingresó valores imperiales convertidos que luego se convirtieron nuevamente al sistema métrico original con errores compuestos. Intentaré resolver ese artículo en particular. Nimbus (Cumulus nimbus flota) 18:44, 16 de agosto de 2020 (UTC) [ responder ]
Para ser justos con la plantilla, en la codificación dice que hay que elegir met o imp para aeronaves estadounidenses o británicas, y met para todas las demás (que incluirían a Australia). Está convirtiendo el techo a 57.005 pies, lo que implica que el valor original era imperial. Nimbus (Cumulus nimbus flotando) 19:24, 16 de agosto de 2020 (UTC) [ responder ]
Se han corregido las conversiones demasiado precisas añadiendo las cifras alternativas de origen de forma manual. Al menos, el artículo de Jindivik está contento. Nimbus (Cumulus nimbus flota) 19:31, 16 de agosto de 2020 (UTC) [ responder ]
Una solución alternativa para las fracciones de pulgadas que evita los valores realmente absurdos es ingresar las fracciones como fracciones (es decir, |length in=1=1/8) esto lo limita a 3 decimales; por supuesto, algún tipo de límite sería bueno. Nigel Ish ( discusión ) 19:37, 16 de agosto de 2020 (UTC) [ responder ]
Gracias. Tengo la sensación de que las secciones de especificaciones no se están revisando para detectar rarezas después de la conversión a esta plantilla. Ahora entiendo mejor cómo funciona, así que debería poder corregir aquellas para las que tengo una fuente al menos. Nimbus (Cumulus nimbus flota) 19:41, 16 de agosto de 2020 (UTC) [ responder ]
Acabo de ajustar la conversión de longitud en Grumman TBM Avenger , era 12,19518 metros. Seguramente hay un problema en la plantilla. Nimbus (Cumulus nimbus flotando) 20:30, 5 de diciembre de 2020 (UTC) [ responder ]
Lo mismo ocurre con Douglas A-20 Havoc . Tengo la sensación de que hay muchísimos más como este. La plantilla no parece capaz de manejar fracciones decimales de pulgadas de forma sensata. He probado varias formas en un entorno limitado. No hay ninguna guía en la documentación (busqué la palabra "fracción"). Nimbus (Cumulus nimbus flota) 21:06, 5 de diciembre de 2020 (UTC) [ responder ]

La conversión se realiza mediante {{ convert }} . No he examinado Template:Aircraft specs/convert pero convert arroja los siguientes resultados ( {{ cvt }} se convierte con |abbr=on):

Cuando se le da a Convert una longitud de 40 pies y 1/8 de pulgada, calcula la precisión de salida necesaria para mostrar ± 1 ⁄ 16  de pulgada. Si las pulgadas son 0,125, la precisión es ± 0,0005 m con un poco más que generalmente funciona bien, aunque no en este caso. En cualquier caso, consulte esta edición en Grumman TBF Avenger . Eso muestra 12,195 m, que es una precisión técnicamente correcta, pero posiblemente más de lo deseado. Para obtener 12,2 m, la plantilla necesitaría, pero eso es complicado porque siempre daría 3 cifras significativas que podrían no ser apropiadas en algunos casos. Johnuniq ( discusión ) 22:42, 5 de diciembre de 2020 (UTC) [ responder ]|sigfig=3

Soy consciente de que la plantilla utiliza una forma de tl:convert, necesita edición y prueba para llegar a una función enciclopédica. La raíz del problema es que está convirtiendo fracciones de una pulgada a metros (las pulgadas normalmente se convertirían a su equivalente métrico de centímetros, las fracciones de pulgadas normalmente se convertirían a milímetros) por lo que 0,125 o 1/8 de pulgada da un resultado de 0,00318 metros (donde 3,2 mm sería sensato). Es normal convertir pies y pulgadas a solo metros (con un punto decimal) no metros y centímetros o metros y milímetros, por lo que se debe utilizar algún tipo de redondeo, sugeriría nuevamente limitar el resultado a dos decimales (de un metro) que sigue la práctica de la prensa de aviación (Jane's, etc.). Si esto no se puede lograr, entonces necesitaremos editar las secciones de especificaciones manualmente agregando el otro parámetro de unidad como solíamos hacer.
Verifiqué la función al revés (met a imp) y funciona, redondea una entrada de metros con dos decimales a pies y pulgadas enteras. Nimbus (Cumulus nimbus flota) 11:14, 6 de diciembre de 2020 (UTC) [ responder ]
Podríamos hacer algo como esto, donde tenemos la opción de especificar la sigfig para cualquier medida, pero usar la predeterminada cuando no se especifica. Solo necesitaríamos implementar esta sigfig en las subplantillas. Frietjes ( discusión ) 00:32, 8 de diciembre de 2020 (UTC) [ responder ]
Adelante, por favor. Probablemente necesitemos una nota sobre cómo ingresar fracciones imperiales en la página de documentación (¿1/8 o 0,125 o cualquiera de los dos?) una vez que se realicen los cambios. Nimbus (Cumulus nimbus flota) 06:39, 8 de diciembre de 2020 (UTC) [ responder ]
Implementé algo y comencé a documentar algo en esta sección . Otros consejos, incluidas las fracciones, pueden ser útiles. Además, las distintas subplantillas de conversión son bastante complicadas y traté de evitar agregar el parámetro sigfig a las unidades no convertidas (es decir, los valores de entrada). Es posible que me haya perdido algo o haya agregado algo donde no debería haberlo hecho, así que avíseme si ve algún comportamiento extraño. Lo que hice no debería tener ningún impacto si no usa uno de los distintos parámetros sigfig. Frietjes ( discusión ) 18:40, 9 de diciembre de 2020 (UTC) [ responder ]
Muchas gracias, veo que has puesto mucho empeño en esto. ¿Se corregirán los cambios retrospectivamente? Estoy mirando la longitud del Douglas A-20 Havoc , que actualmente es de 14,62723 metros. He purgado la caché. Saludos. Nimbus (Cumulus nimbus flotando) 18:53, 9 de diciembre de 2020 (UTC) [ responder ]
Nimbus227 , lo arreglé para ti según esta sección de la documentación. ¿Una idea sería limitar el número máximo de sigfigs a 4? ¿O tal vez rastrear páginas con más de 4 sigfigs? ¡Gracias! Plastikspork ―Œ (discusión) 16:15 12 dic 2020 (UTC) [ responder ]
Gracias, ahora entiendo cómo se supone que se debe usar (esperaba que la plantilla lo manejara automáticamente). ¿Podemos rastrear artículos con más de 4 sigfigs? Saludos Nimbus (Cumulus nimbus flota) 16:17, 12 de diciembre de 2020 (UTC) [ responder ]

Problemas con el número de Mach

|max speed mach= no parece funcionar cuando se usa |max speed note=. Nigel Ish ( discusión ) 19:24 19 ago 2020 (UTC) [ responder ]

Además, esto podría mejorarse con la capacidad de sumar números de Mach a la velocidad de crucero y nunca superar la velocidad (en particular, la velocidad de crucero). Nigel Ish ( discusión ) 19:52 19 ago 2020 (UTC) [ responder ]

Convenciones masivas sobre aviones eléctricos

¿Existe una convención establecida para tratar las masas de los aviones eléctricos? En mi opinión, debería ser: MTOW (o peso bruto), que comprende la carga útil, la capacidad de combustible proporciona detalles de la batería, luego el peso en vacío es MTOW - carga útil - batería. Sin embargo, he visto algunos artículos que indican el peso en vacío incluyendo las baterías. ¿Existe una convención establecida? Y, si no, propongo lo anterior. GEbb4 ( discusión ) 21:51, 14 de febrero de 2021 (UTC) [ responder ]

Tendremos que basarnos en lo que utilicen las fuentes y el uso puede variar en comparación con los aviones de combustible líquido, ya que puede haber menos posibilidades de intercambiar el peso del combustible por la carga útil/rendimiento; el avión puede tener siempre un conjunto completo de baterías, que pueden no ser extraíbles. Nigel Ish ( discusión ) 08:46, 17 de marzo de 2021 (UTC) [ responder ]

Si no se indica el tipo de motor, el formato se altera debido a un espacio en blanco innecesario.

Creo que sé una solución, pero no quieres que te ayude. -- 84.189.92.195 (discusión) 23:23 11 mar 2021 (UTC) [ responder ]

No sé qué página tendría un campo vacío allí. Si tiene motor, al menos debería decir el tipo de motor. En cuanto a los planeadores, se podría usar "ninguno", o un , o eliminar esas líneas por completo. ¿Podrías darme un ejemplo? Miré la página de aeronaves en tu historial de edición y solo tiene el espacio normal entre esa sección y la siguiente. - NiD.29 ( discusión ) 23:45, 11 de marzo de 2021 (UTC) [ responder ]

El tramo barrido está roto

La envergadura en flecha se muestra como una envergadura menor; esto no funciona como se requiere; consulte General Dynamics F-111 Aardvark . Nigel Ish ( discusión ) 21:15 29 jun 2021 (UTC) [ responder ]

¿Alguien puede solucionar esto? Nigel Ish ( discusión ) 17:52 13 ago 2021 (UTC) [ responder ]
Nigel Ish Lo he arreglado en el sandbox, ver caso de prueba . Ahora tenemos que esperar a que un editor de plantillas actualice la plantilla principal. - ZLEA T \ C 19:07, 13 de agosto de 2021 (UTC) [ responder ]
Se agregó una solicitud de edición. - ZLEA T \ C 19:09, 13 de agosto de 2021 (UTC) [ responder ]
 Hecho *Pppery* ha comenzado... 19:17, 13 de agosto de 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 9 de agosto de 2021

Coloque espacios alrededor de la salida × del número de rot consistente con {{aircraft specs/eng}}. 148.252.129.49 ( discusión ) 13:20 9 ago 2021 (UTC) [ responder ]

 Hecho *Pppery* ha comenzado... 17:50, 13 de agosto de 2021 (UTC) [ responder ]

No puedo lograr que los parámetros "sigfig" funcionen correctamente

No puedo lograr que los parámetros "sigfig" funcionen correctamente, al menos con ciertos parámetros de especificación, por ejemplo, "peso vacío" y "peso máximo de despegue". He creado un pequeño ejemplo aquí. El peso vacío debe tener solo una cifra significativa y el peso máximo de despegue debe tener 8 cifras significativas. Pero parece que en ambos casos los valores convertidos tienen 6 cifras significativas:

Características generales

Actuación

¿Alguien podría decirme qué hice mal? Spike ( discusión ) 17:53 22 oct 2021 (UTC) [ responder ]

Parece que no funciona con los campos de peso. No estoy seguro de que esto sea algo nuevo. Parece que funciona bien con las dimensiones y las velocidades al menos. Nigel Ish ( discusión ) 18:10, 22 de octubre de 2021 (UTC) [ responder ]
¿Se supone que debería existir una opción sigfig? Supuse que el uso incorporado de la plantilla de conversión brindaría la precisión adecuada. GraemeLeggett ( discusión ) 19:44, 22 de octubre de 2021 (UTC) [ responder ]
Después de leer la página anterior y mirar uno o dos artículos, por ejemplo, Lancaster, donde las conversiones son "Peso vacío: 36.900 lb (16.738 kg)

Peso bruto: 55.000 lb (24.948 kg) Peso máximo de despegue: 68.000 lb (30.844 kg)" - parece que las conversiones de peso están mal. En mi humilde opinión, añadir la opción de cifra significativa porque uno o dos artículos tenían longitudes "precisas" hasta una fracción de pulgada que causaban problemas en lugar de la respuesta obvia de redondear la entrada a la pulgada más cercana fue una mala decisión y debería deshacerse. GraemeLeggett ( discusión ) 20:02, 22 de octubre de 2021 (UTC) [ responder ]

Uso de negrita en esta plantilla

El manual de estilo indica que no se debe usar negrita en situaciones como esta. ¿Hay alguna razón específica para su uso? Si no es así, sugeriría que se elimine. Se agradece cualquier aporte. Saludos, DesertPipeline ( discusión ) 18:52, 24 de octubre de 2021 (UTC) [ responder ]

¿Puedes ser más específico en cuanto a qué directriz infringe esto? Después de analizarlo recientemente en relación con otra plantilla, no infringe ninguna norma. BilCat ( discusión ) 19:26 24 oct 2021 (UTC) [ responder ]
BilCat tiene razón. Como señala, acabamos de pasar por todo esto con otra plantilla. No veo que se mencionen "situaciones como esta" en MOS:BOLD, y más particularmente en la lista negra MOS:NOBOLD . La única directriz MOS relevante que conozco es WP:PSEUDOHEAD , donde este tipo de negrita es aceptable (sic) y se prefiere explícitamente sobre el marcado de lista de descripción (un prefijo de punto y coma, as ;) al que de otro modo tendríamos que recurrir. Recomendaría respetuosamente que cualquier sugerencia seria de eliminación vaya acompañada de una propuesta de formato de reemplazo con un código de marcado asociado que se sepa que cumple con las pautas de accesibilidad , además de una justificación de por qué ayuda al lector visitante . Pero probablemente haya mejores cosas por hacer. — Saludos, Steelpillow ( Discusión ) 20:11, 24 de octubre de 2021 (UTC) [ responder ]
Usuario: Steelpillow : La página del manual de estilo no indica que deba (o pueda) usarse en esta situación; no estoy seguro de si el hecho de que no esté escrito explícitamente que no debe usarse en este contexto significa algo. Además, los fragmentos de texto en cuestión que están en negrita no son encabezados, son parte de listas con viñetas. Las viñetas deberían ser suficientes para este uso, sin necesidad de usar negrita también. Saludos, DesertPipeline ( discusión ) 20:19, 24 de octubre de 2021 (UTC) [ responder ]
No estoy de acuerdo, el uso de negrita en esta plantilla ayuda al lector a distinguir más fácilmente el parámetro de los datos. No veo ningún beneficio en eliminar el marcado en negrita, e incluso si fuera en contra de MOS:BOLD , creo que sería un candidato ideal para WP:IAR . - ZLEA T \ C 20:50, 24 de octubre de 2021 (UTC) [ responder ]
Lo que no está prescrito ni prohibido es opcional. Para responder a la pregunta original, sí, hay una razón específica. Lo que tenemos aquí es semánticamente un conjunto de listas de descripción (de dos partes). Necesitamos el título y el valor en la misma línea. Dado que Wikipedia aplica estilos a las listas de descripción en dos líneas, tenemos que jugar con el CSS o conformarnos con listas desordenadas simples. Y dado que HTML no ofrece tabulaciones, nos vemos obligados a poner el título en negrita para distinguirlo del valor. Las listas desordenadas vienen cargadas de viñetas, que necesitarían más ensalada CSS para ocultarse; si eso es lo que te molesta, no dudes en hacerlo, estoy de acuerdo en que sería una mejora. — Saludos, Steelpillow ( Discusión ) 21:06, 24 de octubre de 2021 (UTC) [ responder ]
Usuario:Steelpillow , Usuario:ZLEA : En mi opinión, no es necesario "distinguirlo del valor". Esto se hace a menudo en listas de este formato en Wikipedia y no veo por qué. Seguramente el título y el valor se pueden distinguir entre sí leyendo el texto.

Podrías considerar convertir esta plantilla en una tabla en lugar de una lista con viñetas. Mira el cuadro contraído para ver un ejemplo de cómo se vería. Para ahorrar espacio vertical, tal vez cada tabla se pueda colocar en el mismo lugar horizontalmente, cada una a la derecha de la última. Saludos, DesertPipeline ( discusión ) 14:25 25 oct 2021 (UTC) [ responder ]

Estoy confundido, ya que la negrita se usa de la misma manera en la página principal, particularmente en la sección "Otras áreas de Wikipedia", y los cuadros de información usan una etiqueta de parámetro/dato en negrita seguida de entradas en texto sin formato para cada línea. Las descripciones de parámetros en negrita se usan en las fuentes que se usan a menudo en estas secciones, Flight International , Janes y la serie Observer's Books . Nimbus (Cumulus nimbus flota) 15:00, 25 de octubre de 2021 (UTC) [ responder ]

¡Esto se está poniendo interesante!
En primer lugar, en respuesta a Nimbus227 , la lista que se acaba de citar en la página principal muestra los enlaces en negrita, que también son los títulos con viñetas, a diferencia de aquí, donde no tenemos enlaces. No tengo ningún libro reciente de Jane's/Observers, pero mi antiguo Jane's usa texto simple en todo el libro y mi Observer's usa títulos en cursiva. Lo que Jane's usa en cambio es un diseño más o menos en columnas, es decir, en forma de tabla. Pero tal vez el mundo editorial haya cambiado desde los años 80, ¿qué sé yo?
A continuación, la salida HTML. Desde hace tiempo se ha dicho que no se deben utilizar tablas para el diseño de páginas, ya que supuestamente estropean los lectores de asistencia. Pero en realidad se trata de un problema de la Edad de Piedra, de la época en que DreamWeaver y FrontPage eran unos inútiles; durante al menos las dos últimas décadas, los lectores se han manejado admirablemente con las tablas, y es de hecho la anidación de elementos como las etiquetas div y las listas con formato incorrecto lo que las estropea. Eso de alguna manera excluye la consideración de la representación de tales elementos por parte de MediaWiki, ejem. Así que sí, estoy de acuerdo en que las tablas son una buena opción.
Más sobre negrita. Si tiene un diseño tabular que separa claramente el título de los datos, no es necesario poner el título en negrita. Centrar los títulos es una tontería, deben estar alineados a la derecha. La visualización clara de los datos puede variar, pero la alineación a la izquierda predeterminada también es una buena opción, al menos para empezar. Pero no queremos la mayoría de los bordes y sombreados y demás, por lo que deberíamos usar un estilo simple predeterminado y agregar un borde de cuadro alrededor de todo para mayor claridad.
Me gusta la disposición de lado a lado que, según he notado, se coloca de manera predeterminada una encima de la otra para pantallas estrechas o móviles. Sin embargo, las complicaciones sobre las citas en línea individuales son innecesarias, simplemente se pueden agregar al valor de datos individual de la manera habitual. Así que aquí está mi intento de avanzar. — Saludos, Steelpillow ( Discusión ) 18:10, 25 de octubre de 2021 (UTC) [ responder ]
¿Estás hablando de cambiar la presentación de esta plantilla a un formato de tabla, o reemplazarla con una tabla formateada en cada artículo, como ya se hace con los artículos de aerolíneas? BilCat ( discusión ) 18:27 25 oct 2021 (UTC) [ responder ]
Entonces, lo que propones es eliminar la plantilla (y presumiblemente todas las especificaciones que se citan con ella). ¿Por qué no eliminar también todos los artículos? Nigel Ish ( discusión ) 20:28, 25 de octubre de 2021 (UTC) [ responder ]
No hay ninguna posibilidad de que un cambio del formato actual tenga éxito, ¿no? ¿Qué tal si cerramos esto y seguimos adelante? GraemeLeggett ( discusión ) 20:39 25 oct 2021 (UTC) [ responder ]
Usuario: Steelpillow : Su ejemplo parece bastante bueno, aunque ¿hay algún problema con tener la apariencia de tabla normal? Algunos textos parecen demasiado juntos sin la delineación. Además, no estoy seguro de qué está causando que los encabezados de las tablas "Características generales" y "Rendimiento" de su ejemplo estén en negrita, pero sugeriría asegurarse de que no estén en negrita y aumentar el tamaño de fuente (usé 110% para mi ejemplo). Además, tal vez sería mejor que el texto "Datos de" esté debajo de las tablas. Saludos, DesertPipeline ( discusión ) 00:46, 26 de octubre de 2021 (UTC) [ responder ]
Las tablas pueden resultar un poco complicadas para los usuarios nuevos. Personalmente, creo que la plantilla tal como está ahora es más sencilla y no tiene tanto potencial de causar problemas de accesibilidad como una tabla. También recomiendo no cambiar la plantilla en sí a un formato de tabla porque complicaría mucho las cosas (lo sé porque acabo de intentar hacerlo). - ZLEA T \ C 03:14, 26 de octubre de 2021 (UTC) [ responder ]
Recomiendo no cambiar la plantilla actual y mantener el texto en negrita como está. BilCat ( discusión ) 03:34 26 oct 2021 (UTC) [ responder ]
Usuario:ZLEA : Si bien estoy de acuerdo en que el código de plantilla para mostrar la información en una tabla será más complejo que el código actual, al menos esto solo debe hacerse una vez. Cuando el código esté escrito y funcione, las personas que coloquen la plantilla en un artículo no tendrán que escribir ninguna tabla por sí mismas. Saludos, DesertPipeline ( discusión ) 03:39, 26 de octubre de 2021 (UTC) [ responder ]
Antes de seguir este camino, te sugiero que 1) compruebes si es factible: vas a necesitar que alguien haga realmente el código antes de que puedas probar la idea 2) te asegures de haber presentado la idea ante otras partes interesadas (por ejemplo, miembros del Proyecto de Aviación, aviación militar, etc.) 3) consultes con la gente del Manual de Estilo para ver si la versión actual es una afrenta al MoS y no solo una "exención" no documentada. GraemeLeggett ( discusión ) 05:59, 26 de octubre de 2021 (UTC) [ responder ]

Para aclarar los conceptos básicos, la sugerencia es modificar la plantilla para que cree tablas en lugar de listas con viñetas. Como ya se ha señalado, no se propone ningún cambio en los artículos.

@ DesertPipeline : No recuerdo ningún editor importante que use bordes de celdas para tales tablas. Aunque a veces se usan colores de fondo bonitos, eso es puramente por ostentación, no tienen ninguna función útil y luchamos una batalla eterna contra esos artistas de la ostentación; no quisiera alentarlos. Además, ¿por qué agregar marcado innecesario? Los encabezados de tabla en mi ejemplo están en negrita porque están formateados como celdas de encabezado de tabla, usando el !marcado de wikitexto (pling) en lugar de |(pipe). Podrían formatearse como títulos de tabla o incluso subtítulos, si se prefiere, pero necesitan alguna bandera para que las herramientas de accesibilidad se enganchen. Personalmente, me quedaría con el tamaño de fuente predeterminado para cualquier elemento elegido, sin embargo, si otros prefieren un tamaño más grande, está bien. Según MOS:FONTSIZE, el uso actual de <big>...</big>debería en cualquier caso cambiarse a un porcentaje Template:Big se usa actualmente para dar una ampliación del 120%. El espaciado entre elementos se puede ajustar fácilmente usando CSS, mi ejemplo es solo una salida de plantilla rápida y sucia para demostrar el principio. El hecho de que las citas de "Datos de" se ubiquen arriba o abajo se aplica al formato que adoptemos y es una cuestión independiente.

Pero estoy de acuerdo con GraemeLeggett en que tendríamos que probar el concepto con una plantilla de prototipo funcional antes de que el resto de este proyecto esté (o incluso deba estar) dispuesto a tomar en serio una propuesta de este tipo. ¿Vale realmente la pena correr el riesgo de que la rechacen o de que los problemas de ZLEA sean insolubles?

— Saludos, Steelpillow ( Discusión ) 09:36 26 oct 2021 (UTC) [corregida 10:26 26 oct 2021 (UTC)] [ responder ]

Steelpillow plantea algunos puntos excelentes. Además, me hizo pensar en un problema relacionado que WP:AIR ha analizado varias veces durante los últimos 10 o 12 años, pero nunca ha resuelto. Actualmente, tenemos una mezcolanza de varias tablas para las especificaciones en muchos de nuestros artículos sobre aviones comerciales y de pasajeros. Si es posible crear una plantilla de especificaciones que se base en Template:Aircraft specs, pero que pueda generar un formato de tabla, tal vez podamos hacer que muestre las especificaciones de múltiples variantes de una aeronave. Probablemente tendría que acomodar entre 2 y 5 variantes, lo que debería ser suficiente para la mayoría de los artículos sobre aviones comerciales. Esta plantilla de tabla no reemplazaría a Template talk:Aircraft specs por completo, sino que se usaría en lugar de ella en artículos que actualmente usan tablas para las especificaciones, como los aviones comerciales. BilCat ( discusión ) 10:14, 26 de octubre de 2021 (UTC) [ responder ]
Aceptar una cantidad de columnas determinada por el usuario es posible y sería útil, pero requiere un uso aún mayor y más complejo de las funciones de análisis y similares. Estoy un poco oxidado en todo eso, dejemos esto para el final. — Saludos, Steelpillow ( Discusión ) 10:38, 26 de octubre de 2021 (UTC) [ responder ]
Steelpillow El uso de funciones del analizador para ocultar celdas cuando no están en uso provoca algunas cosas extrañas en las celdas no ocultas. - ZLEA T \ C 12:05, 26 de octubre de 2021 (UTC) [ responder ]
De hecho. Afortunadamente, la plantilla actual utiliza estas funciones para agregar contenido, no para ocultarlo (establecer los parámetros genhide y perfhide simplemente evita agregar los pseudoencabezados). No veo ninguna razón para descartar ese principio. — Saludos, Steelpillow ( Discusión ) 13:01, 26 de octubre de 2021 (UTC) [ responder ]
Sería más eficaz para los aviones de pasajeros tener una especificación específica desarrollada con la plantilla estándar y una tabla posterior que compare las diferencias clave entre varios modelos (como por ejemplo en el artículo de Avro Vulcan ). Pero ese también es un tema que debería ser cubierto por todo el proyecto WP:Air GraemeLeggett ( discusión ) 11:08, 26 de octubre de 2021 (UTC) [ responder ]

(Pongo mi comentario aquí porque estoy dando una respuesta general) La sugerencia de discutir el tema de las negritas en la página de discusión de MOS es sensata. La mejor idea sería obtener datos concluyentes sobre si el uso de negritas en listas como esta (y en cualquier otro contexto) realmente ayuda a los lectores. Con respecto a todo lo demás dicho, creo que se está volviendo un poco demasiado complejo para mí participar en esta discusión en particular, específicamente, partes sobre estadísticas generales para aeronaves en una tabla. No estoy lo suficientemente familiarizado con el tema como para brindar información útil. Espero que otros puedan continuar esta discusión (posiblemente en otro lugar que no sea esta página de discusión) y determinar si se debe implementar. Saludos, DesertPipeline ( discusión ) 14:49, 26 de octubre de 2021 (UTC) [ responder ]

El hecho de que sea o no "útil para los lectores" es en gran medida subjetivo y en realidad se reducirá a un voto de "no me gusta". Para mí, es útil porque ayuda a los ojos del lector a distinguir entre las etiquetas y las especificaciones en sí. El principal tema a discutir en MOS sobre el uso de negrita en las especificaciones es si causa o no problemas de accesibilidad. Ese siempre ha sido el principal problema con el uso de negrita en los pseudotítulos, no la "utilidad". BilCat ( discusión ) 18:51, 26 de octubre de 2021 (UTC) [ responder ]
Claramente, el texto en negrita ayuda al usuario a leer el resultado de los artículos, pero estoy confundido por la discusión, ya que hasta donde sé, esta plantilla no usa tablas. Hasta donde puedo ver, el texto en "negrita" en los títulos no tiene nada que ver con las tablas, así que ¿solo estamos tratando de complicar las cosas? ¿El OP pensó que la tabla "Parámetros de la plantilla" estaba relacionada con el resultado? Hasta donde sé, eso es solo información para esta página. Alternativa Puede que sea un poco tonto y no entienda el punto. MilborneOne ( discusión ) 19:36, 26 de octubre de 2021 (UTC) [ responder ]
La sugerencia es que si se cambiara la plantilla para usar tablas, entonces los números podrían alinearse en una columna y ya no sería necesario poner en negrita los nombres de los elementos. Vea mi menú desplegable "Ejemplo de tablas sin adornos" para ver un ejemplo aproximado de lo que quiero decir. — Saludos, Steelpillow ( Discusión ) 21:28, 26 de octubre de 2021 (UTC) [ responder ]

Formato de tabla

Me gustaría señalar que el problema con mi plantilla de tabla es conocido, pero no tengo idea de cómo solucionarlo. Aquí se muestra cómo se realizaría la transclusión con todos los parámetros completos (tenga en cuenta que no agregué todos los parámetros de la plantilla original y omití las unidades y las conversiones en estos ejemplos):

Dado que la plantilla está diseñada para ser universal para todas las aeronaves, ninguna aeronave utilizará todos los parámetros. Los parámetros no utilizados saturan la plantilla, por lo que es necesario ocultarlos con funciones de análisis. Sin embargo, las funciones de análisis parecen actuar como caracteres invisibles (a los que llamaré "funciones de análisis fantasma") cuando se les indica que no muestren nada, lo que significa que los saltos de línea residuales no se ignoran al renderizar la página:

Si podemos solucionar este problema, entonces crear una plantilla de especificaciones de formato de tabla debería ser fácil. - ZLEA T \ C 00:58, 27 de octubre de 2021 (UTC) [ responder ]

Esta es una "característica" bien conocida de la codificación de plantillas. A diferencia del wikitexto normal, el analizador de plantillas puede ser muy sensible a los saltos de línea. Por lo tanto, debe escribir su código más en el espíritu de:
|-! Envergadura| 0(función de analizador fantasma)(función de analizador fantasma)(función de analizador fantasma)|-! Envergadura en flecha| 42(función de analizador fantasma)(función de analizador fantasma)|-
Esto hace que la comprensión y la depuración sean diabólicas, pero nadie ha sido capaz de hacer que el analizador sea más fácil de usar.
— Saludos, Steelpillow ( Discusión ) 08:55 27 oct 2021 (UTC) [ responder ]
Se necesitaron 11 años para que esta plantilla tuviera el formato actual, y comenzó como un derivado de otra. "Fácil" (y "rápido") son términos relativos. GraemeLeggett ( discusión ) 10:36 27 oct 2021 (UTC) [ responder ]
Steelpillow Lo intenté, pero el problema es que el código en realidad se transcluiría como:
|-! Envergadura| 0(función de analizador fantasma)(función de analizador fantasma)(función de analizador fantasma) |-! Envergadura en flecha| 42(función de analizador fantasma)(función de analizador fantasma) |-
No puede haber un «|-» en la misma línea que una celda. - ZLEA T \ C 11:52, 27 de octubre de 2021 (UTC) [ responder ]
Estoy bastante seguro de que solía poder resolver eso, posiblemente al tener una segunda plantilla que producía el código para una sola fila y luego invocarlo repetidamente desde la plantilla principal. Hoy en día también tenemos módulos , que ejecutan código Lua arbitrario . Por lo tanto, debe ser técnicamente factible, solo un verdadero dolor de cabeza. Vea también esta discusión sobre otra de las plantillas de nuestro proyecto. Si tengo tiempo, experimentaré. — Saludos, Steelpillow ( Discusión ) 13:20, 27 de octubre de 2021 (UTC) [ responder ]

Actualización: Estoy haciendo un buen progreso en mi sandbox . Para conocer mi estado actual de renderizado y otra información, consulte mi página de usuario de aeronaves . Puntos destacados: He necesitado tres formas diferentes de renderizar el código de la tabla, dependiendo de dónde se encuentre en la pila de espaguetis. Hay una segunda plantilla, especialmente para los datos del motor, invocada solo por la plantilla principal y oculta en Template:Aircraft specs/eng ; me ocuparé de eso a continuación. Hasta ahora no hay obstáculos. — Saludos, Steelpillow ( Discusión ) 11:27, 29 de octubre de 2021 (UTC) [ responder ]

Formato propuesto

Eso fue más fácil de lo que esperaba. Aquí hay un ejemplo en mi nuevo formato de tabla. Se puede comparar con la versión en vivo actual aquí . ¿Qué opinan? Si parece estar en la línea correcta, lo trasladaré al entorno de pruebas adecuado para que pueda probarse adecuadamente. Saludos, Steelpillow ( Discusión ) 14:06, 29 de octubre de 2021 (UTC) [ responder ]

Especificaciones (pseudotítulo falso)

[ convertir: necesita un número ]

Referencias


Pensé que el objetivo era no tener encabezados en negrita . Aparte de eso, la legibilidad es peor en comparación con la actual. Con términos en negrita, puede escanear rápidamente hacia abajo para encontrar los que le interesan y luego leerlos de arriba a abajo. Hay poca diferenciación entre el nombre del elemento y el valor. Me intriga si la plantilla puede manejar la sangría que será necesaria para enumerar las cargas de armamento en el código de puntos duros. GraemeLeggett ( discusión ) 18:28, 29 de octubre de 2021 (UTC) [ responder ]
PD: las conversiones de peso aún no funcionan correctamente debido a la inclusión de la opción sigfig, por ejemplo, la representación de 5300 lb (aproximadamente) como 2404 kg. Te sugiero que lo saques y lo tires a la basura. GraemeLeggett ( discusión ) 18:47, 29 de octubre de 2021 (UTC) [ responder ]
Gracias por los comentarios. Esta versión se puede adaptar fácilmente para que se ajuste a cualquier negrita que se requiera, manteniendo al mismo tiempo la semántica para lectores asistentes. Es decir, el estilo visual se puede cambiar, la semántica incorporada en el código no debería cambiarse. Los valores de los parámetros ahora están todos alineados, lo que facilita la lectura cuando no hay negrita. Ninguna de estas características es posible con la versión actual. Lo que muestro aquí es solo un ejemplo para el bien de la discusión; por ahora es simplemente el valor predeterminado para la semántica. No estaba al tanto de la sangría, intentaré echarle un vistazo una vez que se establezca el principio. Las conversiones de peso son un tema aparte, que se trata mejor en una discusión aparte. — Saludos, Steelpillow ( Discusión ) 19:23, 29 de octubre de 2021 (UTC) [ responder ]
@ GraemeLeggett : La plantilla: especificaciones/casos de prueba de aeronaves no parece utilizar la parte de la plantilla que sangra los detalles del armamento. ¿Puede usted (o alguien) indicarme uno o dos artículos que sí muestren la sangría? — Saludos, Steelpillow ( Discusión ) 11:09, 30 de octubre de 2021 (UTC) [ responder ]
Pruebe Fairchild_Republic_A-10_Thunderbolt_II#Specifications_(A-10C) y Lockheed_P-38_Lightning#Specifications_(P-38L) para mejorar el diseño de la sección de armamento. Parece que BAC_TSR-2#Specifications sería una opción para manejar texto largo en la sección de armamento. GraemeLeggett ( discusión ) 12:26 30 oct 2021 (UTC) [ responder ]
Gracias. Entonces, hay dos tipos de listas anidadas. Una está basada en plantillas para los subparámetros de "puntos duros". Esto se puede solucionar, ya sea con algo de CSS o una tabla anidada, dependiendo de cómo nos sintamos con respecto a la semántica. El otro tipo es el wikitexto del usuario ingresado en el artículo mismo. Algunas entradas contienen nidos de viñetas codificados de forma rígida que interactúan con las listas de viñetas basadas en plantillas. No hay una solución fácil para esto. El único enfoque viable que se me ocurre es agregar un nuevo parámetro de plantilla que, cuando esté presente en una nueva lista, la trataría de manera diferente a la solución heredada. Eventualmente, el código heredado se puede limpiar de los artículos (un bot sería una buena opción) y el parámetro puede quedar obsoleto. — Saludos, Steelpillow ( Discusión ) 15:54, 30 de octubre de 2021 (UTC) [ responder ]

Pero lo que acabo de describir es un programa de trabajo importante y no vale la pena seguir adelante a menos que haya un consenso claro en el proyecto para pasar a este formato basado en tablas. No veo que ese consenso surja en ningún momento antes de que un determinado lugar cálido se congele. Por lo que respecta a mi propuesta, se acabó el juego. Gracias a todos los que contribuyeron; al menos hemos aprendido algo que puede ayudar a otros en el futuro. — Saludos, Steelpillow ( Discusión ) 15:54, 30 de octubre de 2021 (UTC) [ responder ]

Me gusta cómo se ven tus especificaciones enmarcadas y aprecio tus esfuerzos, pero a menos que haya una gran ventaja, creo que deberíamos seguir manteniendo el formato actual, negrita y todo, solo porque será mucho más fácil para los editores trabajar en él. - Ahunt ( discusión ) 16:08, 30 de octubre de 2021 (UTC) [ responder ]
Solo quiero reiterar que, en general, NO HACE NINGUNA DIFERENCIA para el editor de artículos, todo se hace con la magia de las plantillas. La única excepción sería una transición de viñetas sangradas codificadas por el usuario al nuevo modo, y uno o dos bots deberían poder hacer eso. — Saludos, Steelpillow ( Discusión ) 16:29, 30 de octubre de 2021 (UTC) [ responder ]
Ah, ya veo, ¡gracias por la aclaración! - Ahunt ( discusión ) 16:38 30 oct 2021 (UTC) [ responder ]
En cuanto a las listas con viñetas creadas por el usuario dentro del formulario con plantilla, es un ejemplo de que, independientemente del plan que se formule para hacer algo con solo un elemento por parámetro, alguien encontrará la necesidad de agregar más sangría, o una lista con viñetas (lista simple), o algún otro formato manual dentro de un parámetro y encontrará una manera de hacerlo. Hay 12 000 artículos que utilizan esta plantilla.
PD: Todavía me opongo al formato sin negrita y al recuadro alrededor de la especificación.
PPS: sería necesario que cada elemento de la tabla tuviera la alineación superior activada para cuando el texto variable pase a una nueva línea. GraemeLeggett ( discusión ) 18:25 30 oct 2021 (UTC) [ responder ]
Todo eso NO SERÍA PROBLEMA, una vez que se llegara a un acuerdo. Es trivial ajustar el estilo para cumplir con el consenso, realmente lo es. El único problema real es limpiar las listas de viñetas ingresadas por los usuarios, ya que muchas necesitarían ajustar la cantidad de estrellas de viñetas; un bot debería poder hacer eso. — Saludos, Steelpillow ( Discusión ) 19:39, 30 de octubre de 2021 (UTC) [ responder ]

También prefiero el formato actual y no veo ninguna necesidad de cambiarlo. Sin embargo, apoyaría una prueba en varios artículos destacados para ver si recibimos algún comentario de los lectores, positivo o negativo. Si a los lectores les encanta abrumadoramente, o si hay pocos comentarios negativos, entonces apoyaría una implementación completa. BilCat ( discusión ) 20:02, 30 de octubre de 2021 (UTC) [ responder ]

Otra pregunta: ¿Cómo se verá esto en formato móvil? No lo uso, así que no tengo ni idea. BilCat ( discusión ) 20:05 30 oct 2021 (UTC) [ responder ]

Propuesta revisada

He incorporado las partes fáciles de los comentarios anteriores, pero siguen habiendo problemas con ellas:

El estilo se ha revertido para que coincida mejor con el actual. El problema es que los pseudotítulos de las secciones son indistinguibles de los títulos reales de nivel 3, y me parece inaceptable. Una solución intermedia es hacerlos del mismo tamaño que los títulos de los artículos, pero eso también se ve horrible. La falta de un borde agrava aún más el desorden; al menos, separaría el texto de los subtítulos reales del artículo. Eliminar la primera columna en negrita solucionó todo eso y está más en línea con las prácticas editoriales respetables.

Los parámetros de puntos duros con sangría y de varias líneas se han solucionado de forma provisional. Puedo ajustar la sangría según sea necesario. Las listas introducidas por el usuario pueden seguir mostrando varias peculiaridades, tanto para esto como para la aviónica, pero crear un robot de limpieza está más allá de mi zona de confort. Pero ¿vale la pena seguir con ese robot de limpieza?

Para la vista móvil, la interfaz estándar tiene un menú en la parte inferior de la página, con una opción de "Vista móvil".

— Saludos, Steelpillow ( Discusión ) 09:08 1 nov 2021 (UTC) [ responder ]

Especificaciones (pseudotítulo falso)

[ convertir: necesita un número ]

Referencias


En la vista móvil, debido a la falta de balas, todo se ve apretado contra el borde izquierdo de la pantalla. Podría ser útil un poco de espacio para mover los elementos individuales un poco hacia la derecha debajo de cada uno de los encabezados General, Rendimiento y Armamento. Y diría lo mismo en la vista de escritorio también. GraemeLeggett ( discusión ) 11:11, 1 de noviembre de 2021 (UTC) [ responder ]
¿Es diferente del texto principal? Es una "característica" común de las hojas de estilo móviles ineptas y no quisiera hacer una excepción solo para esta lista. — Saludos, Steelpillow ( Discusión ) 13:57, 1 de noviembre de 2021 (UTC) [ responder ]
Me pregunto si podemos agregar un campo para un dibujo en este momento; tal como está ahora, con poca visión general, los dibujos se muestran en tamaños aleatorios, a menudo con un exceso de codificación totalmente innecesaria y muchas veces con tamaños configurados explícitamente cuando no deberían serlo.

Agregar la imagen a la tabla puede ayudar a garantizar que se muestre de manera uniforme, al mismo tiempo que reduce la codificación y mejora la accesibilidad. - NiD.29 ( discusión ) 18:23, 1 de noviembre de 2021 (UTC) [ responder ]

Me gusta la idea, pero, al igual que el estilo exacto y el error de las firmas, creo que es mejor abordarlo en un hilo aparte. Cuantos más cambios incluyamos en una propuesta determinada, más difícil será obtener un consenso para el cambio. — Saludos, Steelpillow ( Discusión ) 19:02, 1 de noviembre de 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 23 de diciembre de 2021

Saludos y felicitaciones. En "con una capacidad de {{{capacidad de punto de anclaje}}}", agregue un espacio al final, después de la coma. Motivo: Actualmente, Fairchild Republic A-10 Thunderbolt II#Especificaciones (A-10C) incluye "con una capacidad de 16 000 lb (7260 kg), con provisiones para transportar combinaciones de: " [ sic ]. Agregar un espacio después de la coma (por cualquier medio que sea razonable) aliviará este problema. — DocWatson42 ( discusión ) 15:12 23 dic 2021 (UTC) DocWatson42 ( discusión ) 15:12 23 dic 2021 (UTC) [ responder ]

Lo hicimos en el sandbox y lo probamos . Ahora esperamos que aparezca un editor de plantillas. - ZLEA T \ C 15:34, 23 de diciembre de 2021 (UTC) [ responder ]

 Listo . PI Ellsworth  -  ed.  put'r there  20:40, 23 de diciembre de 2021 (UTC) [ responder ]

@ ZLEA y Paine Ellsworth : Gracias a ambos. ^_^ — DocWatson42 ( discusión ) 03:52 24 dic 2021 (UTC) [ responder ]
¡Es un placer!  Paine   05:48, 24 de diciembre de 2021 (UTC)[ responder ]

Campos faltantes

Por favor, consulte |prime units?=el parámetro. -- AXO NOV (discusión) ⚑ 19:02 23 mar 2022 (UTC) [ responder ]

La siguiente discusión está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.

El siguiente ejemplo no aparece.

Especificaciones de la aeronave|peso máximo de despegue kg=15|velocidad máxima kmh=150|resistencia=16 horas|alcance de combate km=140|rango de ferry km=600|techo m=5000|eng1 tipo=1 tiempo [[motor de pistón]]|eng1 numero=1|eng1 hp=1|eng1 nombre=SAITO FA-62B, JAPÓN|eng1 nota=(combustible - gasolina A-95)|más general=* '''Carga útil:''' {{convert|6|kg|lbs|abbr=on}}* '''Método de lanzamiento''': una plataforma de catapulta plegable* '''Método de aterrizaje''': recuperación con paracaídas* '''Velocidad máxima del viento al inicio''': 10 m/s* '''Rango de temperatura de funcionamiento''': −30 a +40 °C}}

Características generales

Actuación

Alexander_Davronov Debes configurar el parámetro "¿unidades principales?" para que se muestren la mayoría de las especificaciones. El siguiente ejemplo debería funcionar:
Especificaciones de la aeronave|unidades primas?=met|peso máximo de despegue kg=15|velocidad máxima kmh=150|resistencia=16 horas|alcance de combate km=140|rango de ferry km=600|techo m=5000|eng1 tipo=1 tiempo [[motor de pistón]]|eng1 numero=1|eng1 hp=1|eng1 nombre=SAITO FA-62B, JAPÓN|eng1 nota=(combustible - gasolina A-95)|más general=* '''Carga útil:''' {{convert|6|kg|lbs|abbr=on}}* '''Método de lanzamiento''': una plataforma de catapulta plegable* '''Método de aterrizaje''': recuperación con paracaídas* '''Velocidad máxima del viento al inicio''': 10 m/s* '''Rango de temperatura de funcionamiento''': −30 a +40 °C}}

Características generales

Actuación

Como nota al margen, también debes usar el parámetro "ref" para mostrar de dónde obtuviste la información.
Gracias. -- AXO NOV (discusión) ⚑ 19:02 23 mar 2022 (UTC) [ responder ]
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.

Etiqueta de plantilla de "peso bruto" ambigua (¿e innecesaria?)

La plantilla estándar actual para las especificaciones de aeronaves incluye un parámetro denominado "peso bruto", así como los parámetros "peso vacío" y "peso máximo de despegue".

Las definiciones ofrecidas para "peso bruto" y "peso máximo de despegue" son confusamente contradictorias, a saber:

"Peso bruto: el peso de la aeronave con carga completa. En la mayoría de los casos, será el peso máximo de despegue"

y

"Peso máximo al despegue: el peso máximo al despegue de la aeronave, cuando sea diferente del peso bruto anterior"

Para aumentar la confusión, "peso bruto de la aeronave" tiene su propia página de Wikipedia con otra definición contradictoria:

"El peso bruto (también conocido como peso total y abreviado como AUW) es el peso total de la aeronave en cualquier momento durante el vuelo o la operación en tierra"

En mis más de 40 años en la industria, nunca he encontrado que "peso bruto" se utilice como algo más que un sinónimo de MTOW.

Wikipedia mezcla los dos términos indiscriminadamente, y algunos tipos tienen un "peso bruto" en el bloque de especificación y otros tienen un "peso máximo de despegue". Un puñado de tipos tienen ambos, y se agrega la anotación "aterrizaje" a "peso bruto" como una solución alternativa al hecho de que la plantilla actual de Wikipedia, curiosamente, no tiene el parámetro "peso máximo de aterrizaje".

Los certificados de tipo para aeronaves civiles invariablemente especifican "Peso máximo al despegue" (por ejemplo, FAA) o "Masa máxima al despegue" (EASA) y no contienen ninguna referencia al "peso bruto".

Mi propuesta es simple: si se considera que MLW es un componente deseable en una especificación de aeronave de Wikipedia, se debe agregar "peso máximo de aterrizaje" a la plantilla con una regla que indique que esto se debe usar cuando se incluye un MLW (opcionalmente) en la especificación.

Se aceptan comentarios. DaveReidUK ( discusión ) 09:24 7 jun 2022 (UTC) [ responder ]

Pocos tipos de aeronaves tienen un peso máximo de aterrizaje independiente para poder encontrar una fuente (ya que la gran mayoría de aeronaves son anteriores a tales cosas), y agregaría confusión adicional sin sentido a nuestros lectores no especialistas cuando se use, y no podría compararse fácilmente con el peso máximo mucho más común, pero invitaría a tales comparaciones. El uso indiscriminado de múltiples términos es el resultado de dicho uso por parte de la industria, especialmente cuando se consideran aeronaves francesas o alemanas. Casi TODAS las aeronaves francesas de la Segunda Guerra Mundial y anteriores a la Segunda Guerra Mundial tenían el peso máximo pintado en el timón y hay MUCHOS más de ellos que tipos modernos que usan expresiones más modernas para significar casi lo mismo.
Lo que la mayoría de los tipos tienen es un peso en vacío y algún tipo de peso máximo, y sí, el peso bruto suele ser sinónimo de todo el peso en vacío, especialmente para los aviones de la Segunda Guerra Mundial o anteriores a la Segunda Guerra Mundial. La plantilla ya ofrece los medios para agregar campos de forma ad hoc, y para los tipos poco frecuentes en los que esto es una preocupación, se puede agregar manualmente y no necesita otro campo que haga que la plantilla sea aún más grande. Si el peso máximo excede el peso máximo de aterrizaje, eso debe agregarse en el campo de notas. - NiD.29 ( discusión ) 11:24, 7 de junio de 2022 (UTC) [ responder ]
En lo que respecta al MTOW y similares, la gran dificultad a la que se enfrenta Wikipedia es la necesidad de obtener fuentes fiables de todo. La vida real es complicada; por ejemplo, algunos aviones despegan con los tanques de combustible medio vacíos y los rellenan en pleno vuelo, por lo que el peso bruto máximo es superior al MTOW. Solo podemos citar las fuentes con las que nos topamos, por lo que siempre hay margen para mejorar si alguien puede exponer y justificar una propuesta en particular. Pero me desconcierta tu publicación. Dedicas nueve párrafos a exponer los problemas relacionados con el MTOW, etc., y luego cambias de tema por completo y ofreces una propuesta de una sola línea sobre cómo tratar el MLW. Sin embargo, en ese caso no hay nada que sugiera, en ningún caso, si el MLW se "considera un componente deseable de una especificación de aeronave de Wikipedia". Se podría suponer que en la actualidad no se considera así, de lo contrario también estaría en plantilla. No me queda claro a dónde quieres llegar con todo esto. Sería más claro si limitaras tu discusión a un cambio propuesto por discusión. — Saludos, Steelpillow ( Discusión ) 11:51 7 jun 2022 (UTC) [ responder ]

Distancia de despegue, distancia de aterrizaje y distancia para despejar 15 m/50 pies

¿Por qué no hay parámetros para la distancia de despegue, la distancia de aterrizaje y la distancia para superar los 15 m/50 pies?

Para las aeronaves que operan desde pistas, estos son algunos de los parámetros más importantes. — Comentario anterior sin firmar agregado por Lkingscott ( discusión • contribuciones ) 01:18, 28 de enero de 2023 (UTC) [ responder ]

Como Wikipedia es una enciclopedia general y no Janes All The World's Aircraft , limitamos las especificaciones a unos pocos números clave. Si añadimos las distancias de despegue y aterrizaje, ¿por qué no las superficies de control o la presión de los neumáticos? - Ahunt ( discusión ) 01:25 28 ene 2023 (UTC) [ responder ]

Techo de servicio con enlace

Ha surgido cierta confusión en esta página: Discusión:Lockheed Martin F-22 Raptor#Altitud máxima 65.000 pies

Sería útil incluir un enlace a Ceiling (aeronáutica) para el parámetro de techo de servicio, tal como lo hacemos para "relación empuje-peso". {{u| Gtoffoletto }}  talk 11:53, 6 de febrero de 2023 (UTC) [ responder ]

Caballo de fuerza

Hola, amigos de los aviones. Escribo principalmente sobre coches, pero no exclusivamente. Un problema que he notado es que todos los países (hasta donde sé) que no hablan inglés utilizan caballos de fuerza métricos, que son el equivalente a 735 vatios en lugar de los 746 vatios de un caballo de fuerza imperial o habitual. Esto se aplica a Alemania, Francia, Japón y todos los demás países que he podido determinar. En algunos artículos veo que esto se tiene en cuenta, en Daimler-Benz DB 601 , por ejemplo. ¿Hay alguna forma de que la plantilla de especificaciones de aeronaves se pueda hacer para incorporar o hacer referencia de alguna manera a los diferentes tipos de caballos de fuerza?

Un problema es que la mayoría de las fuentes en inglés tienden a utilizar la abreviatura alemana para caballos de fuerza métricos (PS), ya que se utiliza en Alemania, pero también en Japón y Corea del Sur. Parece extraño utilizar PS para describir un Dewoitine o un Fiat, por lo que otra opción es utilizar hp-metric en las plantillas de conversión, aunque eso da como resultado "hp", lo que puede causar confusión (consulte el ejemplo n.° 4 en la tabla siguiente). Algunos escriben "hp (m)", pero no existe un estándar universalmente aceptado. De todos modos, espero que alguien tenga algunas ideas al respecto. Aquí hay una tabla de opciones para cuando se utilizan plantillas de conversión:

 Mr.choppers |  ✎  20:46, 18 de julio de 2023 (UTC)[responder]

Me preocupa un poco que el artículo sobre caballos de fuerza y ​​Template:convert no estén de acuerdo. El artículo trata a los caballos de fuerza y ​​a los caballos de fuerza métricos como si fueran lo mismo según la definición de DIN 66036, mientras que la plantilla los ofrece como unidades diferentes. El artículo afirma que el CV francés es el mismo, pero no ofrece ninguna fuente. Pero, por ejemplo, en 1945, ¿las unidades francesas y alemanas estaban realmente definidas de forma idéntica? El artículo carece en general de citas adecuadas. Por lo tanto, realmente sugeriría que los gurús de las unidades de Wikipedia se pongan manos a la obra con el tema y formen un consenso detallado, antes de que los aerófilos podamos saber qué deberíamos implementar. — Saludos, Steelpillow ( Discusión ) 07:54, 19 de julio de 2023 (UTC) [ responder ]
@ Steelpillow : La definición de 1 hp métrico = 735,5 vatios es la norma fuera de los países de habla inglesa y, hasta donde yo sé, fue elegida en Francia a finales del siglo XIX como definición métrica, muy cercana al cálculo original de Watt. El hp métrico todavía se llama cheval-vapeur en Francia, lo que indica sus orígenes en la era del vapor. Se define como la potencia necesaria para levantar 75 kg un metro en un segundo. El único cambio a esto ocurrió en 1901, cuando se ajustó la definición de gravedad estándar en la 3.ª Conferencia General de Pesos y Medidas .
Los japoneses todavía se refieren a los dos tipos de caballos de fuerza como franceses y británicos respectivamente (pero luego usan la abreviatura alemana "PS" solo para mantener las cosas interesantes). En cuanto a la terminología de conversión, el problema es que no existe un estándar universalmente aceptado para abreviar los caballos de fuerza métricos, lo que genera mucha confusión. Si tuviera una buena solución, hace mucho tiempo que les habría dicho a los expertos en plantillas qué hacer.  Mr.choppers |  ✎  04:57, 20 de julio de 2023 (UTC) [ responder ]
Así que ahí lo tienen. El artículo sobre caballos de fuerza debe aclarar todo eso y respaldarlo con citas ( WP:CITE ) de fuentes confiables ( WP:RS ) para que pueda verificarse ( WP:VERIFY ). Una vez hecho esto, se puede iniciar una discusión en Template talk:Convert sobre si mostrar tanto hp (Imperial) como hp-metric con la misma abreviatura " hp " es ambiguo y no ayuda y debería cambiarse. Dado que no hay una abreviatura estándar para hp métrico, una opción sería " hp (metric) ", pero entonces la gente podría querer calificar la otra como " hp (Imperial) " también; nunca cuestionaría ningún "consenso" de división temporal que nuestra manada de gatos pudiera discutir sobre el tazón de leche de hoy. En cualquier caso, preferiría ver todo esto resuelto antes de que cambiemos nuestras plantillas y pautas derivadas aquí. — Saludos, Steelpillow ( Discusión ) 08:42 20 jul 2023 (UTC) [ responder ]

¿No admite "," como separador decimal?

Hola, noté en Volocopter Volocity#Specifications que la plantilla no parece manejar "," como separador decimal. Por ejemplo, "length m=9,5" se representó como 95m en lugar de los 9,5m previstos, y las unidades imperiales también se multiplicaron por 10. Arreglé esto cambiando la coma por el punto decimal. ¿Se admite la coma como separador decimal en esta plantilla? Harris7 ( discusión ) 16:57 23 oct 2023 (UTC) [ responder ]

Lo más probable es que no cumpla con MOS:DECIMAL . Nimbus (Cumulus nimbus flota) 19:48, 23 de octubre de 2023 (UTC) [ responder ]

Cómo evitar las viñetas dobles utilizando solo * para sangrar

Recientemente noté un problema con el artículo Kawasaki P-1 ; la sección "Armamentos" tenía viñetas dobles para los subtítulos "Bombas:" y "Otros:", como se ve aquí .

Al comparar el formato de ese artículo con otros artículos sobre aviones militares (por ejemplo, Nimrod MRA4 ), descubrí el problema: el artículo P-1 usaba :*sangrías para los elementos individuales del armamento, pero debería haber usado solo *el nivel de sangría requerido. Hice ese cambio en el artículo P-1 y las viñetas dobles desaparecieron.

En otras palabras, esto es incorrecto y es probable que dé lugar a balazos dobles:

|misiles de punto duro=<br>:* cohete de botella

Esto es correcto y probablemente se reproducirá como se pretende:

|misiles de punto duro=<br>***cohete de botella

Esto puede resultar obvio para los editores con más experiencia que yo, pero me llevó un tiempo darme cuenta, así que pensé en documentarlo aquí. No creo que se trate de un problema con la plantilla en sí, sino (potencialmente) de un problema con el formato proporcionado por el usuario para algunos de los elementos de la plantilla.

¡Gracias! 73.185.200.182 ( discusión ) 02:28 17 dic 2023 (UTC) [ responder ]

Has identificado exactamente cuál era el problema. Lamentablemente, no hay mucho que podamos hacer para automatizar la detección, ya que se trata de una peculiaridad confusa incorporada en mediawiki. Si intentas hacer una búsqueda simple de una página con esta plantilla y mezclas dos puntos y asteriscos, la mayoría son falsos positivos. Agregué un enlace a WP:COLAS en la documentación, que creo que es nuestra mejor descripción de cómo hacer la sangría. -- Trialpears ( discusión ) 23:47, 18 de diciembre de 2023 (UTC) [ responder ]

Solicitud de edición: agregar enlace de relación de aspecto

¿Puede alguien con privilegios de administrador agregar el enlace Relación de aspecto (aeronáutica) a la etiqueta de relación de aspecto en la plantilla de especificaciones (o sugerir una forma alternativa)?

Gracias, -Fnlayson ( discusión ) 19:36 9 ene 2024 (UTC) [ responder ]

 Hecho *Pppery* ha comenzado... 15:20, 15 de febrero de 2024 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 15 de febrero de 2024

Por favor, arreglen el enlace "Nunca excedan la velocidad" para que vaya a V speeds § VNE en lugar de V speeds § Vne, que está escrito incorrectamente en mayúsculas , lo que no funciona porque los anclajes distinguen entre mayúsculas y minúsculas. ¡Gracias! DemonDays64 ( discusión • contribuciones ) 14:10 15 feb 2024 (UTC) [ responder ]

 Hecho *Pppery* ha comenzado... 15:20, 15 de febrero de 2024 (UTC) [ responder ]

Nota de velocidad máxima que sale en el lugar equivocado

Utilicé la "nota de velocidad máxima" por primera vez y descubrí que se imprime en la ubicación incorrecta. Si miras la fuente de Gloster P.370 , puse una altitud en la que se maximiza la velocidad. Esperaba que apareciera junto a la velocidad, por lo que diría algo como "Mach 1.82 a 36000 pies", pero en cambio, "a 36000 pies" aparece en la línea del título después de "Rendimiento". ¿Parece que esto es un error? Maury Markowitz ( discusión ) 15:44, 19 de marzo de 2024 (UTC) [ responder ]

Esto se debe a que se pone "a 36000 pies" en el parámetro "nota de velocidad máxima" sin poner ningún valor en "velocidad máxima kmh" o "velocidad máxima mph". Cuando solo se especifica el número de Mach, las notas se deben poner en el parámetro "nota de velocidad máxima de Mach". He corregido la plantilla en Gloster P.370 , pero creo que se debe hacer algo para evitar que aparezca el texto incluso cuando el parámetro MPH / km/h está oculto. - ZLEA T \ C 16:56, 19 de marzo de 2024 (UTC) [ responder ]

Agregar parámetro "número de hélice" para la cantidad de hélices

Este parámetro aún no se encuentra disponible. ¡Agréguelo lo antes posible! D4n2016 ( discusión ) 18:34 8 oct 2024 (UTC) [ responder ]

¿Por qué necesitamos el "número de hélices" cuando ya tenemos el número de motores? A lo largo de los años solo ha habido un puñado de aviones en los que esos dos números difieren (es decir, aquellos con hélices contrarrotativas impulsadas por el mismo motor) y estos están adecuadamente documentados (por ejemplo, el Shackleton) en el artículo correspondiente. No veo ninguna razón por la que esto sea un requisito, y mucho menos uno de ASAP. DaveReidUK ( discusión ) 21:51 8 oct 2024 (UTC) [ responder ]
De acuerdo, los parámetros de esta plantilla fueron cuidadosamente elegidos para lograr un equilibrio entre ser enciclopédicos y contener suficientes detalles para quienes los necesitan. Nimbus (Cumulus nimbus flotando) 08:33, 9 de octubre de 2024 (UTC) [ responder ]
Muchos lectores solo visitan los artículos sobre aeronaves por la sección de especificaciones, por eso. D4n2016 ( discusión ) 12:29 9 oct 2024 (UTC) [ responder ]
¿Cómo sabes que eso es cierto? E incluso si lo fuera, hay muchos aspectos de la configuración de una aeronave que están en el cuerpo del artículo pero no en la plantilla. ¿Deberíamos especificar en la plantilla si un tipo de aeronave tiene ala alta o baja, tren de aterrizaje triciclo, cola en T, etc.? No lo creo. DaveReidUK ( discusión ) 13:37 9 oct 2024 (UTC) [ responder ]
No creo que sea técnicamente posible indicar qué secciones específicas de los artículos visitan los lectores, las únicas estadísticas disponibles son las visitas a la página. La opinión generalizada es que la mayoría de los lectores solo ven la sección principal y el cuadro de información de los artículos sobre aeronaves. Agregar el número de hélices está fuera de lo que una enciclopedia general debería cubrir , las publicaciones especializadas como las monografías a menudo se encuentran en las secciones de referencia de los artículos para los lectores que desean saber todo sobre un tipo, aunque, hasta donde yo sé, nunca he visto el número de hélices enumeradas en las publicaciones que tengo . Nimbus (Cumulus nimbus flota) 14:39, 9 de octubre de 2024 (UTC) [ responder ]