stringtranslate.com

Discusión de plantilla:Navbox

Solicitud de edición (carga condicional del módulo:Navbar)

Suponiendo que no pasé por alto ningún problema (aunque los casos de prueba se ven bien), copie los cambios en Special:Diff/1235534036 a Module:Navbox . Esto carga condicionalmente Module:Navbar solo cuando la barra de navegación realmente se mostrará (es decir, cuando |navbar=no se usa, básicamente). Soy consciente de que podría hacer este cambio yo mismo, pero está más allá de lo que me siento cómodo haciendo en Module:Navbox, incluso con todos los casos de prueba que se ven bien, por lo que agradecería que alguien verificara dos veces el cambio real primero. Es sorprendentemente difícil mantener "navbox" y "navbar" en orden cuando estás hablando de ambos... 「ディノ奴千?!」☎ Dinoguy1000 19:53, 19 de julio de 2024 (UTC) [ responder ]

Se ve bien. Izno ( discusión ) 19:57 19 jul 2024 (UTC) [ responder ]
Como estamos actualizando el módulo, también moveré el display: noneque ha estado colgado en MediaWiki:Print.css a TemplateStyles, que es este diff. Izno ( discusión ) 20:34 19 jul 2024 (UTC) [ responder ]
 Done Izno ( discusión ) 19:25 22 jul 2024 (UTC) [ responder ]

Cómo hacer que los enlaces del título del cuadro de navegación se muestren en modo oscuro

solución propuesta

La siguiente solución debería solucionar el problema que se describe aquí. Tengo derechos de edición, pero quería una segunda opinión antes de aplicar estos cambios.

El problema se produce por una combinación de factores:

Mi solución propuesta es hacer esto en el nivel de plantilla.

Una alternativa que consideré fue agregar otra regla !important en MediaWiki:Vector-2022.css , pero creo que es preferible que la solución se encuentre en los estilos del cuadro de navegación. Con suerte, a largo plazo podremos trasladar la eliminación de color en WikimediaMessages a la plantilla del cuadro de navegación y todo esto será más fácil de seguir. 🐸  Jdlrobson ( discusión ) 18:57, 22 de julio de 2024 (UTC) [ responder ]

La tercera alternativa es resolver la tarea en Phab que nos permite desactivar el modo oscuro para componentes específicos, y luego podemos desactivarlo para navbox. Eso es algo que podría llevar una o dos horas como máximo. Izno ( discusión ) 19:10 22 jul 2024 (UTC) [ responder ]
Precisamente, esto es a lo que me refiero cuando digo "a largo plazo".
Esperamos que transcurra al menos un mes antes de que se implemente la solución, dados los otros compromisos del equipo web. Lamentablemente, hay problemas mucho más importantes que deben abordarse.
Sería bueno tener una solución a corto plazo mientras tanto. Podemos hacer referencia al ticket del fabricante en un comentario en línea y puedo asegurarme de que se deshaga cada vez que se trabaje en ese ticket. 🐸  Jdlrobson ( discusión ) 21:30, 22 de julio de 2024 (UTC) [ responder ]
¿Estoy leyendo el código correctamente y deduzco que el cambio se aplica solo a los enlaces en el título del cuadro de navegación? Si es así, ¿cuál es la solución para los enlaces visitados en el cuerpo del cuadro de navegación, que también se muestran en gris sobre negro para mí? Puede que esté leyendo el código de forma incorrecta. – Jonesey95 ( discusión ) 00:43, 23 de julio de 2024 (UTC) [ responder ]
¿Puedes darme una página de ejemplo @ Jonesey95 ? Pero sí, esto es solo para el título del cuadro de navegación, ya que ese era el único problema del que estaba al tanto.
Si hay otros elementos, se podrían utilizar las mismas reglas, sustituyendo th.navbox-title por el selector correspondiente. 🐸  Jdlrobson ( discusión ) 17:59 23 jul 2024 (UTC) [ responder ]
Parece que mi memoria está mal. Volví a {{ Soulfly }} y solo el título de la barra de navegación superior y el título del subtítulo donde los enlaces visitados se vuelven grises en lugar de morados. Continúe. – Jonesey95 ( discusión ) 18:03, 23 de julio de 2024 (UTC) [ responder ]
En lo que supongo que es un problema relacionado con CSS, en {{ Malawian roads }} , veo enlaces a artículos en azul o rojo si no existen en modo claro, pero solo en azul en modo oscuro. Por ejemplo, la carretera M26 (Malawi) no existe, pero aparece en azul en modo oscuro. -- Beland ( discusión ) 20:36 2 ago 2024 (UTC) [ responder ]
FTR, obtener una vista previa de {{ Malawian roads }} y cambiarla para que apunte a {{ Navbox/sandbox }} no solucionó el problema del color del enlace rojo. -- Beland ( discusión ) 20:41 2 ago 2024 (UTC) [ responder ]
 No lo he hecho por ahora: he corregido esto en la plantilla en cuestión basándome en el soporte upstream para el enlace automático a Vector-2022/Minerva.css. Si hay otros (sospecho que puede haberlos), podemos discutirlos entonces. Izno ( discusión ) 17:39, 5 de septiembre de 2024 (UTC) [ responder ]
¡Gracias por la solución! Ahora se ve bien en las carreteras de Malawi . -- Beland ( discusión ) 05:45 6 sep 2024 (UTC) [ responder ]

Texto gris sobre fondo blanco

Al editar un cuadro de navegación, todo lo que NO sea un enlace se muestra en texto gris sobre un fondo blanco. Antes no era así. ¿Alguien sabe cómo solucionar esto? -- Jax 0677 ( discusión ) 22:20 23 jul 2024 (UTC) [ responder ]

Representar directamente los cuadros de navegación secundarios

Muchos artículos exceden el límite de tamaño de inclusión posterior a la expansión debido a que los cuadros de navegación ocupan una gran cantidad de bytes. Gran parte de esto se debe a los cuadros de navegación que incluyen cuadros de navegación secundarios, porque anidar una plantilla de cuadro de navegación dentro de otra plantilla de cuadro de navegación hace que el cuadro de navegación interno se cuente dos veces para el límite (y si está utilizando la plantilla en lugar del módulo directamente, en realidad cuenta 4 veces). Para aliviar esto, he modificado Module:Navbox/sandbox para permitir que se agreguen cuadros de navegación secundarios sin tener que agregar una llamada de plantilla adicional o una invocación de módulo. Por ejemplo, en lugar de

{{ Navbox | nombre =  {{ subst : NOMBREPAGINA }} | título = Título | lista1 =  {{ Navbox | hijo | grupo1 = Grupo1.1 | lista1 = Lista1 }} | lista2 =  {{ Navbox | hijo | grupo1 = Grupo2.1 | lista1 = Lista1 }} } }

Podrías hacerlo

{{ Navbox | nombre =  {{ subst : NOMBREPAGINA }} | título = Título | lista1 = hijo | lista1_grupo1 = Grupo1.1 | lista1_lista1 = Lista1 | lista2 = hijo | lista2_grupo1 = Grupo2.1 | lista2_lista1 = Lista1 }}

El código solo se activa si el texto de list# es la palabra clave "hijo" Y se especifica al menos un parámetro que comienza con "list#_". El resultado es un tamaño de inclusión posterior a la expansión drásticamente menor y, en mi opinión, un código más fácil de leer. Por supuesto, el método antiguo, o una combinación de los dos, todavía funciona, como se demuestra en User:Ahecht/sandbox4 . ¿Alguna idea antes de que haga una solicitud de edición formal? -- Ahecht (
PAGINA DE DISCUSION
)
20:08, 30 de julio de 2024 (UTC) [ responder ]

He pensado en hacerlo de forma similar a esto. Creo que preferiría ver algo como esto list1.1, group1.1que es un poco más corto y probablemente no genere un código muy diferente.
No estoy completamente seguro de que debamos optar por ello child, pero estoy bastante seguro de que esto se podría hacer sin la palabra clave adicional. Izno ( discusión ) 20:16 30 jul 2024 (UTC) [ responder ]
@ Izno Entonces, un cuadro de navegación secundario en la "lista 4" usaría group1.4, list1.4, group1style.4, image.4, o sería group4.1, list4.1, group4style.1, image4, etc. Si es lo primero, no debería ser más difícil de codificar, aunque no tiene la misma sangría natural y el orden jerárquico no es lo que la mayoría de la gente esperaría (aunque usar 4.group1, 4.list1, etc. soluciona ese problema). Si es lo último, el código ciertamente sería más complicado ya que algunos argumentos estarían delimitados, otros no, y el número a extraer está en un lugar diferente en diferentes variables. También dificultaría la conversión de cuadros de navegación existentes.
Tienes razón en que no es necesario optar por la childpalabra clave: podríamos escanear los argumentos en busca de los delimitados, extraer el número de lista y agregarlo a listnums. La única razón por la que lo incluí es que hace que sea claramente visible para alguien que crea o edita una plantilla de cuadro de navegación que ese número de lista ya está tomado, lo que debería hacer que sea menos probable que agreguen texto accidentalmente a ambos list#y especifiquen parámetros para un hijo. -- Ahecht (
PAGINA DE DISCUSION
)
20:58, 30 de julio de 2024 (UTC) [ responder ]
Estoy un poco más a favor del estilo, ya que permitirá distinguir visualmente los grupos (sobre todo si están alineados). Primefac ( discusión ) 11:57 31 jul 2024 (UTC) [ responder ]listx_listy
Lo que estoy pensando es que he visto 3 o incluso 4 capas de cuadros de navegación, por lo que list1_group1_list1_group1_list1_group1se vuelve un poco difícil de manejar. :) En realidad, ¿la implementación funciona para el caso de más capas? Izno ( discusión ) 15:52, 31 de julio de 2024 (UTC) [ responder ]
Hrm, buen punto. Primefac ( discusión ) 16:04 31 jul 2024 (UTC) [ responder ]
@ Izno , Primefac La implementación es recursiva, por lo que funciona con listas anidadas (agregué un ejemplo a User:Ahecht/sandbox4 ), aunque "solo" sería list1_list1_list1_group1. Cuanto más lo pienso, más me desagrada la list1_list1notación (ya que en ese momento no es realmente una lista) y me inclino por child1_list1/ subgroup1_list1como más descriptiva o simplemente 1_list1como más concisa. -- Ahecht (
PAGINA DE DISCUSION
)
16:47 31 julio 2024 (UTC) [ responder ]
He actualizado el sandbox en Special:Permalink/1239318936 para aceptar la notación child1_list1, subgroup1_list1, y 1_list1, como se muestra en User:Ahecht/sandbox4 . Actualmente requiere las palabras clave childo subgroup, pero ese requisito podría eliminarse potencialmente en una actualización futura. También hice que la función que lee los argumentos sea recursiva para mantener las referencias en el orden correcto incluso cuando se usan hijos/subgrupos. -- Ahecht (
PAGINA DE DISCUSION
)
13:53, 8 de agosto de 2024 (UTC) [ responder ]
 Listo . Seguí adelante e implementé esto. ¡Espero no haber roto el 8% de Wikipedia! -- Ahecht (
PAGINA DE DISCUSION
)
18:03, 16 de agosto de 2024 (UTC) [ responder ]
zh:Module:NavboxV2 ya logró renderizar directamente los cuadros de navegación secundarios hace cuatro años y se integró con {{ Navbox con columnas }} / {{ Navbox con grupos colapsables }} (a través del |type=parámetro). Dabao qian ( discusión ) 05:52 8 sep 2024 (UTC) [ responder ]
@ Dabao qian He consolidado las tres plantillas en Module:Navbox/sandbox . Puedes configurar |type=(o |1_type=) como "con columnas" o "con grupos colapsables". Para {{ Navbox con columnas }}, utiliza la notación "col1_list1" para los subgrupos de las columnas. Consulta Template:Navbox/testcases#allthreetypes para ver un ejemplo. -- Ahecht (
PAGINA DE DISCUSION
)
01:14 2 octubre 2024 (UTC) [ responder ]
Vale, parece la versión china. Establezca |type=(el valor predeterminado es "vertical") en "horizontal" o "vertical_collapsible" para cambiar {{ Navbox con columnas }} o {{ Navbox con grupos colapsables }} . Dabao qian ( discusión ) 13:10 2 oct 2024 (UTC) [ responder ]
@ Dabao qian Las palabras clave exactas que se utilizan se pueden configurar en Módulo:Navbox/configuration/sandbox como keyword.with_collapsible_groupsy keyword.with_columns. Elegí "con columnas" y "con grupos colapsables" porque hemos estado usando los nombres {{ navbox with column }} y {{ navbox with collapsible groups }} en la Wikipedia en inglés durante los últimos 7 años, por lo que esos términos son más familiares que "horizontal" y "vertical_collapsible" (además, permite reemplazar {{ navbox with column }} con {{ #invoke:navbox |with column}}). -- Ahecht (
PAGINA DE DISCUSION
)
17:04, 2 de octubre de 2024 (UTC) [ responder ]
He copiado este módulo en zh-yuewiki (ver yue:Module:NavboxV2) y lo he modificado para que sea compatible con zh:Module:NavboxV2. Pero, ¿cómo se pueden utilizar ambos? |1_border=Dabao qian ( discusión ) 17:18 2 oct 2024 (UTC) [ responder ]|list1=[child/subgroup]
@ Dabao qian Nunca deberías necesitar usar |1_border=. Si usas |list1=subgroup, el módulo establece automáticamente |1_border=subgroupsin que tengas que especificarlo (también establece automáticamente |1_navbar=plain). También puedes seguir usando el método antiguo, por lo que debería producir el mismo resultado que . -- Ahecht ({{#invoke:NavboxV2|navbox|list1=subgroup|1_list1=List 1}}{{#invoke:NavboxV2|navbox|list1={{#invoke:NavboxV2|navbox|border=subgroup|navbar=plain|list1=List 1}}}}
PAGINA DE DISCUSION
)
00:48, 8 de octubre de 2024 (UTC) [ responder ]
Como autor de NavboxV2, finalmente veo que enwiki también tiene el problema de sobrecarga de Navbox, que es similar al de zh y necesita una solución. Me siento conmovido. (LOL)
Respecto al problema del modo de parámetro:
  • Para el separador, elegí "-" (guión corto) y usted eligió "_" (guión bajo). Esta es una elección personal y no planeo hacer compatibilidad aquí. Principalmente involucra la incertidumbre de la detección de parámetros (tanto los guiones como los guiones bajos deben detectarse al mismo tiempo), algunos problemas de codificación rígida (algunos códigos solo usan guiones como el valor de la búsqueda de parámetros entrantes) y mi pereza;
  • Para la detección de subcuerpos, no lo uso listN=childporque el código de detección de subcuerpos del borderparámetro se puede reutilizar y, al mismo tiempo, se puede evitar la incertidumbre de la detección de parámetros (es necesario adivinar si el "hijo" de listN=childes el valor de marca del subcuerpo o el valor del contenido de la lista ordinaria. Y el primero también requiere más código de detección de parámetros del subcuerpo);
  • Con respecto a agregar parámetros tipo "lista", como "hijo" y "subgrupo", de manera similar, dado que la mayor parte de la estructura del código de {{ Navbox }} se copia, la posición del código del valor de la "lista" original, el nombre del parámetro es simplemente "lista", así que manténgalo simple y no agregue demasiada incertidumbre de entrada adicional.
El código de NavboxV2 no está integrado en Navbox, sino que se crea una nueva plantilla. Esto se debe a que no soy un administrador local y no puedo actualizar el código de Navbox a voluntad. Además, la nueva plantilla puede depurar y corregir el código en cualquier momento para evitar afectar el funcionamiento normal de Navbox.
Estaré atento a tu trabajo e intentaré ver si hay algo interesante que pueda inspirarme. -- Cwek ( discusión ) 09:35 9 oct 2024 (UTC) [ responder ]

Modo oscuro con borde blanco

En el modo oscuro, en todos los cuadros de navegación, el borde se ve así: ¿Hay alguna forma de solucionar esto para que los bordes se vean correctamente? Es un problema menor, pero que afecta a muchos artículos. —  Qwerfjkl talk 11:32, 7 de agosto de 2024 (UTC) [ responder ]

Los bordes blancos se utilizan para distinguir las filas pares e impares de la lista. Dabao qian ( discusión ) 05:57 8 sep 2024 (UTC) [ responder ]
Sin embargo, no deberían ser bordes visibles, especialmente si son de un blanco brillante como ese. Los bordes deberían tener el mismo color que los demás bordes grises. Esto se puede solucionar en las reglas CSS para el modo oscuro, si alguien con la capacidad de editarlo pudiera hacerlo. Down10  TA CO 07:52, 8 de octubre de 2024 (UTC) [ responder ]

Visibilidad móvil

Hola a todos,

No quería ser demasiado exagerado y eliminar la información que indica que la plantilla no es visible en dispositivos móviles, aunque lo comprobé hace un segundo y sí lo es. También revisé el informe de Phab vinculado en el encabezado como parte de una edición a otra página y parece que el problema se ha resuelto al menos parcialmente.

Si alguien estaría dispuesto a actualizar la página para reflejar los cambios recientes, o alternativamente decirme que estoy completamente equivocado, ¡háganmelo saber!

YuxtaposedJacob ( discusión ) | :) | 01:10 18 oct 2024 (UTC) [ responder ]

Los cuadros de navegación no suelen ser visibles en dispositivos móviles. Remsense  ‥ 01:28, 18 de octubre de 2024 (UTC) [ responder ]
Fascinante, puedo ver los de mi página de usuario en el móvil, pero no los del espacio del artículo.
¡Gracias!
YuxtaposedJacob ( discusión ) | :) | 04:23 18 oct 2024 (UTC) [ responder ]
Ahora son visibles fuera del espacio principal, por lo que probablemente debería haber un refinamiento para brindar información correcta. Izno ( discusión ) 18:13 18 oct 2024 (UTC) [ responder ]