stringtranslate.com

Discusión de Wikipedia:Desambiguación

sobre cómo deberían verse las estadísticas para las notas de sombrero, las redirecciones principales y los temas principales

Aquí hay más información que he recopilado después de que alguien preguntó en Talk:Tupelo :

Creo que tendré que seguir actualizando este resumen aquí para crear una base de conocimientos. -- Joy ( discusión ) 15:19, 1 de marzo de 2024 (UTC) [ responder ]

-- Joy ( discusión ) 14:44 6 abr 2024 (UTC) [ responder ]
-- Joy ( discusión ) 18:05 10 may 2024 (UTC) [ responder ]
-- Joy ( discusión ) 06:55 5 jun 2024 (UTC) [ responder ]
-- Joy ( discusión ) 16:37 11 jul 2024 (UTC) [ responder ]
-- Joy ( discusión ) 13:25 5 sep 2024 (UTC) [ responder ]

Esto no quiere decir que todas estas medidas estuvieran verdaderamente justificadas o que no haya una plétora de factores individuales en juego. Pero incluso con esta variedad de resultados, hay algo claramente fuera de lugar en nuestra interpretación actual, casi consensuada, de cómo deberían ser las estadísticas para los temas principales según el uso. Esto también significa poco para las consideraciones de importancia a largo plazo. -- Joy ( discusión ) 15:30, 1 de marzo de 2024 (UTC) [ responder ]

Tus cifras sobre el porcentaje de "interés" son bastante engañosas, ya que no mencionan que, en muchos casos, el porcentaje más grande, con diferencia, fue "sin tráfico en absoluto", es decir, sin clics, por la razón que sea (¿visitas que no fueron de humanos? ¿El objetivo deseado no está disponible? ¿La información en la página de desambiguación es suficiente?). Por ejemplo, en el caso de Hamme, señalas que "después del traslado, el tema principal que se suponía anteriormente obtuvo un interés de aproximadamente el 16%", que fue más de 4 veces más que los otros temas "combinados". Fram ( discusión ) 14:51, 11 de abril de 2024 (UTC) [ responder ]
Sí, lo he mencionado varias veces. Estoy de acuerdo en que es engañoso simplemente asumir que cada visita entrante cuenta para algo significativo. La verdad es que no hay forma de que sepamos qué significan, si es que significan algo, esas visitas entrantes a la página que no tienen salida. olderwiser 15:34, 11 de abril de 2024 (UTC) [ responder ]
@Bkonrad Exactamente , pero no es exactamente que no sepamos que no significan nada . Hay múltiples indicios de que sí lo significan:
En primer lugar, hay una gran variedad de casos, desde aquellos en los que vemos que muchas de las visitas entrantes se traducen en clics hasta aquellos en los que vemos que pocas visitas entrantes se traducen en clics. No resumí toda esa información en esta página de discusión, tienes que hacer clic en los enlaces para examinarla. (Es posible que más adelante encuentre algo de tiempo para extraer esa dimensión de datos y ampliar la lista anterior).
Esto significa que no solo vemos tráfico fantasma de manera constante, sino que debemos observar el comportamiento real de los lectores al menos hasta cierto punto. Por lo tanto, no podemos ver, por ejemplo, que el 60 % del tráfico se traduce en clics en un caso nuevo y luego llegar a la conclusión de que la mayor parte del 40 % restante se puede ignorar.
En segundo lugar, hay casos en los que vemos que casi todas las visualizaciones entrantes se traducen en clics. El ejemplo más reciente que encontré se describe en Talk:Forced march#post move to disambiguation , donde nuestra tasa de identificación pasó de 34/55 (~62 %) en el primer mes observado, a 96/96, a 95/95, a 135/135 en los últimos tres meses, sorprendentemente, incluso con una cantidad tan pequeña de tráfico.
Esto niega incluso la idea de que siempre tiene que haber al menos algo de este tráfico fantasma, porque aparentemente tenemos un escenario de falsificación que parece bastante consistente. Por lo tanto, no podemos simplemente ver, por ejemplo, que el 75 % del tráfico se traduce en clics y luego llegar a la conclusión de que cualquier parte del 25 % restante es ignorable.
-- Joy ( discusión ) 12:33 14 abr 2024 (UTC) [ responder ]
Cabe señalar que, desde entonces, hemos observado que la marcha forzada recibe más clics salientes que entrantes. Ese es otro escenario que no podemos explicar: los mismos lectores haciendo clic en varios elementos de una lista. -- Joy ( discusión ) 08:48, 18 de julio de 2024 (UTC) [ responder ]
Sobre los puntos individuales planteados por @Fram anteriormente :
  • meta:Investigación:Wikipedia clickstream dice que intenta excluir visitas que no sean de humanos: Intentamos excluir el tráfico de arañas clasificando los agentes de usuario con la biblioteca ua-parser y algunos filtros específicos de Wikipedia adicionales. Es posible que no lo consiga, pero entonces es probable que también falte la categoría de visitas a la página "Usuario", por lo que no sé si deberíamos confiar en que ese sea un efecto importante.
  • El objetivo buscado no está disponible: ¿cómo mejoraría esto las probabilidades de que se afirme que debería haber un tema principal, cuando habría temas que restarían valor a la existencia de un tema principal y ni siquiera están disponibles? Eso parecería aumentar el riesgo de sorprender a más contingentes de lectores. "Estas personas ni siquiera saben acerca del significado X, y proclamaron que el significado Y es el principal - ¡pfft!"
  • La información sobre la página de desambiguación es suficiente: este caso de uso no se ha estudiado en absoluto y estoy de acuerdo en que parece posible al menos en algunos casos. En definitiva, ¿por qué consideraríamos malas todas las navegaciones que no resulten en otro clic? Es decir, seguramente esto también resta valor a la idea de que exista un tema principal, si también existe el contingente de lectores a los que no podemos convencer de hacer clic en el enlace para leer sobre el tema principal propuesto (que también suele ser el primer enlace de la lista).
  • Más de 4 veces que los otros temas combinados. Ya expliqué en Talk:Hamme (desambiguación) cómo estás haciendo afirmaciones extrañamente incorrectas. Incluso si comparamos 28 flujos de clics identificados y los 10 flujos de clics identificados, la relación entre esos dos números es 2,8, simplemente no es 4. Del mismo modo, tanto 28 como 10 están tan cerca del umbral de anonimización que no está del todo claro que esta relación tenga que ser precisa. En otras palabras, esto podría haber sido 4 o podría haber sido 2 con solo unos pocos pares de vistas src-dest más identificados en lugar de anonimizados. Y ninguna de estas relaciones es impresionante cuando también vemos mucho más tráfico interesado en ninguno de estos.
En cualquier caso, gracias por el interés. -- Joy ( discusión ) 12:33 14 abr 2024 (UTC) [ responder ]
Sí, no digo que se deba ignorar por completo el recuento de visitas entrantes, solo que tratar de interpretar lo que significa es altamente especulativo y debemos ser muy cautelosos con el significado que atribuimos a esas visitas sin salida. Si hay un cambio repentino en el número de visitas entrantes, es probable que merezca una mayor consideración. De manera similar, si hay una brecha constante y muy grande entre las visitas entrantes y salientes, eso también puede merecer cierta consideración. Pero incluso en esos casos, decidir qué buscaban los lectores que llegan a esas visitas sin salida al llegar a una página de desambiguación en particular sigue siendo altamente especulativo. Podría ser un factor a la hora de argumentar que no hay un tema principal donde no lo hay en este momento (es decir, cuando hay una solicitud para reemplazar una página de desambiguación con un tema principal). No estoy seguro de qué significado podríamos interpretar en esas visitas sin salida de una página de desambiguación donde existe un tema principal. Podría ser que los lectores simplemente sientan curiosidad por saber qué más podría tener el mismo nombre, sin la intención de mirar ninguno de ellos con más detalle. Simplemente no sabemos por qué esos lectores se comportan de esa manera. mayoresmás sabios 13:46, 14 de abril de 2024 (UTC) [ responder ]
De acuerdo, el cambio de patrón sería un indicador significativo. Pero en ese sentido, vuelvo a señalar la evidencia anterior: a menudo observamos un patrón claramente consistente y luego hacemos un cambio por cualquier razón, y luego los datos cambian y observamos un patrón consistente claramente diferente . Bueno, a menudo se necesitan algunos meses para que las cosas se estabilicen y, en el período intermedio, hay uno o dos cambios, pero aún así.
En los casos en los que ya se ha seleccionado un tema principal, es muy difícil interpretar el tráfico que no genera clics. Como el contenido es más extenso y variado, podría tratarse de varias posibilidades. Así como podrían ser lectores que navegan de forma incorrecta y hacen clic para irse de inmediato, también podrían ser lectores que se quedaron y aprendieron algo y luego hicieron clic para irse, o podría ser un grupo de lectores completamente satisfechos que estaban absolutamente felices de leer lo que tenían frente a ellos y no tenían necesidad de aprender de inmediato más sobre otro tema relacionado. No tenemos las herramientas para discernir esto.
Sin embargo, con páginas más simples como las listas de desambiguación, es menos difícil comprender el comportamiento general del lector porque no presentamos a las personas grandes cantidades de posibilidades, reducimos ese número y simplificamos sus opciones, y hacemos más probable que podamos comprender las mediciones de nuestras herramientas existentes.
Lo que creo que deberíamos aprender de todo esto es que no debemos ser demasiado cautelosos y, en cambio, no deberíamos tener miedo de experimentar tanto como lo hemos hecho hasta ahora.
En todos los datos que he rastreado, aún no hemos observado un caso en el que haya habido un lector nuevo que se quejara de que las listas de desambiguación son la opción incorrecta. Mientras apliquemos MOS:DABCOMMON , y lo hacemos, no tenemos ninguna indicación de que estemos confundiendo o preocupando a una cantidad apreciable de lectores, incluso en casos polémicos. -- Joy ( discusión ) 14:35, 14 de abril de 2024 (UTC) [ responder ]
En todos los datos que he rastreado, todavía no hemos observado ningún caso en el que un lector nuevo se quejara de que las listas de desambiguación fueran la opción incorrecta. Este parece un criterio peculiar. Dejando de lado las reacciones a las listas que has estado recopilando, no recuerdo la última vez que me encontré con un lector "nuevo" quejándose de una página de desambiguación ubicada incorrectamente, cuando el denunciante no era un partidario miope que buscaba promover su tema preferido.
En cuanto a lo que creo que deberíamos aprender de todo esto es que no debemos ser demasiado cautelosos y, en cambio, no deberíamos tener miedo de experimentar tanto como lo hemos hecho hasta ahora. Me alegra que estés profundizando en los datos, pero espero que nadie se esté engañando al pensar que los montones de datos de calidad incierta basados ​​en funciones mal documentadas representan un enfoque consensuado para tomar decisiones. olderwiser 16:02, 14 de abril de 2024 (UTC) [ responder ]
En realidad, también tenemos algunos puntos de datos interesantes sobre eso, cf. Talk:Tito (desambiguación) , donde nadie prestó realmente atención durante más de una década mientras se implementaba la desambiguación, y luego un consenso de editores prácticamente instantáneamente decidió aplicar una redirección de tema principal principalmente por su importancia a largo plazo. (El lado positivo es que ese cambio nos permitió medir algo más después, Wikipedia talk:Disambiguation/Archive 56# sobre la calidad de los datos de uso de visitas a la página y del flujo de clics explica más).
Estoy bastante seguro de que si analizamos otros casos también podemos encontrar marcos temporales similares, donde alguna elección de navegación arbitraria ha estado vigente durante años y décadas, y luego decidimos arbitrariamente congregarnos, tomar decisiones nuevas y divertidas y darnos palmaditas en la espalda colectivamente :)
En otras palabras, nuestro proceso de toma de decisiones parece perfectamente sólido (en su mayoría, también para mí, no me excluyo), pero se nos escapan tantas cosas que es dudoso que gran parte de él realmente importe tanto como creemos. -- Joy ( discusión ) 16:49, 14 de abril de 2024 (UTC) [ responder ]

¿Qué significa "en determinadas circunstancias" enWP: Hermanastra

¿No sería útil definir qué significan las palabras " en determinadas circunstancias " en WP:DABSISTER ? o (mejor aún) ¿ofrecer ejemplos de cuándo sería útil un enlace a una Wikipedia en un idioma extranjero y cuándo no?
Lo intentaría, pero no tengo idea de qué significan esas palabras. The Mountain of Eden ( discusión ) 20:53 16 jul 2024 (UTC) [ responder ]

Mi opinión es que deberíamos evitar los enlaces a artículos de Wikipedia en otros idiomas… en lugar de eso, deberíamos crear artículos aquí y enlazarlos. Blueboar ( discusión ) 15:01 28 jul 2024 (UTC) [ responder ]

Definición propuesta utilizando la existencia de políticas de control de calidad de Verificación, Notabilidad y Neutralidad

Dado que nadie ha proporcionado una definición para " bajo ciertas circunstancias ", ¿qué tal esta definición?:
En los casos para los que no existe un artículo para un término de desambiguación en la Wikipedia en inglés pero existe un artículo en una Wikipedia en un idioma diferente, es aceptable usar la {{interlanguage link}} plantilla para vincular al artículo en el proyecto hermano, con el término de desambiguación contando como un enlace azul (por lo que no sería necesario un enlace azul adicional para la entrada) solo si el proyecto hermano tiene políticas de verificabilidad, notabilidad y neutralidad.

(La tabla aún necesita ser completada - yo solo completé los primeros 25 espacios en blanco de la tabla). La Montaña del Edén ( discusión ) 01:46 22 jul 2024 (UTC) [ responder ]

Apoyo

Oponerse a

Discusión

No parece necesario. No se ha demostrado que exista un problema real con el texto actual, que permite cierta flexibilidad según el caso. Remsense诉01:50, 22 de julio de 2024 (UTC) [ responder ]
Esto también pasa por alto una razón principal para no incluir ills: incluso en wikis que tienen estándares vnn, no todos los artículos en dicha wiki cumplen con esos estándares. Basta con echar un vistazo a la cantidad de basura que existe en la wiki en inglés, que supuestamente tiene altos estándares. Y además de eso, la mera existencia de un artículo en una wiki en otro idioma no proporciona ninguna indicación de si ese mismo tema tiene alguna relevancia en inglés. Pensé que la última discusión sobre esto determinó que, como mínimo, el término debe mencionarse en un artículo actual para proporcionar al menos alguna sugerencia minúscula de que el tema tiene alguna vigencia en inglés. olderwiser 03:16, 22 de julio de 2024 (UTC) [ responder ]
Así como la notoriedad no es una función del tiempo , no creo que sea una función del lenguaje utilizado para escribir el artículo. Pero sí es una función de las personas que participan en la discusión, por lo que el consenso puede cambiar . Por eso creo que deberíamos tener una política clara, para que haya coherencia. La redacción actual de WP:DABSISTER no tiene sentido para mí, y en 5 días nadie fue capaz de proporcionarme un significado para ella. Por eso propuse algo que tiene sentido.
Si bien es obvio que tener políticas de verificabilidad, notabilidad y neutralidad no garantiza que todos y cada uno de los artículos cumplan plenamente con las políticas, es mejor que no tener políticas. Por eso lo propuse en lugar del vago "en determinadas circunstancias". The Mountain of Eden ( discusión ) 06:51 22 jul 2024 (UTC) [ responder ]
No estoy de acuerdo, ya que la notoriedad depende en gran medida del idioma y la cultura. En esencia, su propuesta da luz verde a la inclusión de ills en todos los artículos de otros idiomas que tengan algún tipo de estándares de vnn, independientemente de si un término determinado tiene algún uso en inglés. olderwiser 10:56, 22 de julio de 2024 (UTC) [ responder ]
La política de notabilidad de Wikipedia dice que la notabilidad se establece con la cobertura de " fuentes confiables e independientes ". ¿Cómo dependería eso del idioma y la cultura? The Mountain of Eden ( discusión ) 02:56 23 jul 2024 (UTC) [ responder ]
Este no es realmente el foro adecuado para discutir la relevancia de temas en lenguas extranjeras en la Wikipedia en inglés. El concepto de desambiguación surge dentro de una wiki de idioma cuando hay más de un tema que podría tener el mismo título. Si no existe información sobre un tema en lengua extranjera en la Wikipedia en inglés, no hay nada que desambiguar. olderwiser 03:40, 23 de julio de 2024 (UTC) [ responder ]
Estoy de acuerdo en que es necesaria una desambiguación " cuando hay más de un tema que podría tener el mismo título ". La cuestión es qué hacer cuando no hay ningún artículo en la Wikipedia en inglés. Tenemos MOS:DABRED para gestionar eso. Pero en los casos en los que hay un artículo, pero que no está en la Wikipedia en inglés, eso lo gestiona WP:DABSISTER . El lenguaje actual en WP:DABSISTER con las palabras " en determinadas circunstancias " es ambiguo en el mejor de los casos y sin sentido en el peor. La idea es limpiar el lenguaje para dar una guía clara. The Mountain of Eden ( discusión ) 16:48, 23 de julio de 2024 (UTC) [ responder ]
Para colmo de males, hay una nota a pie de página en WP:DABSISTER que dice " No hay acuerdo sobre las condiciones en las que tales enlaces son aceptables ". Por lo tanto, deberíamos pensar en algo . Incluso si no es perfecto, podría mejorarse más adelante. The Mountain of Eden ( discusión ) 16:52 23 jul 2024 (UTC) [ responder ]
Buena suerte en llegar a ese acuerdo. Las discusiones anteriores fueron largas con partidarios más o menos intransigentes. Creo que, como ocurre con muchas cosas en Wikipedia, las pautas no pueden prescribir con precisión qué hacer en cada situación y algunas cosas es mejor dejarlas para discusiones caso por caso. No creo que sea sensato asumir ningún tipo de equivalencia entre artículos en Wikipedias de varios idiomas. Con la pauta que propones, sería muy fácil tener páginas de dab repletas de entradas de ILL para cualquier otro idioma que tenga alguna semejanza con las pautas de VNN (independientemente de cuán rigurosamente se sigan dichas pautas en la práctica). Mi opinión es, esencialmente, que las páginas de desambiguación están pensadas para desambiguar artículos en el idioma específico de esa Wiki. Es decir, no hay conflicto de títulos entre los artículos en la wiki en inglés y en cualquier otro idioma. Cada una puede tener diferentes artículos con exactamente el mismo título sin ningún conflicto. Si un término extranjero tiene alguna relevancia para el inglés, debería haber algunas indicaciones dentro de la Wiki en inglés (es decir, el término al menos se menciona en algún lugar de algún artículo). olderwiser 17:54, 23 de julio de 2024 (UTC) [ responder ]
Las directrices no pueden prescribir con precisión qué hacer en cada situación ”. Estoy totalmente de acuerdo contigo.
[A]lgunos asuntos es mejor dejarlos para que se analicen caso por caso . También estoy de acuerdo con eso. El problema es que la redacción actual en WP:DABSISTER , especialmente la nota a pie de página, es tan inútil que es mejor no tener nada y tratar el caso de un enlace rojo en la Wikipedia en inglés y un enlace azul en la Wikipedia en otro idioma como cualquier otro enlace rojo.
Si pensamos que un enlace rojo en la Wikipedia en inglés con un enlace azul a una Wikipedia en un idioma extranjero debería manejarse de forma diferente a un enlace rojo normal, deberíamos explicar qué hacer en tal caso, en lugar de decir que no hay consenso sobre qué hacer.
Puede que mi propuesta no sea perfecta, pero al menos es algo. Si la ponemos en la página, puede que surjan futuros editores con ideas sobre cómo mejorarla. La Montaña del Edén ( discusión ) 21:14 24 jul 2024 (UTC) [ responder ]
No creo que deba manejarse de manera diferente a otros enlaces rojos. No creo que los artículos en wikis en idiomas extranjeros deban tratarse como equivalentes a los artículos en inglés para enlaces azules en entradas de DAB. En mi opinión, debería haber un artículo en inglés existente que mencione el término. olderwiser 22:53, 24 de julio de 2024 (UTC) [ responder ]
Suena bien. Si nadie más contribuye a esta discusión en los próximos 4 o 5 días, lo consideraremos un consenso y cambiaremos la página del proyecto en consecuencia. The Mountain of Eden ( discusión ) 23:24 24 jul 2024 (UTC) [ responder ]
¿Qué cambiarías si no es lo que propusiste originalmente? más viejomás sabio 23:28 24 jul 2024 (UTC) [ responder ]
Buena pregunta. Ver más abajo La Montaña del Edén ( discusión ) 23:47 24 jul 2024 (UTC) [ responder ]

Propuesta #2

Cambie el texto de WP:DABSISTER por lo siguiente:

Si un artículo no existe en la Wikipedia en inglés, pero sí en un proyecto hermano, es probable que esto sea una indicación de que se debería crear un artículo en la Wikipedia en inglés. Sin embargo, al final del día, según WP:WRITEITFIRST , hasta que se cree un artículo en la Wikipedia en inglés, el término que se va a desambiguar se debe tratar como se prescribe en WP:DABRED .


La Montaña del Edén ( discusión ) 23:47 24 jul 2024 (UTC) [ responder ]

Apoyo

Oponerse a

Me parece que la existencia de la sección dabsister es principalmente una disposición de seguridad para garantizar que las personas no eliminen esos enlaces externos de {{ ill }} ya que no permitimos enlaces externos de otra manera.
En general, recomendaría pensar en esto desde la perspectiva del lector primero : para grandes contingentes de lectores angloparlantes, incluso agregar enlaces entre idiomas no es útil y posiblemente pueda resultar confuso, porque podrían hacer clic en el enlace azul esperando continuar leyendo en inglés. Permitir estos enlaces ya es bastante generoso, pero exigir que se cumpla algún otro estándar (como dabmention) es más seguro. -- Joy ( discusión ) 11:57, 28 de julio de 2024 (UTC) [ responder ]

Discusión

Creo que es incorrecto decir que es probable que se indique que se debe crear un artículo en la Wikipedia en inglés . La mera existencia de un artículo en otro idioma no dice nada sobre si el artículo debe crearse en la Wikipedia en inglés. ¿Y qué sucede con la nota al pie que proporciona un ejemplo de cómo debe construirse la entrada (que, por cierto, cumple con MOS:DABRED )? olderwiser 00:28, 25 de julio de 2024 (UTC) [ responder ]

Podemos reemplazar "es probable que sea una indicación" por "puede ser una indicación". La Montaña del Edén ( discusión ) 05:36 25 jul 2024 (UTC) [ responder ]
Creo que la redacción actual probablemente funcione bien: en casi todos los casos será posible un enlace azul a un artículo que mencione el tema, pero puedo imaginar casos ocasionales en los que haya un término ambiguo, que se confunda fácilmente con un tema en Eng.wiki, que esté presente en otra wikipedia pero no (todavía) en en.wiki y donde no haya un lugar obvio para agregar un enlace azul de fuente confiable.
Tal vez haya un poeta canadiense recientemente añadido a en.wiki, con una combinación de nombre y apellido en común, y un poeta alemán con el mismo nombre pero con una fecha de nacimiento y biografía claramente diferentes en de.wiki. Es útil para nuestro lector incluir un enlace wiki al poeta alemán junto con la entrada del poeta canadiense del mismo nombre, aunque el poeta alemán no se menciona en nuestra Lista de poetas en idioma alemán y no podemos esperar que el editor que acaba de crear un artículo sobre el canadiense y lo está añadiendo a la página de nombres busque su homónimo alemán más allá de encontrar que existe en la Wikipedia en alemán y que es identificable como un poeta diferente. (Pero sería mucho mejor añadir el alemán a esa lista o a algún otro artículo apropiado, o crear un esbozo mínimo para ellos).
Si vamos a cambiar WP:DABSISTER , la primera oración tal vez debería decir:
Los enlaces rojos a temas tratados en Wikipedias de otros idiomas se pueden mejorar utilizando {{ Interlanguage link }} para vincular a esas otras Wikipedias, pero aún se requiere un enlace azul a un artículo en Wikipedia en inglés a menos que haya una necesidad excepcional de ayudar a nuestros lectores al desambiguar un tema que aún no se menciona aquí.
Quizás añadir:
Se recomienda encarecidamente a los editores que busquen un artículo o una lista donde se pueda mencionar el tema, con fuentes confiables, para que se pueda crear un enlace azul según WP:DABMENTION .
Pam D 08:33 25 jul 2024 (UTC)[responder]
Básicamente, eso suena como alentar el uso de la {{Interlanguage link}}plantilla cuando sea aplicable. Este debería ser el caso para cualquier enlace rojo. Si ese es realmente el caso, entonces toda la sección WP:DABSISTER debería ser redirigida a WP:DABRED , y WP:DABRED debería alentar el uso de {{Interlanguage link}}la plantilla cuando sea aplicable. The Mountain of Eden ( discusión ) 21:11 26 jul 2024 (UTC) [ responder ]
No, no, no. Son cosas diferentes, aunque hay cierta superposición. Los enlaces hermanos son relativamente poco comunes. Los enlaces rojos se agregan de forma incorrecta de forma rutinaria por editores inexpertos. Necesitamos una guía para los enlaces rojos que sea lo más clara posible. Los enlaces hermanos son, en el mejor de los casos, una especie de caso especial de enlace rojo. olderwiser 21:23, 26 de julio de 2024 (UTC) [ responder ]
" Los enlaces hermanos son, en el mejor de los casos, una especie de caso especial de enlace rojo "
Yo eliminaría las palabras "en el mejor de los casos" y "más o menos", para que diga " Los enlaces hermanos son un caso especial de enlace rojo ", lo que significa que las dos secciones deberían combinarse en lugar de distribuirse en dos páginas diferentes. La Montaña del Edén ( discusión ) 21:36 26 jul 2024 (UTC) [ responder ]

Propuesta #3

  1. Elimina WP:DABSISTER de esta página y mueve el acceso directo a MOS:DISAMBIGUATION debajo de WP:DABRED .
  2. Debajo del ejemplo de Flibbygibby enmarcado, agregue la siguiente oración (sin cursiva):
    " Si el artículo que se desea desambiguar no tiene un artículo en la Wikipedia en inglés, pero tiene un artículo sobre un proyecto hermano en otro idioma, el término se puede vincular al proyecto hermano utilizando la {{interlanguage link}}plantilla " .
  3. WP:DABSISTER se vincularía a esta nueva oración propuesta.

La Montaña del Edén ( discusión ) 22:38 30 jul 2024 (UTC) [ responder ]

Apoyo

Oponerse a

Discusión

::Parece que esa es la propuesta n.° 4. Pero ¿por qué no agregar esa oración? La Montaña del Edén ( discusión ) 01:54 31 jul 2024 (UTC) [ responder ]

Lo siento, leí mal la pregunta. No veo cómo podemos redirigir el acceso directo sin agregar el texto, ya que nada en MOS:DAB habla sobre enlaces a proyectos hermanos. Podríamos eliminar el acceso directo o, si cambiamos el acceso directo a WP:DAB , de alguna manera tendríamos que hablar sobre los enlaces a proyectos hermanos en MOS:DAB . The Mountain of Eden ( discusión ) 02:02 31 jul 2024 (UTC) [ responder ]

Propuesta #4

Eliminar WP:DABSISTER por completo.

Apoyo

Oponerse a

Conversar

He añadido esta propuesta (después del hecho) simplemente porque debería haber sido una opción desde el principio. Blueboar ( discusión ) 01:04 31 jul 2024 (UTC) [ responder ]

¿Donde ahora?

Acabo de revertir un cambio de @ The Mountain of Eden : que agregó una declaración a Wikipedia:Manual de estilo/Páginas de desambiguación que creo que era completamente errónea (a menos que esté malinterpretando). La redacción agregada fue:

Creo que la última frase debería ser probablemente "enlace azul a" en lugar de "enlace rojo desde", pero en lugar de intentar resolverlo en la página en vivo, parece mejor acordar una redacción aquí. El resumen de la edición hizo referencia de manera poco útil a "Implementación de la propuesta 3 de WP:DESAMBIGUACIÓN " en lugar de señalar esta página de discusión y este punto en particular dentro de la página de discusión. Pam D 22:43, 12 de agosto de 2024 (UTC) [ responder ]

"un enlace rojo desde" es correcto según WP:DABRED que dice que " Un enlace a un artículo inexistente (un "enlace rojo") debe incluirse en una página de desambiguación solo cuando un artículo vinculado (no solo otras páginas de desambiguación) también incluya ese enlace rojo ". (énfasis añadido) The Mountain of Eden ( discusión ) 23:22 12 ago 2024 (UTC) [ responder ]
Bueno, señalé que la adición no está clara, aunque parece que lo descartaste como una "oposición simbólica". Me di por vencido en el intento de explicar esto porque parecía que lo estabas abordando desde una dimensión completamente diferente. olderwiser 12:56, 13 de agosto de 2024 (UTC) [ responder ]
Quizás me lo perdí, pero no sé qué es lo que no está claro. Sin embargo, estoy de acuerdo en que PamD tiene razón en lo que respecta al enlace azul. Por lo tanto, podemos agregar algunas palabras (el texto subrayado a continuación ) a la segunda oración para que diga:
Si el artículo que se va a desambiguar no tiene un artículo en la Wikipedia en inglés, pero tiene un artículo sobre un proyecto hermano en otro idioma, el término puede vincularse al proyecto hermano utilizando la plantilla. El uso de la plantilla no sustituye la necesidad de tener un enlace rojo desde un artículo existente para el término que se va a desambiguar, así como un enlace azul a un artículo existente dentro de la entrada , como se explicó anteriormente. {{interlanguage link}}{{interlanguage link}}
La Montaña del Edén ( discusión ) 15:03 13 ago 2024 (UTC) [ responder ]
Un poco mejor, pero estás asumiendo que un lector verá esto como parte de MOS:DABRED en lugar de un complemento aleatorio sin sentido (y que es obvio a qué se refiere lo explicado anteriormente ). Y perdemos el ejemplo de cómo usar ill en una página dab (la documentación de la plantilla cubre una variedad de opciones disponibles para uso general que no se aplican a las entradas de desambiguación). Y todavía no está claro qué sucede con la guía general que desalienta los enlaces a proyectos hermanos como Wikiquote, Wikitravel, etc. olderwiser 18:09, 13 de agosto de 2024 (UTC) [ responder ]
  • ¿Por qué es un non-squitur cuando está dentro de WP:DABRED y se trata de casos en los que no hay ningún artículo en la Wikipedia en inglés?
  • ¿Qué ejemplo hemos perdido?
  • ¿Cómo perdimos “ la guía general que desalienta los enlaces a proyectos hermanos como Wikiquote, Wikitravel, etc. ” cuando actualmente no existe?
  • El texto propuesto habla exclusivamente de Wikipedias que no están en inglés. Podemos copiar textualmente la frase " No se deben crear entradas cuyo contenido esté relacionado con otros proyectos hermanos, como Wikidata o Wikivoyage " de la página actual.
La Montaña del Edén ( discusión ) 18:18 13 ago 2024 (UTC) [ responder ]
  • Non sequitur porque tiene su propio atajo y viene después de otra subsección con su propio atajo y ejemplos. Visualmente, la conexión no es muy fuerte.
  • Suspiro, por enésima vez: el ejemplo en la nota al pie que estás eliminando de WP:DABSISTER .
  • ¿A dónde transferir el texto? ¿Y con qué atajo(s)?
Además, ¿por qué estamos creando esto como un subtítulo relacionado tangencialmente bajo MOS:DABRED cuando existe MOS:DABOTHERLANG ? Parece que este caso de uso está mucho más directamente relacionado con eso que con MOS:DABRED . olderwiser 19:09, 13 de agosto de 2024 (UTC) [ responder ]
Según mi interpretación de MOS:DABOTHERLANG , se trata de caracteres no ingleses. Solo se utilizaría la plantilla {{interlanguage link}}si hay un enlace rojo. No hay ninguna otra razón para utilizarla. Por lo tanto, encaja mejor en WP:DABRED .
Todavía no entiendo tu punto sobre la falta de coherencia solo porque hay un atajo presentado en el medio de una sección. Hay muchos atajos en la página en el medio de una sección. Tomemos como ejemplo MOS:DABPERIOD , MOS:DABSHORT , MOS:DABNOLINK ...
Así es como podemos incorporar el ejemplo de la nota a pie de página y la oración que desalienta otros proyectos hermanos.
Si el artículo que se desea desambiguar no tiene un artículo en la Wikipedia en inglés, pero tiene un artículo sobre un proyecto hermano en otro idioma, el término se puede vincular al proyecto hermano usando la plantilla.{{interlanguage link}}
  • Árbol, Villalba  [es; gl] , una parroquia de Vilalba , España
El uso de la {{interlanguage link}}plantilla no sustituye la necesidad de tener un enlace rojo desde un artículo existente para el término de desambiguación, así como un enlace azul a un artículo existente dentro de la entrada, como se explicó anteriormente. No se deben crear entradas cuyo contenido se encuentre en otro proyecto hermano , como Wikidata o Wikivoyage.
La Montaña del Edén ( discusión ) 19:28 13 ago 2024 (UTC) [ responder ]
Como se explicó anteriormente, es una señal de que tienes poca experiencia en la escritura hipertextual, donde las piezas individuales se leen (y citan) FRECUENTEMENTE fuera de contexto. Yo lo veo de otra manera. La única razón para usar ill es si hay un término que no está en inglés que tiene alguna relevancia en inglés y hay un artículo con contenido útil en otro idioma. Idealmente, al usar ILL, de hecho esperamos que el artículo se traiga a la wiki en inglés, haciendo que el enlace ill sea predeterminado al artículo en inglés. MOS:DABOTHERLANG trata sobre términos en idiomas que no están en inglés, no sobre caracteres. Desde la perspectiva de un editor ingenuo (probablemente no esté pensando "quiero crear un enlace rojo en una entrada de dab"), sino más bien, aquí hay un término en un idioma extranjero que tiene algún significado en inglés, pero no hay un artículo en inglés, pero sí un artículo decente en otro idioma), parece que las instrucciones serían más fáciles de encontrar para ese caso de uso en MOS:DABOTHERLANG . más viejomás sabio 19:58 13 ago 2024 (UTC) [ responder ]

No estoy de acuerdo con tu afirmación de que " la única razón para usar ill es si hay un término que no está en inglés pero que tiene alguna relevancia en inglés y hay un artículo con contenido útil en otro idioma ". Aquí hay un ejemplo real: la página de desambiguación Friendship Bridge tiene la entrada Thai-Cambodia Friendship Bridge. No hay absolutamente ninguna razón por la que no debería haber una entrada para este puente en la Wikipedia en inglés, salvo que el artículo aún no se haya escrito (una pequeña investigación revela que, según la Wikipedia en tailandés, en realidad hay dos puentes de este tipo: Thai-Cambodian Friendship Bridge (Aranyaprathet-Poipet)  [th] y Thai-Cambodian Friendship Bridge (Ban Nong Ien-Stung Bot)  [th] , pero eso no viene al caso). Como ilustra este ejemplo, el uso de the tiene que ver con el manejo de casos para los que no hay entradas en la Wikipedia en inglés, pero sí existen entradas en otros idiomas. Y para dejar en claro que esto sería inapropiado en MOS:DABOTHERLANG , el ejemplo en MOS:DABOTHERLANG en realidad usa un término que tiene un artículo en la Wikipedia en inglés (por lo tanto, no es necesario usar la plantilla). En cuanto a tu punto sobre " como se explicó anteriormente ", podemos reemplazar esa redacción con " como se detalla en MOS:DABRED y MOS:DABBLUE ". The Mountain of Eden ( discusión ) 20:53 13 ago 2024 (UTC) [ responder ]

{{interlanguage link}}{{interlanguage link}}

Tal vez lo hubiera expresado de otra manera, pero el punto sigue siendo válido: muy pocos editores van a buscar cómo crear un enlace rojo válido. La sección de enlaces rojos es más una prohibición con algunas excepciones. El uso de un ill puede ser una excepción válida, siempre que los criterios sean aceptables. Y no, creo que estás malinterpretando MOS:DABOTHERLANG . olderwiser 22:32, 13 de agosto de 2024 (UTC) [ responder ]
Y no estoy seguro de qué se supone que ilustra el ejemplo del Puente de la Amistad entre Tailandia y Camboya. ¿Por qué querríamos someter a los lectores ingleses a tener que elegir entre artículos bifurcados en otro idioma sobre el mismo maldito cruce? Y, aparte de una declaración sin fuentes, ni siquiera está claro cómo se conoce el cruce en inglés. Ese sería un ejemplo muy pobre de algo que no vale la pena incluir en un punto. olderwiser 22:45, 13 de agosto de 2024 (UTC) [ responder ]
Definitivamente estás perdido. Hay dos puentes con el mismo nombre: uno ubicado en 13.6153°N 102.6098°E y el otro ubicado en 13.6615°N 102.5495°E. Esto no sería una bifurcación. De hecho, tenemos que ir a la página de desambiguación del Puente de la Amistad y presentarlo como dos puentes separados de la misma manera que hay cuatro puentes enumerados como Puentes de la Amistad entre Tailandia y Laos.
Los enlaces {{ill}} a esos puentes le brindarían al lector información adicional sobre ellos al usar inteligencia artificial para traducir del tailandés al inglés. La montaña del Edén ( discusión ) 23:03 13 ago 2024 (UTC) [ responder ]
Acepté una respuesta negativa como si estuviera de acuerdo y agregué el nuevo texto propuesto a MOS:DESAMBIGUACIÓN . La Montaña del Edén ( discusión ) 19:18 26 ago 2024 (UTC) [ responder ]
Suposición errónea. No vi ningún sentido en seguir hablando sin entendernos. Pero si a nadie más le importa lo suficiente como para comentar, entonces no tengo nada más que agregar. olderwiser 19:59, 26 de agosto de 2024 (UTC) [ responder ]
No sé qué decir. Lo único que vi en tus últimos comentarios es:
  1. Cuestionamiento de la utilidad de la plantilla {{ill}}, lo cual no tenía sentido ya que no se propuso prohibir el uso de la plantilla.
  2. Objeciones a la ubicación del texto propuesto dentro de la página en MOS:DESAMBIGUACIÓN .
Siéntete libre de aclarar cualquier inquietud que tengas con el texto que agregué a MOS:DESAMBIGUACIÓN . Quizás podríamos mejorarlo aún más. La Montaña del Edén ( discusión ) 20:06 26 ago 2024 (UTC) [ responder ]
No estoy seguro de que haya un consenso sobre esto, pero tu segunda oración, No se deben crear entradas cuyo contenido esté en cualquier otro proyecto hermano, como Wikidata o Wikivoyage. no parece correcta. No hay ninguna razón para no incluir un tema como un enlace rojo en una página DAB solo porque tiene un artículo en Wikivoyage o Wikidata. Hasta donde yo sé, {{ ill }} no permite hacer enlaces a otros proyectos como Wikivoyage o Wikidata, por lo que esta oración es innecesaria e inútil. Por favor, elimínala. Pam D 20:26, 26 de agosto de 2024 (UTC) [ responder ]
Esa frase en cuestión no es mía. Está en el texto existente y Bkonrad insistió en que se transfiriera. La montaña del Edén ( discusión ) 20:55 26 ago 2024 (UTC) [ responder ]
No insistí en que se incluyera como parte de esta edición. Me pregunté por qué se estaba eliminando. olderwiser 22:15, 26 de agosto de 2024 (UTC) [ responder ]
Entonces parece que tenemos un consenso para eliminar esta frase. La montaña del Edén ( discusión ) 22:18 26 ago 2024 (UTC) [ responder ]
De ninguna manera. más viejomás sabio 22:19, 26 de agosto de 2024 (UTC) [ responder ]
Entonces tal vez debería abrir una discusión en Wikipedia discusión:Manual de estilo/Páginas de desambiguación porque las prohibiciones deben estar justificadas. La sentencia, tal como está escrita, no ofrece ninguna justificación. La montaña del Edén ( discusión ) 22:24 26 ago 2024 (UTC) [ responder ]
Debo mencionar que no estoy necesariamente de acuerdo con esa oración. No estoy seguro de por qué no podemos tener vínculos con esos otros proyectos hermanos, pero eso estaba más allá del alcance de la propuesta. La Montaña del Edén ( discusión ) 20:57 26 ago 2024 (UTC) [ responder ]
En discusiones anteriores se había establecido que no deberíamos incluir enlaces a proyectos hermanos en las páginas de desambiguación. No creo que encaje como parte de la edición actual, pero no debería simplemente desaparecer sin un consenso claro. olderwiser 22:19, 26 de agosto de 2024 (UTC) [ responder ]
Tal vez debería ser más claro: transferí esa oración para generar consenso con Bkonrad . A mí tampoco me gusta esa oración. Por lo tanto, PamD , tienes todo mi apoyo para eliminar esa oración en WP:DABSISTER . The Mountain of Eden ( discusión ) 21:14 26 ago 2024 (UTC) [ responder ]

Ordenación superior/común como una cuestión de estilo vs. eficiencia de navegación

Recientemente he notado algunos casos en los que el formato MOS:DABCOMMON era un pequeño problema:

Varias de las discusiones en Wikipedia discusión:Manual de estilo/Páginas de desambiguación/Archivo 44 también han tratado sobre el orden. La búsqueda en los archivos de páginas de discusión aquí también muestra muchas discusiones sobre el orden. Tal vez debamos reflexionar sobre este asunto de manera más coherente.

Me parece que deberíamos trasladar la parte de la guía de estilo que afecta a la parte superior de una página de desambiguación a la guía principal aquí, porque esto no parece ser solo una cuestión de estilo per se, sino que podría tener un impacto significativo al garantizar que un lector que busque un tema utilizando un término en particular pueda acceder a la información sobre ese tema de manera rápida y sencilla . -- Joy ( discusión ) 09:54, 25 de julio de 2024 (UTC) [ responder ]

No estoy seguro de que la ventaja de tener un grupo de usos comunes en la parte superior sea siempre evidente. Puede resultar en una navegación más lenta si los lectores saltan a la sección relevante esperando encontrar el elemento específico que aparece allí y luego tienen que volver a buscarlo en la parte superior. Esto es similar a lo que puede suceder con un tema principal y plantea la cuestión de si dichas entradas deberían duplicarse dentro de la sección correspondiente y en la parte superior. olderwiser 12:54, 25 de julio de 2024 (UTC) [ responder ]
Estoy de acuerdo, deberíamos incluir los elementos comunes en ambos lugares. Si la lista ya es relativamente larga, duplicar un par de elementos populares no debería alargarla de forma irrazonable y, con suerte, podremos detectar la mayoría de esos casos. -- Joy ( discusión ) 16:52, 25 de julio de 2024 (UTC) [ responder ]
Además, con páginas relativamente cortas, puede resultar innecesario o incluso contraproducente intentar extraer un par. olderwiser 17:21, 25 de julio de 2024 (UTC) [ responder ]
Debido a la gran variedad posible, tendríamos que hacer pruebas con ejemplos específicos. Por ejemplo, ¿es 1 común y 20 poco común, o 2: 20, o 1: 10, o 3: 10, y luego los distintos niveles de lo común que es cada uno de los comunes, etc.? -- Joy ( discusión ) 18:51 26 jul 2024 (UTC) [ responder ]
Parece que encontramos un caso de una página relativamente corta: en Deadlock , la mayoría de las entradas comunes estaban en Otros usos, y @Zxcvbnm las eliminó[1]. -- Joy ( discusión ) 07:14, 23 de agosto de 2024 (UTC) [ responder ]
Sí, eso parece razonable, ya que dos de los duplicados estaban en la sección "Otros usos" y el tercero estaba en la sección "Política y derecho", que no tenía una coherencia clara y en la que solo se había fusionado la entrada restante con otros usos. Es un poco extraño que Impasse siga duplicado en la sección "Ver también". olderwiser 11:06, 23 de agosto de 2024 (UTC) [ responder ]
Mientras tanto, en King Charles , agregar un listado duplicado en la sección correspondiente inmediatamente debajo del listado superior parece haber sido útil para al menos la mitad de los lectores que no vieron el listado superior antes, según dos mediciones mensuales posteriores. -- Joy ( discusión ) 09:14, 6 de septiembre de 2024 (UTC) [ responder ]

Capitalización del título de una página de desambiguación con sentidos tanto en mayúsculas como en minúsculas

Me parece recordar que hay una regla que dice que si una página de desambiguación tiene sentidos tanto en mayúsculas como en minúsculas, entonces el título de la página debe estar en el título en minúsculas, si está disponible. En particular, estoy pensando en LOR (para el que existen muchos sentidos Lor ). Lor actualmente redirecciona a LOR . No estoy pidiendo un movimiento de página aquí, sino dónde se puede encontrar la regla al respecto. Si no hay una regla al respecto, ¿dónde debería colocarse? BD2412 T 01:58, 2 de agosto de 2024 (UTC) [ responder ]

Creo que lo que estás buscando son dos de las viñetas debajo de WP:DABNAME :
  • Se prefiere una palabra a una abreviatura, por ejemplo Arm (desambiguación) en lugar de ARM.
  • Se prefiere la ortografía que refleja la mayoría de los elementos de la página a las alternativas menos comunes.
A veces pueden ser contradictorias, pero probablemente sea mejor resolverlas caso por caso. Station1 ( discusión ) 06:01 2 ago 2024 (UTC) [ responder ]
La verdadera pregunta aquí es si tenemos que tener en cuenta esta fusión en primer lugar. Si se ven patrones de uso distintos basados ​​en la capitalización, y si la navegación sería más eficiente si el lector no tuviera que recorrer ambas listas juntas, simplemente deberían separarse, ya que esta directriz en realidad no se aplica de manera consistente en primer lugar, cf. Wikipedia talk:Disambiguation/Archive 56#WP:DABCOMBINE no es realmente un consenso orgánico en el espacio de las siglas .
En mi navegador, ya tengo que hacer PgDn dos veces para navegar por esa lista, así que si pueden ser dos listas de Lor y LOR y si estas fueran más sencillas, en realidad tendría más sentido. La idea de fusionar es válida cuando creemos que hay una gran cantidad de tráfico de personas, por ejemplo, que escriben "lor" pero quieren "LOR". Si se pudieran ofrecer con un enlace a LOR visible en la primera página sin tener que desplazarse, eso parece mejor que obligar a los lectores a recorrer dos páginas de una lista más compleja en cada visita. Y se volvería medible, podríamos ver en las estadísticas cuántos lectores necesitan hacer eso. -- Joy ( discusión ) 07:25, 2 de agosto de 2024 (UTC) [ responder ]
... ya que esta directriz no se aplica de manera consistente en primer lugar... : Es una directriz, hasta que se modifique o elimine. Hasta entonces, no está claro si otros ejemplos son WP:OTHERSTUFF o WP:IAR .— Bagumba ( discusión ) 09:53 2 ago 2024 (UTC) [ responder ]
Bueno, la directriz WP:DABCOMBINE sólo es útil si realmente tiene sentido. El texto actual es demasiado amplio:
Términos que difieren únicamente en mayúsculas, puntuación y signos diacríticos. Casi siempre deben compartir una página de desambiguación.
Esto solo dice "términos", pero no tiene que ser tan genérico: por ejemplo, Mediawiki nos obliga a combinar arm y Arm , pero no nos obliga a combinar Arm y ARM . Si tenemos 9 significados conocidos de Arm, 3 significados conocidos tanto de Arm/arm como de ARM no por pereza al escribir (empresa, software, idioma) y 34 significados conocidos de ARM, no es trivial ni obvio simplemente aconsejar que casi siempre deben ser una lista de 46 elementos, y no deberíamos guiar a las personas hacia esa solución en términos tan fuertes.
Parece que esta directriz fue escrita solo para casos de uso breves y triviales, y sinceramente dudo que alguien haya comprobado alguna vez si realmente se puso a prueba en la práctica analizando sus resultados. Deberíamos cambiarla para que sea menos estricta. -- Joy ( discusión ) 09:39 6 sep 2024 (UTC) [ responder ]
@ Joy : He visto páginas "fusionadas" mucho más largas y me preocuparía que algunas personas que busquen "LOR" no se molesten en poner en mayúsculas las letras al escribirlas en el cuadro de búsqueda. BD2412 T 17:50, 2 de agosto de 2024 (UTC) [ responder ]
En el caso de páginas largas, esto se puede solucionar añadiendo, por ejemplo, "LOR (desambiguación)" a Ver también, o incluso agregándolo como nota de presentación si Ver también está muy abajo en la página. Incluso con páginas fusionadas, creo que es más fácil para los lectores encontrar lo que están buscando si las LORS y las LOR se dividen en secciones separadas. Station1 ( discusión ) 18:03 2 ago 2024 (UTC) [ responder ]

Pregunta: ¿"/" en la desambiguación entre paréntesis?

Actualmente estoy trabajando en la reescritura de la guía de WP:KOREA sobre los títulos de los artículos sobre montañas. Para desambiguaciones con múltiples términos, no estoy seguro de qué es preferible, un "/" o un "y". Por ejemplo, aquí hay una página con un "y": Taehwasan (Gangwon y Chungcheong del Norte) . Aquí hay una página con un "/": Sinseonbong (Chungju/Goesan) .

¿Son aceptables ambos formatos? Sé que tener varios términos en primer lugar no es bueno, pero en el peor de los casos, si tuviéramos varios términos, ¿qué deberíamos hacer? seefooddiet ( discusión ) 07:53, 5 de agosto de 2024 (UTC) [ responder ]

Nota: encontré algunas secciones relevantes. WP:NCPLACE#Características naturales y posiblemente una interpretación libre de WP:DISAMBIG#Formato pueden sugerir que deberíamos evitar el "/" ya que los títulos de los artículos normalmente no lo tienen. seefooddiet ( discusión ) 07:55, 5 de agosto de 2024 (UTC) [ responder ]
Creo que el enfoque más habitual en estos casos es utilizar la cordillera como término desambiguante. Pero esa información actualmente no está disponible en los artículos. olderwiser 10:21, 5 de agosto de 2024 (UTC) [ responder ]
Como Corea es bastante pequeña, y debido a su geografía, sus montañas a menudo se encuentran en las mismas pocas cadenas montañosas. Categoría:Montañas de Corea del Sur Categoría:Montañas de Corea del Norte Categoría:Cordilleras de Corea .
Las montañas Taebaek y las montañas Sobaek son dos importantes cadenas montañosas. ¿Deberíamos intentar desambiguar primero por cordillera y luego, si no es posible, por múltiples ubicaciones? seefooddiet ( discusión ) 17:20 5 ago 2024 (UTC) [ responder ]
MOS:SLASH recomienda no usar barras diagonales en general, con ciertas excepciones. En el contexto sobre el que preguntas, yo usaría "y" cuando se trata de elegir entre las dos. Station1 ( discusión ) 18:08 5 ago 2024 (UTC) [ responder ]
El consenso parece ser que los nombres compuestos son feos, por lo que los editores suelen preferir elegir una variante y añadir redirecciones para otra. Como alternativa, elegir algún tipo de compromiso diferente.
Para este último, un ejemplo que puedo recordar fue la montaña de Kozjak en la frontera entre Serbia y Macedonia del Norte, donde elegí Kozjak (montaña cerca de Pčinja) como desambiguador de compromiso, un río cercano que también pasa por ambos. -- Joy ( discusión ) 08:27, 12 de agosto de 2024 (UTC) [ responder ]

Ubicación de las plantillas de herramientas de autorreferencia , ,{{srt}}{{look from}}{{intitle}}

Estas plantillas ayudan mucho a reducir las coincidencias no esenciales de WP:PARTIAL , pero no está muy claro DÓNDE deberían aparecer en la sección Ver también. Siempre las coloco en la parte superior porque así las vi por primera vez en Draw#Ver también hace unos 15 años. Pero en los últimos tiempos, tiendo a verlas (70%) como lo último en la sección Ver también, debajo de otros XXX (desambiguación) y ortografías alternativas. ¿Hay una buena razón para hacerlo de una forma u otra, o dejarlo deliberadamente en manos del editor? – sgeureka t • c 12:15, 15 de agosto de 2024 (UTC) [ responder ]

Propuesta de cambio en la determinación del tema principal

Hay una situación en la que creo que nuestras reglas actuales para determinar el tema principal fallan. Es cuando uno (y solo uno) de los artículos enumerados es un artículo vital y, sin embargo, puede que no sea la página con más visitas. Por ejemplo, The Void (filosofía) es un artículo vital de nivel 5, y sin embargo, en lugar de estar en The Void , tenemos una lista de medios modernos con nombres homónimos. Las reglas actuales fallan de una manera que hace que Wikipedia parezca estúpida. El sentido común pondría el artículo vital en "The Void" y la lista de medios modernos con nombres homónimos en The Void (desambiguación) . Dentro de cien años, The Void (película de 2016) difícilmente será la alternativa más buscada, por lo que el estado actual falla. WP:RECENTISM . Skyerise ( discusión ) 10:57, 19 de agosto de 2024 (UTC) [ responder ]

Lo siento, pero no. El proceso para identificar artículos vitales es algo aleatorio, especialmente para los artículos de nivel 5. No hay nada de tonto en dirigir a los lectores a los artículos que realmente están buscando de la manera más expedita. Ya existe un caso de tema principal basado en la importancia a largo plazo. Si no hay consenso sobre la importancia a largo plazo de un tema, no hay razón para presumir que sea el tema principal. olderwiser 11:59, 19 de agosto de 2024 (UTC) [ responder ]
No veo el valor que tiene para el usuario facilitarle el acceso al artículo más "importante" cuando no es un artículo que la gente probablemente esté buscando. Es como decirle al usuario, no "Aquí está el artículo sobre el tema que te interesa", sino "Aquí está el artículo sobre el tema que creemos que te debería interesar".
En algún momento entre ahora y dentro de cien años, no habrá nada que impida cambiar el tema principal si los niveles relativos de interés se han desplazado en esa dirección. Por hoy, estamos al servicio de los usuarios de hoy. Largoplazo ( discusión ) 20:11 19 ago 2024 (UTC) [ responder ]

Cómo funciona la navegación del lector sin que nuestros elementos de navegación estén configurados correctamente

He aquí un ejemplo interesante con el que me topé:

El artículo principal se escribió a fines de 2019 e inmediatamente obtuvo tráfico persistente, lo cual no es lo que esperaba cuando no estaba vinculado desde "Tivadar" en sí; faltaba una nota al pie durante este período.

A principios de 2020, alguien agrega [2] un enlace indirecto al nombre al vincular a Theodore (nombre) en una sección de Nombre, y el tráfico en Tivadar parece comenzar a disminuir, mientras que el tráfico en Tivadar (nombre de pila) comienza a aumentar y desde 2021 regularmente supera el tráfico de la aldea.

Durante todo este tiempo, la lista de Theodore (nombre) todavía tenía un enlace al artículo del pueblo (extraviado) y nuevamente no había ni siquiera una nota al pie.

Parece que los motores de búsqueda aprendieron dónde fallaba nuestra navegación y solucionaron el problema, al menos la mayor parte del tiempo. -- Joy ( discusión ) 08:50, 20 de agosto de 2024 (UTC) [ responder ]

¿Es esta una página de desambiguación?

Hola a todos, acabo de crear Turtle Islands Heritage Protected Area , que es el nombre de un área protegida que en realidad son dos áreas protegidas adyacentes en países limítrofes. No parece tener mucho sentido una página independiente; tras una investigación rápida, parece que ambos lados operan sus parques por separado y ambas páginas individuales ya existen. Por otro lado, es un término usado que parece útil para que los lectores lo encuentren; yo, por ejemplo, lo estaba buscando y también ya existía (técnicamente, una variación sin s después de "Island") como un enlace rojo en Transboundary protected area . Si bien no es un dab tradicional, tampoco parece ser un artículo de índice establecido ni una lista. He realizado una búsqueda de IAR según MOS:DAB y lo he creado como una página de desambiguación por ahora, pero pensé en verificar si había una mejor opción. Saludos, CMD ( discusión ) 15:39, 20 de agosto de 2024 (UTC) [ responder ]

Se trata más de un índice de conjuntos o quizás de un artículo de conceptos generales poco desarrollado, en lugar de una página de desambiguación. Ninguna de las áreas individuales de los dos países se denomina "Área protegida patrimonial de las Islas Tortuga", sino que parecen ser entidades constituyentes que comprenden el área administrada conjuntamente. olderwiser 16:38, 20 de agosto de 2024 (UTC) [ responder ]
Me pregunto si debería ser un artículo muy breve, utilizando las dos referencias en Área protegida transfronteriza , agregando coordenadas y explicando su estado y que se administra como las dos áreas. Y agregarlo al dab en Islas Tortuga . Claramente existe como una entidad a los ojos de la UNESCO y el GTPAN. Y puede tener Categoría:Áreas protegidas transfronterizas así como algunas categorías geográficas. Pam D 16:55, 20 de agosto de 2024 (UTC) [ responder ]
Y sospecho que el Parque Nacional de las Islas Tortuga (Malasia) debería ser trasladado de nuevo a Parque Nacional de las Islas Tortuga : fue trasladado en 2008 con el argumento de que "Filipinas también tiene islas Tortuga", ¡pero la zona de Filipinas no se llama "Parque Nacional de las Islas Tortuga"! ... Oh, WP:SOFIXIT : hecho. Pam D 17:05, 20 de agosto de 2024 (UTC) [ responder ]
Parece una medida sensata, ¿es necesario añadir una nota al pie, dado que el Santuario de Vida Silvestre de las Islas Tortuga está vinculado en el primer párrafo? En cuanto a las fuentes, por lo que he encontrado, la UNESCO y el GTPAN no lo tratan realmente como una entidad. La página pertinente de la UNESCO es solo para el área de Filipinas, y la lista del GTPAN la considera dos áreas, "Pulau Penyu (Islas Tortuga)" [Malasia] e "Islas Tortuga" [Filipinas]. (Sospecho que la página de la UNESCO trata de la reserva filipina, ya que es casi 140 veces más grande que la de Malasia). Tal vez podríamos crear alguna distinción centrándonos en el MOA y en la cooperación que existe (al menos alguna), pero todavía no estoy seguro de que no se pueda incluir en los artículos individuales de todos modos. CMD ( discusión ) 17:12, 20 de agosto de 2024 (UTC) [ responder ]
Me preguntaba si debería simplemente redirigir al de Filipinas como tema principal, pero creo que eso sería políticamente inepto. Sería útil si la página de la UNESCO tuviera un mapa... en cambio, tiene coordenadas inexactas, ya que "E199 25" debe ser un error tipográfico. Las coordenadas N no cubren el lugar de Malasia, ya que está a 6 grados al norte. ¡Interesante! Pam D 17:24, 20 de agosto de 2024 (UTC) [ responder ]
Y nuestro artículo sobre el lugar de Malasia dice que hay siete islas en la entidad filipina, mientras que su artículo solo afirma seis. Pam D 17:28, 20 de agosto de 2024 (UTC) [ responder ]

Alias

He creado Aliasing (desambiguación) en respuesta parcial a la pregunta de Johsebb en Teahouse . Creo que puede ser necesario un seguimiento adicional, en particular, cambiar el nombre de Aliasing a 'Aliasing (procesamiento de señales)' (actualmente una redirección a Aliasing), pero eso depende, supongo, de WP:PRIMARYTOPIC . ¿Alguna idea sobre la mejor manera de proceder? ¿Me he olvidado de algo? Gracias, Mathglot ( discusión ) 18:14, 25 de agosto de 2024 (UTC) [ responder ]

¿ Alguna idea sobre la mejor manera de proceder... ? Supongo que te refieres a determinar el tema principal. Según el hilo, parece que potencialmente el tema con más tráfico no es lo que un experto en el dominio considera el "significado principal" del término. Es subjetivo cómo se equilibran múltiples factores que dan lugar a diferentes temas principales potenciales para determinar el objetivo ideal. Un WP:RM parece ser la ruta si parece probable que un movimiento no discutido sea impugnado.— Bagumba ( discusión ) 09:53, 26 de agosto de 2024 (UTC) [ responder ]
Sí, creo que ese es el problema principal. Me inclino por WP:NOPRIMARY , pero estoy dispuesto a que me convenzan de lo contrario. Y sí, un RM probablemente se calificaría como no obvio, por lo que se debería seguir WP:RM#CM . Mathglot ( discusión ) 09:59 26 ago 2024 (UTC) [ responder ]

WikiNav se considera perjudicial

Acabo de darme cuenta de que me perdí esta parte de Talk:Heimlich (desambiguación)#Traslado solicitado 18 de agosto de 2024 :

cualquier interpretación de la discrepancia entre las vistas entrantes y salientes es especulativa. No sabemos nada sobre por qué sucede o qué razones pueden tener los lectores que no pasan a una vista saliente para hacerlo. Claro, es posible que parte del tráfico saliente también pueda ser de agentes no humanos. Sin embargo, la parte de bots de cualquiera de los dos es una parte menor del punto. El punto una vez más es que los números de vistas entrantes en bruto no nos dicen NADA sobre lo que los lectores podrían haber estado buscando, excepto posiblemente que A) lo que buscaban no estaba en la página o B) que lo que encontraron en la página era suficiente; y ni siquiera podemos notar la diferencia en función de estos datos. older ≠ wiser 11:20, 23 de agosto de 2024 (UTC)

Si cualquier interpretación de la discrepancia entre las vistas entrantes y salientes es especulativa, y la comparación entre las vistas entrantes y salientes es el primer gráfico de WikiNav, entonces tenemos que dejar de recomendar a la gente que mire WikiNav con el fin de decidir cómo organizar la navegación.

O, por otro lado, debemos aceptar el simple hecho de que todo lo que hacemos con nuestros datos estadísticos es necesariamente interpretación.

La idea de que deberíamos tomar la salida parcial de una herramienta y tratarla como si fuera la verdad y tratar la otra parte de su salida como si no fuera nada es francamente absurda. Este tipo de trato con los extremos en lugar de tratar de encontrar los matices está empezando a parecer algo ideológico :D -- Joy ( discusión ) 07:25, 28 de agosto de 2024 (UTC) [ responder ]

Si cualquier interpretación de la discrepancia entre las opiniones entrantes y salientes es especulativa... ¿Puede proporcionar más detalles sobre la naturaleza de la "interpretación" que se cuestiona? — Bagumba ( discusión ) 07:44 28 ago 2024 (UTC) [ responder ]
Está vinculado en la discusión anterior. Las personas ven un montón de vistas salientes a un único destino en WikiNav y deciden que lo mejor para la navegación es que hagamos un cortocircuito. La discrepancia entre las vistas entrantes y salientes se ignora en gran medida a través de este proceso. -- Joy ( discusión ) 08:09, 28 de agosto de 2024 (UTC) [ responder ]
Sí, lo siento. Voy a optar por la vía TLDR :-) Sería útil un resumen rápido de tu problema. Gracias. — Bagumba ( discusión ) 08:17 28 ago 2024 (UTC) [ responder ]
En resumen, tenemos un problema persistente al intentar descubrir los temas principales por uso.
  • Contamos con numerosos casos de términos que se han utilizado para referirse a un único tema destacado durante décadas, o que se han desambiguado para alejarse de un único tema destacado durante décadas, y que, comparativamente, han generado muy poca respuesta de los lectores. Es muy difícil determinar si se debe a una falta de interés en quejarse o a que los lectores en realidad no tienen ningún problema con ello.
  • Tenemos mucha variedad en lo que sucede cuando los lectores llegan a las páginas de desambiguación: en algunos lugares, los clics son una pequeña minoría del tráfico, en otros lugares son incluso mayores que el tráfico entrante y observamos casi todo lo demás en el medio. No tenemos ningún parámetro sólido sobre lo que esto significa.
  • Los motores de búsqueda modifican nuestro tráfico de lectores de manera muy significativa y trabajan en torno a nuestra navegación. Afectan la forma en que funcionan nuestras estadísticas modificando completamente nuestros datos de entrada de una manera que solo podemos detectar después del hecho (o que nunca podemos detectar a menos que hagamos un cambio, para lo cual no podemos obtener un consenso).
  • Nos faltan datos detallados sobre lo que sucede después de que los lectores navegan de una manera que no querían: ¿se quedan y leen los artículos, hacen clic para salir, simplemente cierran la pestaña del navegador, van a Wikcionario, etc.?
  • En términos generales, las sugerencias para mover artículos en función del uso llegan lentamente a las páginas de discusión, y tratamos de aplicar las pautas, pero a menudo estamos limitados por la falta de datos adecuados: se convierte más en una discusión del tipo mi intuición versus tu intuición.
  • Así como no tenemos el concepto de medir los resultados del status quo, tampoco medimos los resultados de los cambios.
  • No tenemos un concepto de experimentación, nunca escucho a nadie más considerar la idea de que probemos algo; la declaración de discusión típica es final y está en negrita al principio.
¿Qué te parece este resumen? :D -- Joy ( discusión ) 08:31 28 ago 2024 (UTC) [ responder ]
Gracias (aunque supongo que no todos estos temas surgieron en este RM específico). Desde un punto de vista visual, no diría que WikiNav es perjudicial. Genera estadísticas. Simple. A menos que sean inexactas, la parte "perjudicial" que podrías estar sugiriendo es cómo la comunidad de WP está interpretando los datos y las acciones posteriores que toma en respuesta. ¿Te parece justo o me estoy perdiendo algo? — Bagumba ( discusión ) 08:44, 28 de agosto de 2024 (UTC) [ responder ]
Sí, este es un resumen de la situación general que está llevando a situaciones de crisis como la de Heimlich.
Solo usé el cliché considerado dañino como una estrategia para que la gente lo vea, lo siento por eso. :)
Supongo que aclara muy bien el punto principal: así como no deberíamos juzgar una discusión por una parte de su título, no deberíamos juzgar las estadísticas de uso por una parte de su salida en WikiNav. -- Joy ( discusión ) 10:50, 28 de agosto de 2024 (UTC) [ responder ]
... en algunos lugares los clics son una pequeña minoría del tráfico, en otros lugares son incluso mayores que el tráfico entrante, y observamos casi todo lo demás en el medio ¿ Más clics salientes que entrantes? ¿Se ha dado alguna explicación para esa anomalía estadística? — Bagumba ( discusión ) 11:59 28 ago 2024 (UTC) [ responder ]
Sí, en la lista anterior menciono un caso así, puedes hacer un Ctrl+F para "marcha forzada". -- Joy ( discusión ) 12:14 28 ago 2024 (UTC) [ responder ]
En el caso de una página como marcha forzada , en todo caso, sugiere que quizás las descripciones no son lo suficientemente claras como para distinguir entre los elementos o posiblemente simple curiosidad sobre usos que no se le habían ocurrido al lector. Al leer la página actual, me resulta difícil distinguir entre marcha forzada (ejercicio militar) y marcha forzada (maniobra) . olderwiser 15:24, 28 de agosto de 2024 (UTC) [ responder ]
Creo que podría ser que la gente a veces busque un artículo con un concepto amplio, pero solo encuentre este, y luego revise todos los significados para llegar a cuál es el concepto unificador. -- Joy ( discusión ) 17:08, 28 de agosto de 2024 (UTC) [ responder ]
Por cierto, según lo que yo entendí, el ejercicio se hace de manera más preventiva, como práctica y prueba, mientras que la maniobra consiste en hacer lo mismo en tiempos de guerra. Si tuviéramos un BCA, probablemente podría explicarlo mejor. -- Joy ( discusión ) 17:10 28 ago 2024 (UTC) [ responder ]
Ni siquiera se menciona la "marcha forzada" en Guerra de maniobras , el objetivo de la marcha forzada (maniobra) . Y la primera imagen es la de un ejercicio de entrenamiento en lugar de una acción en tiempos de guerra (aunque no para una marcha forzada). Esto es bastante confuso. olderwiser 17:20, 28 de agosto de 2024 (UTC) [ responder ]
Si no recuerdo mal, esto surgió principalmente a través de la desambiguación de enlaces en Special:WhatLinksHere/Forced march (maneuver) . Todos esos artículos hacían referencia a la marcha forzada, pero en un contexto que dejaba claro que no se trataba de ejercicios, sino de guerra. -- Joy ( discusión ) 17:26 28 ago 2024 (UTC) [ responder ]
Vale. Es posible que abrir varios enlaces nuevos en una nueva pestaña o ventana, o hacer clic en "Atrás", no genere un nuevo "clic entrante" registrado. — Bagumba ( discusión ) 15:46 28 ago 2024 (UTC) [ responder ]
Son suposiciones razonables. Lamentablemente, la documentación de WikiNav no es muy clara. olderwiser 16:03, 28 de agosto de 2024 (UTC) [ responder ]
¿Quizás alguien en m:Research talk:Wikipedia clickstream pueda aportar algo? — Bagumba ( discusión ) 16:20 28 ago 2024 (UTC) [ responder ]
Sí. Puedes abrir la consola de red F12 en tu navegador mientras haces clic en un artículo de Wikipedia y ver si se realiza otra solicitud de red. Si no es así, no hay registros del lado del servidor que el análisis de flujo de clics pueda usar para recopilar datos. TTBOMK tampoco usamos ningún software espía basado en Javascript para rastrear a los usuarios y poder capturar y registrar estos eventos dentro de los navegadores. -- Joy ( discusión ) 17:12, 28 de agosto de 2024 (UTC) [ responder ]
El lector podría tener la página de dab abierta en una pestaña y hacer clic en varios enlaces diferentes usando el botón derecho y "abrir en nueva pestaña", explorando posibles artículos para encontrar el que necesita. En particular, si se trata de una página de nombres y tiene que explorar muchas páginas de dab diferentes para diferentes nombres de pila. Pam D 17:01, 28 de agosto de 2024 (UTC) [ responder ]
Sí, siempre que tengamos varios niveles de navegación, probablemente deberíamos esperar que los lectores de escritorio hagan eso. Sin embargo, no estoy seguro de si es práctico en dispositivos móviles: en ese caso, es posible que tengamos que esperar una mayor tasa de fallas, es decir, lectores que simplemente ven un proceso de navegación demasiado complejo y se dan por vencidos. Es posible que estos regresen a través de un motor de búsqueda más tarde, pero no se los puede identificar como tales. -- Joy ( discusión ) 17:15, 28 de agosto de 2024 (UTC) [ responder ]
Casi nunca he mirado el lado entrante de una pantalla de WikiNav: lo que importa es el lado saliente, que muestra a dónde van los lectores después de llegar a la página de destino. No considero que WikiNav sea perjudicial: es útil. No estoy de acuerdo con su lógica en la afirmación " Si cualquier interpretación de la discrepancia entre las vistas entrantes y salientes es especulativa, y la comparación entre las vistas entrantes y salientes es el primer gráfico de WikiNav, entonces tenemos que dejar de recomendar a la gente que mire WikiNav con el fin de decidir cómo organizar la navegación". ": uno puede mirar, e informarse por, el primer gráfico sin estar interesado en su lado izquierdo o la diferencia (difícilmente "discrepancia") entre los lados. Pam D 07:56, 28 de agosto de 2024 (UTC) [ responder ]
Los autores de la aplicación nos muestran un gráfico y elegimos mirar solo el lado izquierdo, pero cuando alguien señala que también hay un lado derecho y que hay mucha variedad en cómo interactúan, como se describe en #sobre cómo deberían verse las estadísticas para notas de sombrero, redirecciones principales, temas principales, etc., la respuesta es este grosero "¡solo estás especulando!".
No creo que haya suficiente rigor científico en decidir de manera esencialmente arbitraria lo que importa y, a su vez, acusar a alguien que te dice que otras cosas también pueden importar de estar participando en una actividad que no tiene suficiente rigor científico :) que es lo que hizo el comentario de Bkonrad allí, según tengo entendido. -- Joy ( discusión ) 08:17, 28 de agosto de 2024 (UTC) [ responder ]
The section heading here is misleading. WikiNav was not constructed with the purpose of determining primary topic in mind. It is simply a visualization of sources and destinations of page views and one use to which it has been put is to assist in determining primary topic. The extended quote above is from me, and as I said the portion that I think is being misused in primary topic discussions is the incoming page views. The outgoing views does provide a very clear data point for evaluating what readers are looking for. Incoming views tell us virtually nothing about what readers might have been looking for. As I mentioned to Joy in other discussions, where there is a large discrepancy between incoming and outgoing, that might be worth some further investigation, but by itself it provides no actionable information. olderwiser 10:30, 28 August 2024 (UTC)[reply]
The outgoing views are a very clear data point, except for the huge gaping holes where we have no data points about outgoing views? :)
I think we've amassed enough experience by now to be able to consider some of these things actionable, at least as an experiment. But our process doesn't encourage any such thing.
By not measuring and not checking our outcomes, we're actually in speculative territory as it is, which is why I don't fancy being told my interpretation is speculative. --Joy (talk) 11:05, 28 August 2024 (UTC)[reply]
What "gaping holes"? I have not seen any convincing evidence that incoming views directly provide any useful information. We can certainly adjust processes where there is a need, but I've not seen any consistent indications that there is a systemic problem that can be easily remedied by a change in process. olderwiser 11:15, 28 August 2024 (UTC)[reply]
The obvious gaping holes, the differences between incoming user traffic and outgoing clickthroughs that exist almost everywhere. You know, the thing I've spent many hours documenting in dozens of examples :D --Joy (talk) 12:19, 28 August 2024 (UTC)[reply]
I wouldn't characterize that as a gaping hole with regards to data points about outgoing views. It is a gaping hole with regards to incoming views, but there is no consistent or coherent account for how such differences between incoming and outgoing views affect the usefulness of the outgoing views. olderwiser 15:11, 28 August 2024 (UTC)[reply]
Well, if you want to be more specific like that, there is actually one persistent gaping hole about outgoing views that we know about - the anonymization of clickstreams makes it certain that we do not see any long tail of traffic.
So wherever there's fewer than 10 source-destination pairs in a month, we know that this is explicitly deleted from view - so if a link was clicked by 9 people who came in with an empty referer, 9 people who came from a known search engine, 9 people who came from Wiktionary, 9 people who came from Main Page, 9 people who came from Related Topic #1, ... all of this traffic we will never see as outgoing clickstreams. And then the link below that is clicked by 8 people from X, 7 people from Y, 5 people from Z, ... ditto. And so on.
In some cases, where monthly traffic is really high, this issue should be ignorable. But there are so many discussions where we talk about e.g. 25 or 100 clickstreams, where this could really have an impact. --Joy (talk) 17:21, 28 August 2024 (UTC)[reply]
I would question why any anonymization is needed for anonymous sources such as other-search or other-empty. Do we actually know this is what happens or is this just another example of deficiencies in the documentation? olderwiser 17:32, 28 August 2024 (UTC)[reply]
That's what the documentation describes... I'm not sure what the point is anyway, as even if we knew that e.g. 1 person came from any source and browsed a sensitive topic, and then was the sole person who clicked another link to another sensitive topic - the identity of that person is still unknown? What is even the scenario where someone is being spied upon using this data, that doesn't already involve much more data being known by the same spies? --Joy (talk) 17:43, 28 August 2024 (UTC)[reply]
The documentation is opaque about this. As unlikely as it seems and of such low value as to stagger the mind why anyone would try to exploit, it is theoretically possible to match user names visiting a low volume page during a specific period with the targets on WikiNav. Edit: thinking on this further, I don't see how user names could be correlated with WikiNav data, unless it is recorded somewhere else that isn't immediately obvious. olderwiser 17:50, 28 August 2024 (UTC)[reply]
Even so, it would be better for purposes of determining primary topic if such data were somehow masked rather than omitted. E.g, a group category such a "Internal-masked for privacy". olderwiser 17:56, 28 August 2024 (UTC)[reply]
I suppose it could be a way to to leak editor interests, for example if you see that in a certain month a single person edited pages X and Y, and there were only 3 clicks from Y to X, and only 2 clicks from X to Z, it's probable that the same person (account / IP address) visited Z.
Having this kind of data public could have a chilling effect on people editing.
What I see as a potential for improvement is to see if we can apply the threshold of 10 on a more aggregate set of data, so for example if there were 4 people going from empty via our page to X, and 7 people from search to X, and 3 people from Y to X, that we still get to know that 13 people went from our page to X. --Joy (talk) 18:53, 28 August 2024 (UTC)[reply]
I'm not sure I follow. Which side are we looking at? What is "our page" and what is 'X'? What does it mean to go from empty via our page to X?
Also, I just noticed that the Sources of Traffic section on WikiNav already lists the views for "Filtered", which if the footnote appearing at the head of the page is to be believed The pageviews from these removed observations are referred to as "filtered" elsewhere on this page. olderwiser 20:26, 28 August 2024 (UTC)[reply]
What I mean by our page is a page that we're looking at in WikiNav. If we're trying to figure out if a lot of people are clicking from a page to go to X, we want to see the where do they go from anonymized sources, too. By "from empty" I mean from incoming views that had empty referrer.
Yes, the filtered views are generally visible there. The same you can see indirectly by comparing N incoming pageviews in the top table with the footnoted actual number of incoming pageviews received of M.
There are cases where the amount of these filtered views is obviously significant. One that I remember seeing recently was Split, where it was 33% (530). Nothing needs to be done there, thankfully, but if it was necessary to analyze that, that's a big chunk of data that we're missing.
I went looking for some others, and found there's a fair few after guessing some items from Wikipedia:WikiProject Disambiguation/Popular pages, such as:
  • Drake 30% (3330)
  • Congo 27% (2041)
  • Trump 23% (9516)
  • Georgia 23% (2478)
  • Macron 22% (1798)
  • English 21% (2165)
  • Tesla 18% (1730)
  • Roma 18% (1170)
  • Mash 17% (1116)
  • Rugby 16% (1715)
  • Kamala 16% (1344)
  • Trap 15% (2278)
  • Kill 14% (1293)
  • Ass 14% (1208)
  • Alcohol 14% (1042)
  • Bing 13% (1035)
  • It 13% (918)
  • Brat 12% (828)
  • Alien 10% (844)
  • Kiwi 10% (753)
  • Gaelic 10% (704)
  • Phoenix 9% (644)
  • Alcaraz 8% (690)
  • John Hunt 7% (1239)
  • Poop 6% (1124)
  • IPA 8% (744)
  • Amazon 8% (723)
  • Go 6% (700)
  • Yes 6% (680)
  • Premium 2% (1347)
I included both the percentages and raw numbers to illustrate how sometimes there are are significant discrepancies.
A lot of pages I checked in turn also didn't have any appreciable number of these filtered views despite a lot of options and a lot of traffic, which I found to be somewhat odd, too.
In any case, that can definitely be a noticable chunk of traffic. --Joy (talk) 21:51, 28 August 2024 (UTC)[reply]
Does 'Filtered' ever show up in outgoing views? This could significant in that if the outgoing side of these pairs are removed from the outgoing views, then I agree that could be a problem. But if, for example the specific destinations are included with source masked, that really isn't any problem at all. olderwiser 22:14, 28 August 2024 (UTC)[reply]
No, I think that's the point of the anonymization, that's the definition of filtered - these won't be used to show outgoing clickstreams. Even if they cumulatively end up all the way up to hundreds and even thousands of requests in some of these cases, the filtering comes first.
Note that this also happens for items where a destination has a lot of visible clickstreams - there can be e.g. 25 Foo->Bar clickstreams that get rendered, but only 8 Quux->Bar and 7 Baz->Bar clickstreams and the latter get filtered, and we don't necessarily even get a good picture of how many people went to Bar even if it's ostensibly visible in the graphs.
The whole thing is predicated on hoping that the statistical distribution is kinda normal, and in general it could well be, but in each individual case, it doesn't have to be. --Joy (talk) 08:18, 29 August 2024 (UTC)[reply]
Hmm, curiouser and curiouser. I finally took a look at one of the TSV data files and while Excel dropped some portion of the data over 1048576 rows, the smallest count in what I can see is 12, which suggests that any combo with low counts are simply dropped from the data set. But if that is the case, then how do they calculate the percentage of "Filtered" for the incoming views? If they are able to calculate that for incoming, it should also be possible for outgoing views and that would at least provide an aggregate indication of how large the trailing tail count is. olderwiser 13:54, 29 August 2024 (UTC)[reply]
Yes, clickstream-enwiki-2024-07.tsv is over 34 million rows :)
WikiNav probably looks up the total incoming in the pageviews data, so for "split" that's like this: [3] -> 1611
And then compares it to what it sees in the clickstreams:
% grep -P '\tSplit\t' clickstream-enwiki-2024-07.tsv | awk '{ t += $4 } END { print t }'
1081
So 1611 - 1081 = 530 is missing in that case, that's what got filtered by the program that generates clickstreams. --Joy (talk) 17:56, 29 August 2024 (UTC)[reply]
BTW, this is also missing the total incoming redirect traffic there, which is: [4] 1771. So it could actually be 690 that got filtered out, almost 39%. --Joy (talk) 17:58, 29 August 2024 (UTC)[reply]
Interesting. At least for Split if makes little difference since there is no primary topic and the data doesn't support either of the two main destinations (unless you accept a fraction over 50% as primary). That likely would not change much based on the filtered rows unless all or most of them were for the city. I'm not sure about the redirects. The project page says Requests for pages that get redirected were mapped to the page they redirect to. I'm not sure what that actually means. It sounds like they are included and mapped to the target. Or it may refer only to the outgoing views. olderwiser 20:30, 29 August 2024 (UTC)[reply]
Yes, like I said before, there's nothing to do in that particular case, but the encyclopedia is huge, and there could be a fair bit of this out there. I didn't record this ratio in my statistics tracking endeavors so far so I don't have a ready-made ratio among the known recent examples. I could start recording that for the future.
The redirect requests being mapped simply means it's all squashed together. So for example next month the requests for "Heimlich" will be added to the requests for "Abdominal thrusts", just like all these others already were. So if there were 3 views of Heimlich procedure from a source like external search, and 1 thousand of the same at Abdominal thrusts, that in turn went to Henry Heimlich, the filtering starts at 1003, and so forth. --Joy (talk) 12:13, 30 August 2024 (UTC)[reply]
But you are correct that this is a potential issue to consider with low-traffic pages. olderwiser 17:35, 28 August 2024 (UTC)[reply]

Cleaning up INCDAB

He estado revisando las páginas de Categoría:Desambiguación con títulos (calificados) y he limpiado todos los casos sencillos, pero no estoy seguro de si mi "solución" para los últimos incdabs fue demasiado lejos (y de si debería revertirlos por mi cuenta). Específicamente, creé {{ anchor }} en secciones de lista dentro de artículos (que no son páginas dab ni listas, como se menciona en WP:INCDAB) donde los incdabs anteriores ahora redireccionan.

El valor de navegación/dab sigue intacto, pero creo que puede haber problemas con las páginas de Wikipedia:Desambiguación con enlaces a continuación. ¿Opiniones? – sgeureka t • c 14:51, 11 de septiembre de 2024 (UTC) [ responder ]