Tras un debate , el motivo de eliminación rápida "Páginas de archivo sin archivo correspondiente" se ha trasladado del criterio G8 al F2 . Esto no modifica lo que se puede eliminar rápidamente.
Se invita a los editores a nominarse para formar parte de la Comisión Electoral del Comité de Arbitraje de 2024 hasta las 23:59 del 8 de octubre de 2024 (UTC) .
Reuniones electrónicas del equipo de edición de MW, /wikimedia.org/edit-tasktriage a través de Google Hangouts (martes, de 12 a 12:30 p. m. PDT = 20:00 UTC durante el horario de verano, 19:00 en otros horarios, pero a menudo media hora antes).
Reuniones electrónicas de MW Tech Advice, a través de IRC en #wikimedia-tech connect (miércoles, 13:00–14:00 PDT = 16:00–17:00 UTC).
meta:Talk:Lista negra de spam: solicitudes de lista negra global
Billar sin taco
Irresoluto
– No puedo acceder al material en Ancestry; intenta usar tarjetas adicionales.
Algunas notas más sobreCristalizar
Irresoluto
– Se han incorporado nuevas fuentes y materiales al artículo, pero aún quedan preguntas sin respuesta.
WP:SAL
Irresoluto
– Aún no está terminado, la última vez que miré.
Publicas en Wikipedia discusión:FAQ/Copyright
Irresoluto
– Necesitamos arreglar a William A. Spinks , etc., con estadísticas de línea de base adecuadas, ahora que sabemos cómo interpretarlas.
Ji ja
Irresoluto
– Todavía tenemos que proponer algunas normas sobre la denominación y la desambiguación de artículos relacionados con las razas de animales. En los años transcurridos desde entonces, hemos optado por una desambiguación natural, no entre paréntesis, y por que las razas estandarizadas se escriban con mayúscula, pero eso es todo.
¿Oración redundante?
Irresoluto
– ¿Aún no se ha completado el trabajo de integración de WP:NCFLORA y WP:NCFAUNA en MOS:ORGANISMS ? Parece que ya está casi terminado, salvo por arreglar la sección de razas, después de esa solicitud de comentarios sobre mayúsculas de hace un tiempo.
Nota para mí sobreWP:WikiProject Idioma inglés
Irresoluto
– Creo que ya hice la MAYOR parte de esto…
Excelente mini-tutorial
Irresoluto
Página de inicio:MEDMOS
Irresoluto
– Corregir los accesos directos de WP: FOO a MOS: FOO , para que coincidan con la práctica en otras páginas de MoS. Esto solo se aplica a la sección de MoS allí; al igual que WP:SAL , parte de esa página también es una guía de contenido que no debería tener accesos directos de MOS:.
Ooh...potencialWikiGnomismoactividad...
Irresoluto
– ¿ Hago algo de esto cuando estoy aburrido?
Nota para mí
Irresoluto
– Ccita cosas...
Ahora esto
Irresoluto
– Desambiguación de razas otra vez...
PGP
Irresoluto
– Tengo que ponerme el sombrero de geek y arreglar esto.
Para tu información, parece que tu clave ha expirado. 1234qwer 1234qwer 4 21:57, 5 de noviembre de 2022 (UTC) [ responder ]
¡Ay! Gracias, tendré que generar uno nuevo cuando tenga tiempo para jugar con él. — SMcCandlish ☏ ¢ 😼 22:32, 5 de noviembre de 2022 (UTC) [ responder ]
Artículo en alemán sobre el tartán pata de gallo, el tartán de Border y patrones relacionados
Irresoluto
– Considerando…
de:Rapport (Textil) es un enfoque interesante y no parece que tengamos un artículo correspondiente. Algo que podría abordar en algún momento. — SMcCandlish ☏ ¢ 😼 22:11, 23 de marzo de 2024 (UTC) [ responder ]
Capitalización después de un guión
Hola. En 2020, trasladaste Three-Fifths Compromise a Three-fifths Compromise , con el resumen de edición WP:HYPHEN (no escribas con mayúscula después de un guion a menos que lo que sigue al guion sea en sí mismo un nombre propio). Tengo una pregunta al respecto: ¿estás seguro de que WP:HYPHEN dice "si lo que sigue a un guion es un nombre propio" en lugar de "si el compuesto con guion es un nombre propio"? Si tu interpretación de la redacción es correcta, entonces propondría que la exención para "títulos de obras publicadas" se extienda a todos los nombres propios. En el caso del Compromiso de los Tres Quintos, muchas fuentes escriben "quintos" con mayúscula, entre ellas AP, NYT, WaPo, Forbes, LA Times y Guardian, etc. Esto también es un caso atípico, ya que tenemos artículos como Coca-Cola ("cola" no es un nombre propio), Spider-Man ("man" no es un nombre propio), Quasi-War ("war" no es un nombre propio), Employment Non-Discrimination Act ("discriminación" no es un nombre propio), etc. InfiniteNexus ( discusión ) 19:37 1 dic 2023 (UTC) [ responder ]
Chicago:
Las siguientes reglas se aplican a los términos con guion que aparecen en un título en mayúscula en el estilo de encabezado [...]
Escriba siempre con mayúscula el primer elemento.
Escriba con mayúscula todos los elementos subsiguientes, a menos que sean artículos, preposiciones, conjunciones coordinantes ([...]) o modificadores similares [...] que siguen a los símbolos clave musicales.
Si el primer elemento es simplemente un prefijo o una forma combinatoria que no podría sostenerse por sí sola como palabra ( anti , pre , etc.), no escriba con mayúscula el segundo elemento a menos que sea un nombre propio o un adjetivo propio.
Escriba con mayúscula el segundo elemento de un número escrito con guión ( veintiuno o vigésimo primero , etc.) o una fracción simple con guión ( dos tercios en mayoría de dos tercios ).
Los ejemplos que siguen demuestran las reglas numeradas [...]
[...]
Préstamos récord de bibliotecas de tamaño mediano (2)
[...]
Actividades antiintelectuales (3)
Una mayoría de dos tercios de representantes que no hablan inglés (3, 4)
[...]
APA:
En mayúscula inicial, escriba con mayúscula las siguientes palabras en un título o encabezado:
[...]
palabras principales, incluida la segunda parte de las palabras principales con guión (por ejemplo, "Autoinforme", no "Autoinforme")
MLA:
Cuando copie un título o subtítulo en inglés [...] utilice mayúsculas al estilo de título: escriba con mayúscula la primera palabra, la última palabra y todas las palabras principales, incluidas aquellas que siguen a guiones en términos compuestos.
[...]
No escriba con mayúscula la palabra que sigue a un prefijo con guión si el diccionario muestra el prefijo y la palabra combinados sin guión.
Theodore Dwight Weld y la Sociedad Antiesclavista Estadounidense
AMOR:
En títulos, subtítulos y encabezados de texto, no escriba con mayúscula la segunda parte de un compuesto con guión en los siguientes casos:
Si alguna de las partes es un prefijo o sufijo con guión (ver [...])
Medicamentos antiinflamatorios no esteroides para la espondilitis anquilosante
Si ambas partes juntas constituyen una sola palabra (consultar [...])
Fiabilidad de la información sanitaria obtenida a través de búsquedas en línea sobre autolesiones [...]
Efectos a corto y largo plazo de los medios violentos sobre la agresividad en los niños
[...]
Sin embargo, si un compuesto es temporal o si ambas partes tienen el mismo peso, escriba con mayúscula ambas palabras.
[...]
Actividad de bajo nivel
Bacterias resistentes a los medicamentos
[...]
En títulos, subtítulos y encabezados de texto, escriba con mayúscula la primera letra de una palabra que siga a una letra griega minúscula (pero no mayúscula) (ver [...]), un número ([...]), un símbolo, una letra mayúscula independiente o un prefijo de química orgánica en cursiva, [...]
AP no menciona el uso de mayúsculas después de un guion, pero se da " The Star-Spangled Banner " como ejemplo de título (que también escribimos con mayúscula, ¿podrías mirarlo?).
@ InfiniteNexus : Se necesita más investigación del tipo mencionado anteriormente. Para profundizar un poco, descubro que la Guía de estilo MHRA [15] tiene una regla ridículamente inconsistente para escribir con mayúscula después de un guion, incluso cuando se trata de un prefijo que no puede estar solo, excepto cuando ese prefijo es específicamente Re- . No se da ninguna justificación para esta rareza. Creo que valdría la pena buscar en otras guías de estilo importantes y ver si realmente surge algo parecido a un patrón en gran medida consistente. Sus cuatro guías de estilo estadounidenses (al menos dos de las cuales, APA y AMA, han ido avanzando con el tiempo para ser cada vez más consistentes con Chicago en muchos puntos) no cubren suficiente terreno para que estemos seguros de esto. Y AMA está tratando de ser significativa pero fallando estrepitosamente. "Corto plazo" y "nivel bajo" son ambos el mismo tipo de término; lo mismo ocurre con "autolesión" y "resistente a los medicamentos". Todas ellas pueden separarse sin guiones, sin perder su significado: "Se observó un bajo nivel de resistencia a los medicamentos a corto plazo en un estudio de pacientes ingresados por autolesión". (Supongo que esto es lo que pasa cuando los médicos sin formación en lingüística intentan escribir material sobre la estructura y el uso del idioma inglés). Los compuestos unitarios con guion que aparecen a continuación no pueden separarse de esta manera (aunque algunos a veces se escriben coloquialmente como compuestos cerrados sin guiones: "knowhow" y "runnerup", pero no "fatherinlaw").
Si resulta que hay una tendencia demostrable en todas las guías de estilo principales, entonces probablemente podríamos resumirla con algo simplificado y fácil de recordar y aplicar, que podría ser algo como esto (se necesita más investigación):
En el caso del título, escriba con mayúscula después de un guion cuando el término compuesto sea temporal (normalmente, un modificador de varias palabras que se escribiría sin guiones si no se usara como adjetivo): Demografía inmobiliaria , Operación por control remoto , Pautas de sentido común . No escriba con mayúscula después de un guion si el término es un término compuesto con:
un prefijo ( Preeclampsia , Anti-establishment ), a menos que lo que sigue al guión sea un nombre propio Neoaristotélico ;
un sufijo ( dadaísta );
un compuesto con un significado sinérgico separado del de sus partes y que casi siempre va unido con guión ( Suegro , Saber hacer , Subcampeón ).
Una construcción como esta evitaría la confusión categórica de AMA; evitaría ideas altamente debatibles como "constituyen una sola palabra", "si ambas partes tienen el mismo peso", "palabras principales", "palabras mayores"; evitaría las tonterías del "diccionario" (no existe "el" diccionario, sino muchos diccionarios que a menudo entran en conflicto entre sí y tienen diferentes niveles de enfoque prescriptivo versus descriptivo); y evitaría frikismos quisquillosos que a nadie le interesan, como los símbolos de las claves musicales y los prefijos de química orgánica en cursiva (no deberíamos abordar minucias como esas a menos que surja una disputa a largo plazo al respecto, según WP:CREEP y WP:MOSBLOAT ).
Sin embargo, encuentro muy dudoso el "segundo elemento en un número escrito con guión" y lo mismo con las construcciones "-century"; he visto muchos títulos de cosas que usan "Veintidós", "Quincuagésimo tercero" y "Siglo IV"; este es uno de los varios casos que necesitan más investigación en más guías de estilo. Y al final, no estamos obligados a hacer lo que parece inclinarse una preponderancia vaga de otras guías de estilo, especialmente cuando se contradicen entre sí en cuanto a detalles y fundamentos; simplemente son debidamente informativas con respecto a lo que decidimos. Pero necesitamos decidir algo , ya que el material existente en MOS:TITLES tiene un vacío, y la gente no se pone de acuerdo sobre lo que encaja dentro de él.
PD: Su " The Star-Spangled Banner " se da como ejemplo de un título (que también escribimos con mayúscula, ¿lo vería?) y sonreír con sorna no es constructivo. Usted sabe tan bien como yo que el contenido de WP no es una fuente y que los editores que hacen cosas estilísticamente cuestionables en un artículo en particular no tienen nada que ver con si se debe cambiar una regla de estilo que tenemos. Más concretamente, las guías de estilo que citó no están de acuerdo al respecto y AMA, por ejemplo, lo pondría como "The Star-spangled Banner" porque "star-spangled" no es un compuesto temporal sino un neologismo poético del siglo XVIII que es un término unitario y parece no tener casi existencia sin el guion. MLA también escribiría "-spangled" con minúscula debido a su regla de diccionario [16]. — SMcCandlish ☏ ¢ 😼 01:43, 29 de diciembre de 2023 (UTC) [ responder ]
Si aún estás interesado en investigar esto, no dudes en hacerlo, pero ahora mismo no tengo tiempo para seguir profundizando en este asunto. Las cuatro (cinco, si contamos a AP) guías de estilo que miré son probablemente las más utilizadas en los EE. UU., por lo que parece seguro asumir que esta es la norma entre la mayoría de las guías de estilo externas. No tengo acceso a guías de estilo de otros países. InfiniteNexus ( discusión ) 07:35, 29 de diciembre de 2023 (UTC) [ responder ]
@ JMF : Creo que en el caso Gill (si lo estoy leyendo bien), la objeción de la otra parte era incluir referencias entre paréntesis en línea con números de página, algo que la comunidad también desaprobaba ya, es decir, hacer cosas como "Esto es una afirmación (Smith 2023, p. 7)", en lugar de "Esto es una afirmación <ref>Smith 2023, p. 7.</ref>", o los equivalentes en plantilla "Esto es una afirmación <ref>{{harv|Smith|2023|p=7}}</ref>", o "Esto es una afirmación {{sfn|Smith|2023|p=7}}". En realidad, es posible que 14GTR se opusiera literalmente a incluir números de página en cualquier forma, en cuyo caso su argumento no tiene fundamento en WP:P&G y debería simplemente ignorarse.De repente, se me ocurre una idea: se puede argumentar con fuerza que, dado que la comunidad claramente desaprobó las referencias entre paréntesis en línea en 2020 ( WP:PAREN ), y la razón para hacerlo fue su perturbación del flujo de lectura, no el hecho de que estuvieran involucrados caracteres de corchetes, esto en realidad se traduce automáticamente en una desaprobacióntambién. Es simplemente otro formato para hacer referencias entre paréntesis en línea (su propia documentación establece explícitamente que es una adaptación de "referencia completa de Harvard y estilo AMA", aunque en última instancia soy yo cito a mí mismo), solo que con menos detalles y usando superíndice y dos puntos, en lugar de más detalles con corchetes y sin superíndice ni dos puntos. Es decir, la desaprobación es de citas que son en línea y entre paréntesis , no en línea y que usan lo que los estadounidenses llaman paréntesis (corchetes). Entonces, reemplazando "Esto es una afirmación (Smith 2023, p. 7)". pero mantener "Esto es una afirmación" para producir "Esto es una afirmación. [1]:7 " es simplemente desafiar ese consenso de todo el sitio al seguir poniendo parte de la cita (números de página u otras ubicaciones en la fuente) en línea entre paréntesis, especialmente dado que la plantilla se puede usar para producir cosas como "Esto es una afirmación. [1]:viii–xiv, 7–9, 12 y contraportada ". De hecho, Wikipedia:Citar fuentes#Generalmente se considera útil ya incluye "convertir la referencia entre paréntesis a un estilo de referencia aceptable". Por lo tanto, en realidad podría probar ese argumento ahora mismo al hacer la limpieza de.{{Rp}}<ref>Smith 2023.</ref>{{Rp|7}}{{Rp}}Debido a la estupidez de "que reine el caos" que es WP:CITEVAR , algunas personas probablemente intentarán argumentar en contra de esto, pero creo que su caso será débil y fácilmente desinflado. Dicho esto, probablemente el único camino hacia una limpieza total será documentar completamente cómo convertir a otros formatos, y por qué es una buena idea y por qué es mala, y luego tener un RfC o TfD de seguimiento para desaprobar formalmente y ordenar su reemplazo (principalmente por AWB y, a veces, incluso por bots para casos simples), de modo que ya no se considere un "estilo de cita" válido para los propósitos de CITEVAR, sin duda alguna. Y creo que el trabajo de hacer esa documentación estará en mis manos, aunque no estoy demasiado ansioso por meterme en eso ahora mismo. Me da dolor de cabeza solo pensarlo. — SMcCandlish ☏ ¢ 😼 21:04, 18 de diciembre de 2023 (UTC) [ responder ]{{Rp}}{{Rp}}{{Rp}}
La respuesta de obstruccionismo fue muy similar a lo que esperaba, aunque tenía la esperanza de que el tiempo y la oferta de una escalera para bajar pudieran resolver el problema. AFAICS, la única manera de avanzar es proponer formalmente que {{ rp }} se desestime en favor de las referencias de Harvard. El problema es que, cuando intenté usar el método {{ harvid }} hace tiempo, lo encontré hostil. Persistí y las cosas mejoraron mucho cuando encontré {tl|sfnp}}. Pero otros editores pueden haberse quemado los dedos y se resistirán, basándose en su mala experiencia en aquel entonces. Entonces, ¿puede ser necesario preparar el terreno con explicaciones y educación? -- 𝕁𝕄𝔽 ( discusión ) 20:00, 20 de diciembre de 2023 (UTC) [ responder ]
A mí también me llevó "un minuto" darme cuenta. Comencé el trabajo de documentar completamente cómo reemplazar , en User:SMcCandlish/Replacement of Template:Rp . Aún necesito más información y una corrección para detectar cualquier error de marcado que estropee alguno de los ejemplos de código. — SMcCandlish ☏ ¢ 😼 09:46, 21 de diciembre de 2023 (UTC) [ responder ]{{rp}}
Actualizaciones incrementales
Actualización: esto va muy lento, pero me comprometo a trabajar en ello. Requerirá un montón de expresiones regulares muy bien probadas, utilizadas en serie en un script de usuario JS, para capturar y limpiar una gran cantidad de casos de uso de contenido, de modo que produzca un formato de cita uniforme (y sin romper nada). Mi trabajo anterior documentado en la página mencionada anteriormente ya ha sido superado, en el código que estoy desarrollando fuera del sitio. Comenzaré a construir las expresiones regulares en las que estoy trabajando en un JavaScript muy pronto y comenzaré a probarlo con contenido real y refinándolo. Una vez que funcione de manera confiable para todos los casos de prueba válidos y la mayoría de los casos de prueba sensatos pero no válidos, entonces podremos hacer operaciones de búsqueda y reemplazo que tendrán resultados predecibles con errores mínimos. Este será un gran proyecto. Fue más difícil de lo que esperaba porque la sintaxis XML (¡y mucho menos XML mezclado con una sintaxis!) es increíblemente difícil de analizar con precisión con expresiones regulares (o cualquier otra cosa, de hecho) de manera confiable. He estado usando herramientas avanzadas como regex101.com con blobs complejos de entradas de casos de prueba válidos e inválidos, y usando ChatGPT para intentar resolver errores de coincidencia particularmente espinosos, etc. Como ejemplo, solo una de las expresiones regulares desarrolladas hasta ahora se parece a , e incluso esto aún no puede manejar la normalización de la parte, solo para evitar romper una referencia que tiene una parte (y aún no hace nada para normalizar la última parte, solo la primera). — SMcCandlish ☏ ¢ 😼 00:06, 28 de diciembre de 2023 (UTC) [ responder ]{{rp}}{{...}}<ref\s+name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))\s*(?:(\/)|)><ref name=foo group=bar>name=group=
Ahora analiza incluso cosas como <ref group="bar's > / bar" extends=baz name='foos > / foo' follow="quux quux" />(y parte del código que tiene en cuenta solo está en la versión beta de mw:Help:Cite y aún no se ha implementado en en.WP), aunque esta expresión regular solo corrige el name=parámetro; otros pases con expresiones regulares similares manejarían otros atributos como group=normalizar su formato. Luego, otro pase para corregir el espaciado que no debería existir entre citas. Y así sucesivamente. Y, por supuesto, un pase para reemplazar con o lo que sea. Como digo, un proceso de varios pasos que se realizará utilizando las expresiones regulares en JS. La expresión regular en cuestión ahora es la monstruosa . Me sorprende haber logrado esto. Su única falla es que no puede manejar elegantemente la forma válida para XML (pero técnicamente no válida para referencias) (valor entre comillas simples con comillas dobles anidadas) o la completamente inválida ; eso es algo que deberá manejarse con un pase de limpieza anterior que busque solo esos problemas específicos. — SMcCandlish ☏ ¢ 😼 02:02, 28 de diciembre de 2023 (UTC) [ responder ]{{rp}}{{sfnp}}<ref\s+((?:group|follow|extends)\s*=(?:(?!name\s*=).)*)?name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))(\s+(?:group|follow|extends)\s*=(?:(?!\s*\/>|\s*>).)*)*\s*(?:(\/)|)>name='foo "bar" baz'name="foo "bar" baz">
Se actualizó Regex nuevamente para manejar saltos de línea entre <ref>atributos, así como también > dentro de atributos entre comillas después de name=.
La nueva expresión regular (solo para manejar namecon o sin otros atributos presentes) es:<ref\s+((?:group|follow|extends)\s*=(?:(?!name\s*=)[\s\S])*)?name\s*=\s*(?:"\s*([^"](?:(?!\s*\/>|\s*"\s*>|\s+(?:group|follow|extends)).)*?)\s*"|'\s*([^'"](?:(?!\s*\/>|\s*'>|\s+(?:group|follow|extends)).)*?)\s*'|([^"](?:(?!\s*\/>|\s*>|\s+(?:group|follow|extends)).)*))(\s+(?:group|follow|extends)\s*=(?:(?!\s*\/>|"\s*>|'\s*>)[\s\S])*)*\s*(?:(\/)|)>
Ya es lo suficientemente sofisticado como para manejar entradas tan horribles como:
Ni siquiera <syntaxhighlight>puedo lidiar con lo anterior, pero lo que estoy escribiendo sí. Este solo limpia name(para name="foos > / foo"eliminar el desorden anterior y, mientras tanto, elimina el salto de línea antes del cierre />); expresiones regulares similares en pases posteriores se ocuparán de group, etc., y luego, eventualmente, del reemplazo. — SMcCandlish ☏ ¢ 😼 03:27, 29 de diciembre de 2023 (UTC) [ responder ]{{rp}}
Recordatorio para mí: En algún momento, el script también tendrá que tener en cuenta {{#tag:ref |Citation content here. |name=... |group=... |follow=... |extends=...}}(con parámetros en varios órdenes y con o sin saltos de línea y espaciado extraño). — SMcCandlish ☏ ¢ 😼 03:37, 29 de diciembre de 2023 (UTC) [ responder ]
@ JMF : Listo. — SMcCandlish ☏ ¢ 😼 01:43, 29 de diciembre de 2023 (UTC) [ responder ]
Vautores
Es posible que decirle a la gente cómo escribir citas de harv esté fuera del alcance, pero pensé que debería marcar esto para que lo incluyas o ignores, según tu decisión. Recién descubrí la función {{ref={{sfnref|blah blah}} }} y es mucho más conveniente que agregar first=/last= a todos y cada uno de los nombres, solo para que puedas escribir {{sfnp|last1|last2|last3|last4|2024}}. Aquí hay un ejemplo de prueba:
Wang T, Mo L, Mo C, Tan LH, Cant JS, Zhong L, Cupchik G (junio de 2015). "¿La belleza moral es diferente de la belleza facial? Evidencia de un estudio fMRI". Neurociencia cognitiva social y afectiva . 10 (6): 814–23. doi :10.1093/scan/nsu123. PMC 4448025 . PMID 25298010.
Tendré que tenerlo en cuenta |vauthors=en la documentación y en los scripts eventualmente. Pero |vauthors=no debería usarse excepto en un artículo hecho completamente con referencias al estilo Vancouver (o va en contra de las instrucciones de WP:CITESTYLE de usar un estilo de referencia consistente). Es una mala idea usar ese estilo en primer lugar porque genera metadatos de autor menos útiles y, mucho más importante, es más difícil de analizar para los lectores (es menos claro que algo como "Tan LH" sea el nombre de una persona que "Tan, LH" que coincide con el resto de nuestro formato de iniciales y otro manejo de nombres, especialmente cuando "Tan LH" aparece en un artículo que usa citas que generan "Tan, LH"), y es más propenso a errores para los editores porque este extraño formato de nombre debe hacerse exactamente a la perfección en ese parámetro. Otro defecto grave es que a menudo conocemos los nombres completos de los autores (y esto puede ser bastante útil para distinguir a los autores e incluso para encontrar la fuente en primer lugar si se trata de algo sin una URL o DOI de lectura gratuita), pero |vauthors=nos obliga a eliminar la mayor parte de la información de los nombres que ya tenemos; es un perjuicio para los lectores y para los editores que realizan el trabajo de verificación. Cada vez que me encuentro con un |vauthors=en un artículo que no se ajusta de manera constante al estilo Vanc, lo reemplazo con un conjunto de |last1=|first1=... (a menos que tenga mucha prisa o algo así), a menudo con nombres de autor más completos.El uso de aka no depende de ninguna manera de .|ref={{sfnref|...}}|ref={{harvid|..}}|vauthors=Además, el Lua detrás de las plantillas de citas ya puede analizar los nombres dentro |vauthors=(si se hicieron correctamente) y usarlos con , , etc., directamente. Si eliminamos el de su ejemplo:{{sfnp}}{{harvp}}|ref={{sfnref|Wang ''et al''|2015}}
A continuación se incluye una afirmación en el artículo. [1]
Referencias
^ Wang y otros (2015).
Fuentes
Wang T, Mo L, Mo C, Tan LH, Cant JS, Zhong L, Cupchik G (junio de 2015). "¿La belleza moral es diferente de la belleza facial? Evidencia de un estudio fMRI". Neurociencia cognitiva social y afectiva . 10 (6): 814–23. doi :10.1093/scan/nsu123. PMC 4448025 . PMID 25298010.
El uso de la expresión automatizada es más claro y sencillo que el uso de a junto con . Y no parece haber un consenso sobre si "et al." debería ir en cursiva como en latín, porque está muy asimilado al inglés, como "ie" y "eg"; no creo que ninguna de nuestras plantillas de citas lo ponga en cursiva. (Pero debería tener un "." después, en cursiva o no, incluso en el uso británico, ya que es una abreviatura de truncamiento de et alia ). Incluso sin la cursiva, el uso de la expresión automatizada sigue siendo más claro y sencillo que el uso de a junto con . — SMcCandlish ☏ ¢ 😼 23:23, 29 de diciembre de 2023 (UTC) [ responder ]{{sfnp|Wang|Mo|Mo|Tan|2015}}|ref={{sfnref|Wang ''et al''|2015}}{{sfnp|Wang ''et al''|2015}}{{sfnp|Wang|Mo|Mo|Tan|2015}}|ref={{sfnref|Wang et al.|2015}}{{sfnp|Wang et al.|2015}}
Ah, no me había dado cuenta de que {{ sfnp }} podía deconstruir una lista de vauthors. Podría haberme ahorrado muchos problemas. Ahora me he dado más problemas para rehacerlo correctamente. ;-^
(Yo también prefiero cambiar una lista de vauthors a |first1= last1= first2= last2=etc. Generalmente evito usarlo al crear una cita excepto cuando los autores son chinos o japoneses pero el artículo está en inglés: ¿cómo sé si es last=Mao first=Tse Tung o viceversa? Confieso que también lo uso cuando se enumeran diez autores, por ejemplo en los artículos del IPCC). -- 𝕁𝕄𝔽 ( discusión ) 17:18 30 dic 2023 (UTC) [ responder ]
Bueno, como dije en la otra página, nadie será "castigado" nunca por mezclar estilos de cita. :-) Alguien más podría reorganizarlo más tarde. Puede ser una molestia. Me irrité bastante al arreglar una instancia de vauthor atascada en un artículo que de otra manera no sería de Vancouver, ya que tenía más de 30 autores. He visto a alguien reducir esto a los primeros cuatro pares de apellido/primero y luego hacer |display-authors=etal, pero estoy un poco desanimado porque teníamos más información del autor y al hacer eso se eliminó. Creo que crearé un script para convertir de vauthors a apellido/primero, al menos para mi propia conveniencia, pero probablemente después de hacer este gran trabajo de limpieza de referencias y reemplazo de rp primero.
En cuanto a los nombres asiáticos, supongo que basta con guiarse por lo que dice la publicación; si es "Chaudhary, C.; Richardson, AJ; ...", y tenía un "Hua, X." o raramente, pero a veces en el material sinológico, "Hua X" sin coma, en la lista de autores, eso ya indica el orden del apellido. Pero si la lista de autores del artículo comenzaba con "Chetan Chaudhary, Abigail Richardson, ..." e incluía algo como "Hua Xiang", entonces podría ser ambiguo; ¿mantuvieron el mismo orden o dieron los nombres chinos en orden de apellido primero? No estoy seguro de que vauthors ayude en este caso, ya que no estaría seguro de si usar "Hua X" o "Xiang H". Un poco de familiaridad con los patrones de nombres del este de Asia ayuda. Un nombre como "Hua Xhiangshu" o "Hua Xhian-shu" o "Hua Xiang-Shu" (la ortografía varía) sería el apellido primero. Las personas con más experiencia que yo pueden descifrar los nombres japoneses con solo saber cuáles se dan habitualmente y cuáles son los apellidos. En general, no sé qué decir del coreano, a menos que siga el patrón chino ("Lee Joon-gi" o "Lee Joon-Gi" o "Lee Joongi" es el apellido primero). Ayuda un poco el hecho de que algunos apellidos coreanos son abrumadoramente comunes, como Park/Pak/Paik, Lee/Li, Jun/Joon/June, Song/Sung y Kim. Cuando no estoy seguro, suelo buscar en Google otras obras de la misma persona hasta que puedo averiguarlo. Si no pudiera hacerlo, probablemente usaría |author4=Hua Xiangel orden de los nombres que había encontrado (en absoluto o más comúnmente) y dejaría que alguien con experiencia en el idioma o la cultura lo averiguara más tarde. Tal vez poner un comentario HTML a tal efecto. — SMcCandlish ☏ ¢ 😼 22:52, 30 de diciembre de 2023 (UTC) [ responder ]
PD: Según tengo entendido, la "traducción" de vauthors a sfnp/harvp utiliza los nombres de los autores hasta los primeros cuatro. No estoy seguro de lo que sucede cuando alguien tiene una cita principal con |vauthors=Chaudhary C, Richardson AJ, Hua X|display-authors=etal. No estoy seguro de si esto último es solo una inyección visual de "et al.", o si cuenta como un cuarto nombre de autor y requeriría . Sospecho que no, pero es algo para probar en un entorno de pruebas. — SMcCandlish ☏ ¢ 😼 23:04, 30 de diciembre de 2023 (UTC) [ responder ]{{sfnp|Chaudhary|Richardson|Hua|et al.|2023}}
Juegos
S, sé que te gustan los juegos y sus mayúsculas, así que echa un vistazo a la Lista de juegos de estrategia abstracta . Ya he puesto en mayúsculas un montón de juegos que figuran allí, pero hay algunos con los que no estoy seguro de qué hacer, como Conecta cuatro , que podrían ser marcas comerciales o podrían ser genéricos. ¿Tienes alguna idea o consejo sobre ellos? Dicklyon ( discusión ) 07:25, 20 de diciembre de 2023 (UTC) [ responder ]
Echaré un vistazo, pero estoy en medio de algunos detalles. — SMcCandlish ☏ ¢ 😼 09:29, 21 de diciembre de 2023 (UTC) [ responder ]
@ Dicklyon : Para ese, tenemos un título de artículo de Connect Four y una introducción que comienza con "Connect Four (también conocido como Connect 4, Four Up, Plot Four, Find Four, Captain's Mistress, Four in a Row, Drop Four y Gravitrips". "Connect Four" parece tener su origen en una marca registrada de Milton-Bradley (ahora Hasbro, después de la fusión), junto con la ortografía posterior de "Connect 4". Y en inglés, probablemente sea WP:COMMONNAME, incluso si preferiríamos lo contrario. Es posible que algunos de los otros nombres sean marcas comerciales (o constituyan títulos de obras en forma de variantes publicadas comercialmente de este juego, más específicamente), pero sería necesario investigarlos uno por uno, y los que no son marcas comerciales se escribirían en minúscula. Y podría ser más WP:NPOV reescribir la mayor parte del artículo para usar uno de los nombres que no son de marca registrada en minúscula, y solo usar "Connect Four" o "Connect 4" cuando se haga referencia a MB–Hasbro específicos. productos/publicaciones.Lo que actualmente está en " score four " parece que debería ser " Score Four " (marca registrada de Funtastic en 1968, también conocida como "Connect Four Advanced" de Hasbro más tarde); no parece haber un nombre genérico para esa variante. Y, de todos modos, soy escéptico de que sea un artículo independiente válido en lugar de una sección en Connect Four ; parece que no pasaría una prueba GNG en AfD.No miré de cerca otros ejemplos. ¿Hubo otros que no me parecieron muy buenos? — SMcCandlish ☏ ¢ 😼 01:43, 29 de diciembre de 2023 (UTC) [ responder ]
Claro, hay muchas que pueden ser dudosas, como la que hice aquí. ¿Estás de acuerdo? ¿Y qué pasa con cosas como Five Field Kono , que suelen tener un límite de fuentes sin ningún motivo aparente? Dicklyon ( discusión ) 05:51 29 dic 2023 (UTC) [ responder ]
La limpieza en peralikatuma me parece perfecta. Y five field kono (¿ni siquiera una redirección ahí? Por Dios...) es un juego popular, no una marca registrada/publicación, por lo que debería estar en minúsculas y como: five-field kono ( five-field {{lang|ko-Latn|kono}}) – según MOS:HYPHEN y MOS:FOREIGN . El artículo padre gonu tiene problemas similares. Este es el tipo de cosas que MOS:GAMECAPS pretende abordar específicamente (junto con la sobrecapitalización de cosas como deportes, bailes populares, movimientos y técnicas de deportes/baile, piezas de juego, instrumentos musicales, etc.). Al menos para el futuro inmediato, tenemos una excepción extraña, para go (game) , que actualmente se está representando como "Go", pero obviamente debería ser go ( ), pero necesitaríamos otra RfC para deshacer la anterior que llegó a "Go" a través de lo que parece ser un WP:LOCALCONSENSUS basado en WP: SSF . Pero de ninguna manera "Go" es una especie de excusa para "poner en mayúsculas todos los juegos populares asiáticos". Así que, kono/gonu . — SMcCandlish ☏ ¢ 😼 06:20, 29 de diciembre de 2023 (UTC) [ responder ]{{lang|zh-Latn|go}}
Gracias, arreglé algunos más. Sin embargo, en general, todavía hay un montón de sobrecapacidades en los juegos. Dicklyon ( discusión ) 18:27, 29 de diciembre de 2023 (UTC) [ responder ]
Sí, lo hay. Probablemente todavía esté en muchos artículos sobre danza, aunque he eliminado muchos de ellos. Los deportes en general se ven bastante bien, pero todavía me encuentro con algunos artículos poco conocidos que usan demasiadas mayúsculas. — SMcCandlish ☏ ¢ 😼 23:24, 29 de diciembre de 2023 (UTC) [ responder ]
Tecnología Dahua
Hecho
Hola SMcCandlish, noté que formas parte de la categoría de wikipedistas dispuestos a brindar terceras opiniones [17]. He estado trabajando en Dahua Technology y espero que te interese revisar una discusión en curso en la página de discusión sobre la terminología específica utilizada en el artículo. Agradecería tus comentarios y ayuda para implementar las modificaciones que consideres necesarias. Gracias, Caitlyn23 ( discusión ) 19:23, 20 de diciembre de 2023 (UTC) [ responder ]
Intentaré investigarlo mañana, pero ya ha sido un día muy largo para mí. — SMcCandlish ☏ ¢ 😼 09:31, 21 de diciembre de 2023 (UTC) [ responder ]
Más bien al día siguiente o al día siguiente; hay muchas cosas sucediendo. — SMcCandlish ☏ ¢ 😼 10:00, 22 de diciembre de 2023 (UTC) [ responder ]
Hola SMcCandlish, solo quería volver a consultar si tienes tiempo para revisar la discusión en la página de discusión de Dahua Technology . Me interesaría escuchar tus opiniones y agradecería tu ayuda con las ediciones. Gracias de nuevo, Caitlyn23 ( discusión ) 18:22, 28 de diciembre de 2023 (UTC) [ responder ]
@ Caitlyn23 : Esto no es realmente un asunto de Wikipedia:Tercera opinión , porque no es una disputa entre dos editores; más bien, ha habido una serie de discusiones de consenso con una resolución poco clara. Sería mucho más apropiado que yo simplemente interviniera como uno de esos editores, en lugar de intentar hacer lo que equivale a arbitrar entre un editor (tú) y un grupo de otros editores (con opiniones diferentes, pero algunas de ellas en contra de las tuyas). Ya lo he hecho, sugiriendo un enfoque de compromiso que ambas partes, con suerte, encontrarán viable. — SMcCandlish ☏ ¢ 😼 01:43, 29 de diciembre de 2023 (UTC) [ responder ]
Billar artístico
¡Hola! He trabajado un poco en el billar artístico durante los últimos días. Nunca había visto un partido, pero hace poco encontré un video en YouTube y es muy divertido. Es una pena que sea tan difícil encontrar un video detallado. He añadido algo de información de Trick Shot sobre el billar artístico, pero no estoy muy familiarizado con el tema. ¿Hay alguna fuente curiosa fuera del libro de Shamos sobre estos términos? Google no es de mucha ayuda. Lee Vilenski ( discusión • contribuciones ) 13:13, 27 de diciembre de 2023 (UTC) [ responder ]
@ Lee Vilenski : No que yo sepa, o ya habría dividido el billar artístico en un artículo propio. Sé que Tom "Dr. Cue" Rossman está muy involucrado en el billar artístico (o al menos lo estaba alrededor de 2010). Las revistas de billar antiguas como Inside Pool y Billiards Digest de esa época probablemente tengan algo de cobertura, pero ya no tengo una colección de ese material (solía vivir en un espacio de almacén reconvertido con un montón de espacio, pero ahora es un apartamento pequeño, así que tuve que reducir mucho el tamaño). AZBilliards puede tener algo de cobertura, y puede haber información histórica entre los propios materiales en línea de Rossman. En cuanto al billar artístico [carambola], el carambola en general no es muy popular en el mundo de habla inglesa, pero es un gran problema en otros lugares, por lo que esperaría que haya más materiales de referencia disponibles en francés, italiano, español y chino, entre otros idiomas en el "mundo del carambola".Una pequeña preocupación es que Trick shot#Artistic pool y Artistic billiards#Artistic pool son básicamente casi idénticos WP:CFORKS . La parte principal del material debería fusionarse con el primero, y el segundo debería reducirse a un resumen comprimido, con al principio. — SMcCandlish ☏ ¢ 😼 23:13, 27 de diciembre de 2023 (UTC) [ responder ]{{Main|Trickshot#Artistic pool}}
Eso ya lo pensé. Estoy en proceso de fusión, aunque no veo realmente cómo Trickshot sería el artículo principal de los dos. Tal vez no sé lo suficiente sobre el tema. Lee Vilenski ( discusión • contribuciones ) 09:21, 28 de diciembre de 2023 (UTC) [ responder ]
@ Lee Vilenski : Bueno, el pool artístico, el billar artístico y el snooker con trucos son esencialmente subtemas (variantes específicas de la disciplina) del tema de los trucos . El billar artístico está bien desarrollado en material enciclopédico suficiente para un artículo independiente. El pool artístico se está dirigiendo lentamente en esa dirección; el snooker con trucos aún no (aunque hay al menos un artículo específico sobre la competición). Pero el pool artístico (en una mesa de billar de seis troneras) no es un subtema del billar artístico (en una mesa de carambola sin troneras). — SMcCandlish ☏ ¢ 😼 01:43, 29 de diciembre de 2023 (UTC) [ responder ]
SMcCandlish , que tengas un próspero, productivo y agradable Año Nuevo , y gracias por tus contribuciones a Wikipedia. Abishe ( discusión ) 14:17 1 ene 2024 (UTC) [ responder ]
¿Sabes si el Speed Pool existe realmente? No se ha encontrado información sobre él durante una década y no pude encontrar mucho más al respecto, aparte de algunos torneos con el mismo nombre. No me parece que sea algo destacable, pero pensé que lo comprobaría primero. Lee Vilenski ( discusión • contribuciones ) 23:52, 1 de enero de 2024 (UTC) [ responder ]
Definitivamente es una disciplina competitiva profesional. Jeanette Lee era una gran fanática de ella, incluso antes de sus problemas médicos. AZBilliards y otros sitios probablemente tengan una buena cobertura de la misma que aún no citamos. — SMcCandlish ☏ ¢ 😼 00:19, 2 de enero de 2024 (UTC) [ responder ]
— SMcCandlish ☏ ¢ 😼 16:14, 7 de enero de 2024 (UTC); actualizado: 02:52, 24 de febrero de 2024 (UTC) [ responder ]
Cortar en cubitos
Hola. Verás que mi edición fue un error tipográfico, ya que "reclamé", ya que inexplicablemente escribí "qs", no "Vide", y lo corregí.
Yo diría que, al ser un diccionario en línea, la gente que lo lee, por naturaleza, tiene interés en lo que no entiende; que no se deben usar palabras (aunque no era mi intención) que "... más de unas pocas..." (sic) entiendan debería ser persuasivo sólo si no escribiéramos en inglés: usar eso como guía ahora (no es que eso contravenga ninguna regla de Wikipedia) debería significar que en algún momento pasado alguien declaró que lo es , de todos modos; y debe haber sido en algún momento entre una de las formas de habla celta utilizadas en Gran Bretaña y hoy, ya que estamos usando inglés aquí; palabras que, en un momento, "... no más de unas pocas..." conocíamos, lo que significa que todavía podríamos estar leyendo anglosajón. Entonces, ¿cuándo se convirtió en una regla excluir lo desconocido? Todavía se publican diccionarios para explicar palabras nuevas y desconocidas; una búsqueda que ahora esta guía prohíbe.
Es cierto que habría podido hacer de 'Vide' un enlace; pero lo que es conversacional para algunos es tan abstuso como los razonamientos de otros.
Sí, se mencionó más arriba; pero no se leen todas las secciones y subsecciones, y las palabras enfatizadas que ocupan el espacio de una vieja mancha de tinta podrían muy bien (para la mayoría, no "los pocos" que se saltan lo que leen) haber sido las inofensivas que transmitían la distinción entre tartán y dados.
De todos modos, un saludo. Heath St John ( discusión ) 19:46 8 enero 2024 (UTC) [ responder ]
@Heath St John: Lo siento por la parte "no fue una corrección de errores tipográficos"; había visto ambas ediciones como una única diff combinada , y solo estaba visible el resumen de la edición de la segunda, por lo que parecía que la adición de la referencia cruzada se alegó como una corrección de errores tipográficos. Debería haber comprobado si se trataba de más de una edición con fundamentos de resumen de edición distintos. De todos modos, Wikipedia no usa qv (lo que supongo que pretendía qs ) o vide de esta manera. Son desconocidos para demasiados lectores y realmente no sirven para ningún propósito aquí (principalmente porque Wikipedia no es paper ). Si la mención estaba allí mismo en el mismo bloque de texto (como estaba en este caso), no hay razón para decirle a la gente dónde está; y si está muy separada, en una sección diferente, lo que hay que hacer, si realmente parece necesaria una referencia cruzada, es vincular a esa sección, por ejemplo, con o lo que sea, que produce un resultado como ( ver más abajo ). El propósito habitual de qv es hacer referencia a un lema, como el que se encuentra en un glosario ; y vide se usa generalmente en material académico para referirse a un pasaje específico (y su uso no proporcionó tal especificidad). De todos modos, la sección principal en Sillitoe tartan ahora es incluso más clara de lo que era, con las sutilezas terminológicas consolidadas, por lo que ya no hay lugar para la confusión. PD: El estilo de Wikipedia para latinismos abreviados como " qv ", "ie", "eg" y "et al." es usar los puntos, y los que se asimilan bien en el inglés no especializado no se escriben en cursiva, mientras que los más oscuros como " qv ", " pmv " y " op. cit. " (muchos de ellos son legalismos o academicismos) se escriben en cursiva. "Et al." es en realidad un caso extremo con respecto a las cursivas; hay o hubo recientemente una discusión abierta sobre esto, aunque no recuerdo dónde. (Frustrante, ya que iba a comentarlo). — SMcCandlish ☏ ¢ 😼 20:55, 8 de enero de 2024 (UTC) [ responder ]{{see below|[[#History|below]]}}
Muy claro.
Muchas gracias. Heath St John ( discusión ) 21:03 8 ene 2024 (UTC) [ responder ]
Empujando frijoles
Hola. En el futuro, espero que puedas tomarte un tiempo y considerar WP:AGF en lugar de insinuar que alguien está ocupado metiéndose frijoles por la nariz, como hiciste en este resumen de edición . Ya hay demasiadas restricciones en el proyecto y no creo que quieras que parezca que estás haciendo eso. -- Mikeblas ( discusión ) 02:04, 10 de enero de 2024 (UTC) [ responder ]
No hay falla de AGF ni control de acceso en nada de lo que dije, o en revertir algo que no consideré (al menos en ese momento) una mejora. Tengo la sensación de que en realidad no has leído ni entendido WP:BEANS . En resumen, significa que no le des a la gente ideas sobre cómo hacer tonterías con cosas con las que no necesitan estar haciendo tonterías. No tiene nada que ver literalmente con narices y frijoles; es una metáfora. (Y no se trataba de ti). Mi punto era que, desde mi perspectiva, Trapper ya había respondido a tu consulta, y mi otro punto era que las personas generalmente no necesitan saber sobre el código relacionado con bots, en detalle en la documentación de parámetros para que los editores humanos los usen, o es probable que algunos de ellos lo manipulen de formas inútiles. Aquellos que sí tienen una razón para estar involucrados con él (por ejemplo, operan un bot o están trabajando en la categoría de limpieza poblada por el bot) ya sabrán sobre ese parámetro y lo que está haciendo (o sabrán rápidamente cómo/dónde averiguarlo). Ese fue el razonamiento en ese momento (y no cabe en un resumen de edición). Sin embargo, dado lo que dijiste en WT:CS1 más tarde, ya dije que vi tu punto de vista al respecto y que deberías sentirte libre de deshacer mi reversión [18]. Supongo que no lo viste, pero es un poco raro recibir una nota hostil sobre una reversión antigua de hace unos días. No es como si tuviera algún poder mágico por el cual una reversión mía sea permanente e incuestionable. :-) De todos modos, entiendo tu punto sobre documentar ese parámetro de una manera más general para el editor, ya que después de todo podría haber una razón para que cualquier editor haga algo con él. Simplemente no creo que deba documentarse de manera redundante, cuando está bien vincular a la documentación existente. Sin embargo, ni siquiera eso me parece muy fuerte. — SMcCandlish ☏ ¢ 😼 02:48, 10 de enero de 2024 (UTC) [ responder ]
Alternativa a rp
Hola. En tu archivo Page-ception tienes dos párrafos que describen el uso de ref= como alternativa a Template:rp . ¿Sigue vigente? ¿Existe alguna posibilidad de que haya una descripción independiente que pueda indicarles a los demás?
(Utilizo rp principalmente porque es mucho más corto. ref= tiene el mismo problema que sfn, puntos de falla adicionales. En <ref name=McNuttsIR2006/>{{rp|131}}</ref>vs <ref>[[#McNuttsIR2006|McNuts, I. R. (2006)]], p. 131.</ref>, la cadena " McNuts, I. R. (2006)]], p." no se verifica por falla de referencia). Johnjbarton ( discusión ) 19:31, 12 de enero de 2024 (UTC) [ responder ]
@ Johnjbarton : No pude analizar lo que quisiste decir con "no se verifica por error de referencia" y esa cadena entre comillas. No he convertido el material del hilo "Page-ception" en una página propia, y me estoy inclinando cada vez más por (que no necesita un ), junto con el uso poco frecuente de inside para casos que requieren anotaciones adicionales. Las cosas complicadas y que hice en Tartan y algunos otros artículos se pueden reemplazar por esas dos plantillas para obtener un resultado más simple y menos propenso a errores.{{sfnp}}<ref>...</ref>{{harvp}}<ref>...</ref>|ref=Whatever 2023<ref name="Whatever2023">[[#Whatever 2023|Whatever (2023)]] ...</ref>
¿Tienes algún problema con algún caso? Quizás pueda ayudarte a solucionarlo.
El problema (o un problema) es que es una forma de referencia entre paréntesis en línea, que fue desaprobada por consenso de la comunidad por completo en 2022. Separa parte de los datos de la cita de la cita y obstruye el texto. — SMcCandlish ☏ ¢ 😼 19:50, 12 de enero de 2024 (UTC) [ responder ]{{rp}}
Contexto: en Electromagnetic field , nos encontramos con una situación en la que hay un par de libros de texto estándar que se citan repetidamente, cada cita apunta a un rango de páginas diferente y luego un montón de citas únicas para puntos específicos. Una forma sería usar un montón de etiquetas {{ rp }} . Otra sería tener una lista separada de plantillas {{ cite book }} para los libros de texto y luego apuntar a los rangos de páginas específicos con {{ sfn }} s. XOR'easter ( discusión ) 21:21 12 ene 2024 (UTC) [ responder ]
@ XOR'easter y Johnjbarton : Oh, esa es pan comido: [19] (junto con alguna otra limpieza). Hice eso mientras mantenía un debate en WP:VPPOL en la otra ventana. :-) Esta no necesitó ningún |ref=retoque. Si no se adapta a sus necesidades, siéntase libre de deshacerla, por supuesto ( WP:CITEVAR y todos los 'at). Algunas personas prefieren que las fuentes citadas en múltiples ocasiones estén bajo su propio subtítulo después de ==References==, como ===Sources===o ===Bibliography===, en lugar de entre y (o incluso ambos a la vez). — SMcCandlish ☏ ¢ 😼 22:35, 12 de enero de 2024 (UTC) [ responder ]{{refbegin}}{{refend}}
Gracias por la solución (al menos @ XOR'easter estará más contento ;-)
No puedo entender la multicitación en una sección separada. Cambie la cantidad de citas y modifique las secciones. No, gracias. Johnjbarton ( discusión ) 02:05 13 ene 2024 (UTC) [ responder ]
Si llega el momento, simplemente vuelve al formato anterior o elige uno nuevo; no estaba tratando de "imponer mi voluntad" con ese cambio; era básicamente una demostración, y esperaba que se revirtiera. — SMcCandlish ☏ ¢ 😼 03:04, 14 de enero de 2024 (UTC) [ responder ]
PS: Otro enfoque es WP:LDR , en el que las fuentes citadas en múltiples ocasiones se colocarían dentro de una <references>...</references>estructura o una etiqueta extendida, directamente debajo de , cada una envuelta en , pero esto me parece innecesariamente complicado. — SMcCandlish ☏ ¢ 😼 22:37, 12 de enero de 2024 (UTC) [ responder ]{{reflist|...}}==References==<ref>...</ref>
No quiero volver a litigar la decisión, pero para mí el problema exacto con sfn es que separa los datos de cita (en Referencias) de la cita (en Fuentes). O en el caso de Campo electromagnético , "Referencia" contiene algunos enlaces azules que apuntan a citas con otro formato y algunos enlaces azules que apuntan fuera del artículo. Parece descuidado.
Ahora que sé que sfnpse puede mezclar, <ref>lo probaré. Johnjbarton ( discusión ) 02:04 13 ene 2024 (UTC) [ responder ]
Bueno, al menos todos los datos de citas están en la sección "Referencias"; esto es claramente una mejora (menos descuidado que) tener parte de ellos allí y parte atascados en mitad de una oración en el artículo (donde para algunos lectores probablemente ni siquiera esté claro qué es ). En cualquier caso, no es posible tener toda la información de citas en la misma línea , en algún lugar de la página, sin duplicar por completo cada una o lo que sea para cada página en la que se cita. Esto realmente es lo mejor que se puede conseguir. Todo el sitio parece estar moviéndose en esta dirección. PD: Usé en lugar de porque produce la misma salida de fecha "(2018)" que las plantillas de citas principales; produce "2018" sin los paréntesis/corchetes redondos consistentes, sin ninguna buena razón. La gente solo lo usa porque tiene un nombre más corto y piensan que es "el predeterminado" o lo que es "normal", pero realmente no debería usarse a menos que el artículo tenga un estilo de cita que use consistentemente el formato "2018", lo que solo es posible si todas son citas formateadas manualmente y sin plantilla, lo que prácticamente ya no se hace en ningún artículo del sistema, excepto en basura vieja que nadie ha tocado desde la década de 2000. — SMcCandlish ☏ ¢ 😼 02:12, 13 de enero de 2024 (UTC) [ responder ]{{cite journal}}{{sfnp}}{{sfn}}{{sfn}}{{sfn}}
¿Existe alguna documentación aparte de Template:Sfnp ? Estoy seguro de que te resultará completamente obvio, pero no entiendo cómo utilizarlo.
Hay una cantidad indefinida de parámetros (¿cuántos apellidos de autores hay?) con definiciones ambiguas (2002abcde?) ("de Broglie" vs "DeBroglie", etc.). Según tengo entendido, estos parámetros tienen que coincidir con una {{cite}}plantilla, ¿correcto? Todos los parámetros last1...yearson esencialmente un identificador obligado a coincidir con una función de la plantilla de cita, hasta donde sé.
(Nada de esto es un problema refporque lo nameúnico que se necesita es que coincidan, los autores y la fecha solo se dan en un lugar. Me parece que una solución en la que el punto de entrada de la cita sea una cadena arbitraria y un número de página como rppero que se muestre como lo desea el consenso sería mejor). Johnjbarton ( discusión ) 16:47, 13 de enero de 2024 (UTC) [ responder ]
Para otros y como referencia futura: la información sobre cómo utilizarla {{sfnp}}se encuentra en Template:Sfnp , en las secciones "Posibles problemas" e "Implementación". Johnjbarton ( discusión ) 22:16 13 ene 2024 (UTC) [ responder ]
@ Johnjbarton : 'Hasta donde sé, todas las plantillas relacionadas comparten la misma documentación y, como has visto, contiene información para la resolución de problemas. Pero tal vez alguien debería escribir un instructivo sobre su uso (¿otra cosa para mi lista de tareas pendientes?). Algunos puntos de uso basados en lo que ya sabía y algo de sandbox que acabo de hacer; supongo que este es el comienzo del instructivo:
Un ejemplo "máximo" completo sería algo como: .{{sfnp|Chen|Jones|López-Garcia|Le Fevre|2021|p=99|loc=footnote 7}}
El |loc=parámetro es opcional y también se puede utilizar en lugar de junto con |p=o su forma plural |pp=(estos dos son mutuamente excluyentes entre sí):{{sfnp|Chen|Jones|López-Garcia|Le Fevre|2021|loc=errata sheet}}
Los apellidos de los autores deben coincidir con los que figuran (en orden numérico) en la plantilla CS1{{Cite journal |last1=Chen |first1=Amy B. |last2=Jones |first2=C. D. |last3=López-Garcia |first3=Carlos |last4=Le Fevre |first4=Jean-Paul |last5= ... |date=2021 ...}} , por ejemplo: para que coincida con el ejemplo anterior.
La ortografía debe ser la misma ("De Broglie" y "DeBroglie" y "de Broglie" no son equivalentes).
La coincidencia de apellidos también funciona con la plantilla equivalente genérica CS2{{Citation |last1=Chen |first1=Amy B. |last2=Jones |first2=C. D. |last3=López-Garcia |first3=Carlos |last4=Le Fevre |first4=Jean-Paul |last5= ... |date=2021 ...}} . Si esto se encuentra en cualquier artículo dominado por las plantillas CS1 más específicas, se debe reemplazar con la apropiada de ellas, según WP:CITESTYLE (y en este punto, la gran mayoría de los usos de CS2 son inyecciones inconsistentes de este tipo en artículos CS1; la cantidad de artículos con plantillas CS2 consistentes está disminuyendo todo el tiempo).{{Citation}}
Sorprendentemente, también funciona extrayendo apellidos individuales del |vauthors=desorden con pérdidas y "detestable para el lector", siempre que esté codificado en el formato adecuado: {{Cite journal |vauthors=Chen AB, Jones CD, López-Garcia C, Le Fevre J-P, ... |date=2021 ...}} este formato también debería reemplazarse a primera vista con el estándar de CS1 |last1=, etc., si |vauthors=se encuentra en un artículo que no usa citas de estilo Vancouver de manera consistente , que es casi todos los casos en este momento. (Quedan pocos artículos que usan Vancouver de manera consistente, pero los editores que son fanáticos de ese estilo comúnmente lo inyectan por error en artículos que no lo usan, lo que va en contra de WP:CITESTYLE ).
También es lo suficientemente inteligente como para tratar |editor1-last=, etc. como nombres de autores para este propósito si no hay |last1=, etc. Si hay uno o más autores especificados, entonces se ignoran los nombres de los editores (no se concatenan en la lista de autores).
|last=, |author=, y |author1=(y los raros |author-last=, |author1-last=, y |author-last1=) son todos alias de |last1=, y así sucesivamente. |editor-last=, |editor=, |editor-last1=, |editor1=son todos alias de |editor1-last=, y así sucesivamente.
Para varios autores, el máximo es 4, no "un número indefinido". Si ingresa 5 o más, la plantilla mostrará un mensaje de error rojo. (Esto se aplica a , y todas sus variantes).{{sfnp}}{{harvp}}
Se deben incluir todos los autores hasta 4 si se especifica en la cita completa. En el ejemplo anterior, no funcionará porque falta el elemento.{{sfnp|Chen|Jones|López-Garcia|2021|p=32}}|Le Fevre
No se detecta ni se admite el parámetro especial CS1/CS2 |display-authors=etal, que indica "et al." después del último nombre de autor especificado. Si la cita es {{cite book |last=Adebayo |first=Mohamed |display-authors=etal |date=1997 ...}}, se debe citar de forma abreviada como .{{sfnp|Adebayo|1991|p=23}}
Si se trata de dos publicaciones del mismo año del mismo autor(es) [o, técnicamente, autores con el mismo nombre y apellido]: aquí es donde |ref=entra en juego. Si tiene {{cite book |last=Tāwhiri |first=Koa |date=2023 ...}}y {{cite journal |last=Tāwhiri |first=Moana |date=2023 ...}}, la solución es la siguiente: {{cite book |last=Tāwhiri |first=Koa |date=2023 ... |ref={{sfnref|Tāwhiri|2023a}} }}y {{cite journal |last=Tāwhiri |first=Moana |date=2023 ... |ref={{sfnref|Tāwhiri|2023b}} }}, cada uno citado brevemente como {{sfnp|Tāwhiri|2023a}}y {{snfp|Tāwhiri|2023b|p=42}}, respectivamente.
Una alternativa cuando hay dos autores con el mismo apellido es ser más específico acerca de los nombres de los autores: {{cite book |last=Tāwhiri |first=Koa |date=2023 ... |ref={{sfnref|Tāwhiri, K.|2023}} }}y {{cite journal |last=Tāwhiri |first=Moana |date=2023 ... |ref={{sfnref|Tāwhiri, M.|2023}} }}, cada uno citado brevemente como {{sfnp|Tāwhiri, K.|2023}}y {{snfp|Tāwhiri, M.|2023|p=42}}, respectivamente. Hacer ambas formas de desambiguación a la vez no es útil. La desambiguación del nombre suele ser útil siempre que haya dos autores con el mismo apellido en el mismo artículo, incluso si los años de publicación no coinciden.
La práctica recomendada anteriormente era " sobrecargar con el operador " el parámetro de la cita de formato largo |year=: {{cite book |last=Tāwhiri |first=Koa |year=2023a ...}}, lo que funcionaría con , pero contamina la salida de fecha de la cita de formato largo con una cadena de año no válida:{{sfnref|Tāwhiri|2023a}}Tawhiri, Koa (2022a)El truco para repararlo era hacer: {{cite book |last=Tāwhiri |first=Koa |year=2023a |date=2023...}}. Pero todo esto es simplemente una atrocidad ridícula, un caso de la cola que mueve al perro, el código que obliga a los editores humanos a hacer tonterías confusas que abusan y hacen malabarismos con los parámetros de plantilla para fines secundarios que no coinciden con su intención de información de cita. Peor aún, los editores no expertos tienden a pensar que |year=2023a|date=2023es un error tipográfico y lo "arreglan" a solo |date=2023, rompiendo así las citas cortas a esa fuente. El |ref=parámetro se introdujo para hacer innecesarios esos saltos de aro que se rompen fácilmente. Las instancias de |, con o sin la compensación |date=2023deben reemplazarse con |date=2023y an (también llamado a menudo por el alias ) dentro de un . NB: Usar en lugar de es universalmente mejor, porque también maneja años desnudos junto con fechas más completas, y los editores que encuentran un pero ven una fecha completa en el trabajo citado al verificarlo tienden a mejorar la cita dando la fecha completa; es simplemente obsoleto.{{sfnref}}{{harvid}}{{ref}}|date=|year=|date=|year=2023|year=
Cómo lidiar con nombres de autor excesivamente largos (generalmente de organizaciones): otra tarea para . Si tiene , puede agregar , y citarlo como, por ejemplo, .|ref={{sfnref|...}}{{cite report |editor1-last=Yi |editor1-first=Xiu-Yīng |editor2=Committee on Reptile and Amphbian Nomenclature |date=2023 |publisher=World Herptological Society ...}}|ref={{sfnref|Yi|CRAN|2015}}{{sfnp|Yi|CRAN|2015}}
Las plantillas de citas de estilo Vancouver ( , , , etc.), que son poco comunes pero que aún se encuentran ocasionalmente, no se pueden usar en absoluto con , etc., sin agregarles algo . Otra razón más para no usar ese estilo de cita.{{Vcite journal}}{{Vcite journal}}{{Vcite book}}{{sfnp}}|ref={{sfnref|...}}
Los nombres de los autores utilizados por las plantillas relacionadas no tienen nada que ver con lo que se incluye en , solo con los apellidos especificados dentro de la plantilla de cita. Si tiene , se citará de forma breve como .{{sfnp}}<ref name="..."><ref name="DeBroglieMacDuff2019">{{cite web |last1=De Broglie |first1=Matt |last2=MacDuff Samuelson |first2=Jennifer B. |date=2019 ...}}{{sfnp|De Broglie|MacDuff Samuelson|2019}}
Es útil para la cordura de todos hacerlos coherentes y claros, por ejemplo, use <ref name="DeBroglie & MacDuff Samuelson 2019">. Tenga en cuenta que las comillas son obligatorias debido a los espacios y caracteres ASCII no alfanuméricos. La práctica perezosa de hacerlo <ref name=DeBMacDS2019>con nombres de referencia muy simples que no contienen espacios, puntuación u otros caracteres especiales es una idea terrible porque es razonablemente probable que alguien más limpie esas referencias desordenadas más tarde y pueda olvidar las comillas y romper la cita. Incluso hacer <ref name=DeB-MacDS-2019>es técnicamente un marcado inválido, aunque pocos editores se dan cuenta de ello (MW parece manejarlo bien en general, pero esto no se puede garantizar en futuras versiones porque va en contra de los requisitos documentados de <ref>. Cada vez que se encuentra, <ref name=foo>debe convertirse a <ref name="foo">(aunque como parte de una edición más sustancial por WP:COSMETICBOT ).
En cuanto a "una solución donde el punto de entrada de la cita es una cadena arbitraria y un número de página como rppero que se representa como el consenso desea sería mejor", no estoy seguro de que sea técnicamente factible de hacer dentro de esta wiki (pero vea la nota a continuación sobre las características futuras de <ref>). Algo en lo que podría reflexionar. Si fuera factible, creo que simplemente ya habríamos reemplazado la funcionalidad de in situ . En teoría, podría haber alguna manera de hacer algo como , donde la plantilla (en realidad módulo Lua - esto ciertamente tendría que hacerse con un programa Lua complicado, no con código de plantilla normal) coincidiera con un probablemente definido en un bloque WP:LDR en la parte inferior de la página, y luego extrajera los detalles necesarios de la cita de formato largo esencialmente de la misma manera que lo hace, y generara una cita corta similar. Esto sería "frágil" en el sentido de que si alguien cambiara el nombre de 's, se rompería. También tiene el problema de que, como con / , generalmente sería deseable poner la cita de formato completo en la parte inferior de la página. Si hubiera un interés de la comunidad en esto, alguien más tendría que implementarlo, porque yo no puedo escribir código Lua de ninguna manera.{{rp}}Here is some article text.{{magicref|Yamamoto2001|p=27}}{{magicref}}Yamamoto2001<ref name="Yamamoto2001">{{cite book |last=Yamamoto |first=Sumiko |date=2001 ...}}</ref>{{sfnp}}<ref>name{{magicref}}{{snfp}}{{harvp}}
Si esto es realmente solo una cuestión de velocidad/facilidad de entrada, un enfoque provisorio pero básicamente desordenado es simplemente poner la cita completa en el cuerpo del artículo en la primera cita de la fuente. A las plantillas realmente no les importa dónde "viven". Técnicamente no sería inválido hacerlo. Here is some article text.<ref>{{cite book |last=Adebayo |first=Mohamed |display-authors=etal |date=1997 |page=123 ...}}</ref> ... This is more article text much later.{{sfnp|Adebayo|1997|pp=289–290}}Sigue citando fuentes y haciéndolo en línea, solo que no de una manera ideal (porque la cita larga tiene un número de página "fijo" en ella, y se mezclará con el principal <references>o el de salida. Si hicieras esto en un artículo nuevo, probablemente a nadie le importaría, pero si lo hicieras en un artículo con un estilo de cita ya establecido, alguien podría objetarlo como un cambio en el estilo de cita, o al menos cambiarlo para poner la cita larga en la parte inferior y sin un número de página incrustado permanentemente. {{reflist}}
Dos notas más:
Estoy en el proceso de escribir lentamente una {{rp}}guía de reemplazo, con herramientas de script de usuario para hacerlo más fácil (el script requiere un montón de pruebas y ajustes porque analizar XML mezclado con {{...}}marcado usando JavaScript y expresiones regulares es muy difícil, incluso cuando solo se analiza una sola <ref>etiqueta y sus parámetros limitados como name=y group=).
La capacidad de citar directamente diferentes páginas en la misma fuente dentro de la <ref>etiqueta en sí está llegando (supuestamente y muy lentamente). El formato se verá así <ref extends="Miller 2019">Miller (2019), p. 42.</ref>, y una cita tan corta tendrá un ↑ en el que se puede hacer clic que enlaza a la cita completa (con suerte, elegirán otro carácter, ya que en muchos casos la cita completa puede estar debajo de todo el resultado <references>/ , no más arriba dentro de esa sección). Ya está en pruebas beta, y la documentación de vista previa está en mw:Help:Cite#Citing different parts of the same source. Sin embargo, podrían pasar años antes de que obtengamos esta funcionalidad. El desarrollo de MW es lento, y la implementación aquí aún más lenta. ¡Esa característica se documentó por primera vez como en versión beta el 2 de diciembre de 2019 [20]! Por Dios.{{reflist}}
— SMcCandlish ☏ ¢ 😼 23:22, 13 de enero de 2024 (UTC) [ responder ]
¡Vaya, eso es excelente, gracias! Es mucho mejor tener las excepciones como subviñetas sangradas. Deberías publicar esto o editar el documento de plantilla; avísame si quieres recibir comentarios.
Probablemente uso ProveIt para el 90 % de mis referencias (principalmente a través de DOI e ISBN), lo que es una fuerza que me empuja hacia las referencias en línea. Parece que las herramientas para adaptar ProveIt a sfnp incluirían:
ProveIt para continuar insertando en línea
Es posible que solo vea una sección en la ventana de edición, por lo que no puede insertarla en Fuentes/Referencia/Notas
Las plantillas insertadas en línea citepodrían ser movidas por bots a Fuentes/Referencias/Notas.
Después de las ediciones del usuario, como parte de uno de los bots de limpieza de citas.
¿Esto existe?
ProveIt podría ofrecer inserción sfnp a partir de fuentes citadas analizadas del artículo completo como alternativa a la inserción de citas.
Esto reduciría la tarea ardua de hacer coincidir cuatro nombres de autores.
@ Johnjbarton : Acabo de guardar una versión mejorada en User:SMcCandlish/How to use the sfnp family of templates ; mucho más fácil de leer y con algo de información adicional. ProveIt no es algo que yo use; soy un dinosaurio vergonzosamente manual cuando se trata de agregar datos de citas. Simplemente copio y pego nombres y títulos y DOI y demás del material fuente y lo masajeo para convertirlo en una plantilla de cita. Probablemente muy ineficiente. No conozco ninguna tarea de bot que haga el tipo de reordenamiento del que estás hablando. Podría ser factible crear uno, pero posiblemente sea un desafío lograr que lo aprueben, porque es probable que algún payaso del tipo "no te atrevas a tocar citas en mi FA" alegue que de alguna manera viola su " estilo de cita " perfecto y cuidadoso, si no está haciendo las citas completas en la parte inferior de la página. Ver también Wikipedia talk:Citar fuentes#Punto de estilo fino con las subsecciones "Citas" y "Obras citadas" ; Incluso la forma de hacerlo al final de la página varía. Temo que esto sea y siga siendo una tarea de limpieza por artículo y a juicio del editor. En cuanto a "ProveIt podría ofrecer inserción sfnp a partir de fuentes de citas analizadas a partir del artículo completo como alternativa a la inserción de citas", eso suena práctico/factible, pero no sé quién desarrolla eso y cuán activos son o responden a las nuevas solicitudes de funciones. Con respecto a la tarea tediosa de hacer coincidir los nombres de los 4 autores: es un poco complicado la primera vez, pero una vez que tienes uno, se puede copiar y pegar para las citas de otras páginas a la misma fuente; solo cambia el número de página. El uso cuidadoso de expresiones regulares (si eres lo suficientemente geek para ello) en la función de búsqueda avanzada integrada en el editor de escritorio predeterminado o en uno similar que forma parte de wikEd, se puede utilizar para acelerar un montón de cosas al hacer la conversión/limpieza (pero copia y pega el artículo en un editor de texto entre operaciones de expresiones regulares; si te equivocas en una, Ctrl-z (Mac: cmd-z) no funciona). También me resulta extremadamente útil utilizar una utilidad de portapapeles múltiple. A partir de Windows 10 ya la tiene incorporada (usa Cmd-V para ver una lista de pegables recientes). Para Mac, puedo recomendar la utilidad de terceros iClip, aunque hay varios buenos competidores. De todos modos, para dejar de divagar y volver al tema, otra alternativa a la monotonía de hacer coincidir los nombres de los 4 autores es hacer {{cite journal |last=Smith |first=J. |last2=Jones ... |date=2021 ... |ref={{sfnref|Smith et al.|2021}} }}y luego usar {{sfnp|Smith et al.|2021|p=92}}. — SMcCandlish ☏ ¢ 😼 02:51, 14 de enero de 2024 (UTC) [ responder ]
Una petición
Hola. Creo que Dicklyon te respeta mucho y no solo porque apoyas su postura de "mensajes en minúscula". Tal vez, si le "sugirieses" directamente que deje de hacer esos movimientos de página mientras se está tramitando una RFC relacionada, él lo haría. Sé que no es tu responsabilidad hacerlo. Pero podría ayudar a evitar que un editor (no yo) denuncie a Dicklyon a WP:ANI. GoodDay ( discusión ) 21:18, 14 de enero de 2024 (UTC) [ responder ]
No me di cuenta de que era él. Sí, lo haré; probablemente tenga habilitado el correo electrónico y podría ser mejor llamar su atención de esa manera. — SMcCandlish ☏ ¢ 😼 21:43, 14 de enero de 2024 (UTC) [ responder ]
@ Buen día : Listo. - SMcCandlish ☏ ¢ 😼 21:49, 14 de enero de 2024 (UTC) [ respuesta ]
De acuerdo, no haré más movimientos ni ediciones relacionados con el campo de juego hasta que se resuelva la convocatoria. Dicklyon ( discusión ) 00:16 15 ene 2024 (UTC) [ responder ]
Dicklyon , el RfC no tiene nada que ver con los movimientos de página y no se resolverá moviendo nada, eso lo debe decidir un RM. Te sorprenderá que estoy de acuerdo con algunas de tus minúsculas de estos temas, y abrir RM en muchos de ellos probablemente te dará los resultados que quieres. Muchos editores piensan que el Draft de la Liga Nacional de Fútbol y otras páginas del Draft de la NFL están separadas de otras páginas del draft como nombres propios, y hará falta otro RM para resolver eso, un RM separado de los demás (así es como Amakuru consiguió que "movimiento por los derechos civiles" se pusiera en minúscula, mezclándolo en un RM con otras páginas del movimiento por los derechos civiles que no tenían nada que ver con el Movimiento por los Derechos Civiles de 1954-1968, por lo que el problema se diluyó, y solicito que tú u otros no intenten esa táctica con el RM del Draft de la NFL, gracias). Randy Kryn ( discusión ) 01:05, 15 de enero de 2024 (UTC) [ responder ]
Sigue repitiendo que "no tiene nada que ver con los movimientos de página", y tal vez alguien se convenza. Pero gracias por admitir que al menos a veces tengo razón. No veo ninguna evidencia de que el draft de la NFL se destaque como más "adecuado" en las fuentes, pero veo que mucha gente lo repite. Dicklyon ( discusión ) 01:08 15 ene 2024 (UTC) [ responder ]
A menudo tienes razón, y sabes que pienso eso, así que no estoy "admitiendo" nada. Pero sí creo que estás dañando el propósito tanto de WP:RM como de la página de la bomba (política) de Village con esta RfC divisiva, propósitos que no se resolverán fácilmente si logras salirte con la tuya al sustituir una página por otra. No sé por qué no puedes tener en cuenta la oposición de la ubicación, simplemente cerrar la RfC, mover la pregunta del Draft de la NFL a un RM en la página del Draft de la NFL y luego enviar un ping a todos los que han comentado en la RfC para que lleven sus comentarios principales y evidencia a esa página. Randy Kryn ( discusión ) 01:14, 15 de enero de 2024 (UTC) [ responder ]
La "oposición de ubicación" es totalmente contraria a las políticas de WP:CONSENSUS y WP:NOT#BUREAUCRACY , y la única razón por la que está sucediendo es que la gente del wikiproyecto de fútbol americano sabe que no puede controlar el resultado de una RfC de VPPOL inundando un proceso (RM) al que casi nadie le presta atención. VPPOL es enorme y es el lugar de mayor consenso en todo el sistema. Que unas pocas personas a las que no les importa el fútbol se estén sumando en un "al diablo con nuestras políticas, siempre del lado de cualquier cosa que le haga daño a Dicklyon y al MoS" es desafortunado pero predecible. Todo el mundo tiene alguna crítica que no le gusta en MoS, y los más irritados de ellos siempre salen de la nada para hacer comentarios del tipo " WP:OWN policy no debería existir, al menos no para mi tema favorito" en cualquier oportunidad que tengan. No significa que no haya consenso sobre ninguno de estos lineamientos o cuestiones de política, solo significa que ciertas personas golpearán a su caballo muerto directamente al centro de la tierra. Debido a que es una cuestión de estilo y la gente está cansada de los tediosos debates de estilo, nunca se tomará ninguna medida para poner fin a sus payasadas, o incluso hacer algo al respecto cuando se involucran en ataques personales directos, como lo hacen contra Dicklyon con mucha frecuencia. Si este fuera cualquier otro tema de cualquier tipo, esta tendenciosidad y esta incivilidad programática organizada que duran años nunca se tolerarían. — SMcCandlish ☏ ¢ 😼 03:35, 15 de enero de 2024 (UTC) [ responder ]
No sé cuánto de esto está destinado a mí, Dicklyon sabe que respeto (la mayor parte) de su trabajo aquí. El punto es que esto agrega otra capa a un movimiento solicitado y su proceso de apelación. WP:RM , luego a WP:MOVEREVIEW , luego a WP:Village pump (policy) . Este importante cambio hace que Village pump (policy) sea la Corte Suprema de Wiki para los movimientos solicitados, y si eso es lo que usted y Dicklyon pretenden hacer, creo que es justo expresar oposición sin ser criticado indebidamente. Randy Kryn ( discusión ) 12:43, 15 de enero de 2024 (UTC) [ responder ]
No hay ningún tipo de "cambio" aquí. No sólo está perfectamente bien buscar aportes adicionales de la comunidad cuando el consenso sobre una cuestión de P&G es [supuestamente] incierto, sino que es una muy buena idea . Es por eso que existe WP:VPPOL . Es por eso que existe WP:CENT . Es por eso que tenemos cosas como WP:NPOVN , WP:RSN y otros tablones de anuncios (aparte de las fábricas de dramas de "castigar a alguien" como ANI y AE), e incluso una tradición de abrir "WP:Solicitudes de comentarios/ tema " independientes cuando pensamos que van a durar mucho. Si hubiera algún mérito en su fantasía de que una RfC es inválida cada vez que algún otro proceso de nivel inferior también pertenece a ese tipo de disputa, entonces ninguno de estos lugares existiría o podría existir. Por lo tanto, cíteme la política que hace que la RM sea obligatoria. Cíteme la política que prohíbe una discusión más amplia de VPPOL sobre cualquier tipo de asunto en particular, especialmente los títulos en particular. Cítame la política que dice que hay una excepción WP:CONLEVEL y WP:NOTBURO cuando se trata de títulos de artículos.
VPPOL siempre ha sido el lugar donde "una vez que se decide aquí, ya no hay más preguntas que seguir haciendo" (a menos que algo cambie más tarde y WP:CCC pueda aplicarse, por lo que la pregunta debería hacerse nuevamente). No tenemos un lugar de aportes más amplio para evaluar el consenso de la comunidad. El propósito de esto es obtener la mayor cantidad posible de aportes sobre una cuestión de interpretación, aplicación o cambio de P&G, especialmente cuando puede afectar a una cantidad sustancial de artículos y/o la cuestión está sumida en un tira y afloja entre dos puntos de vista opuestos sin el aporte suficiente de wikipedistas de posición intermedia que no sean partidarios de la disputa. Es completamente rutinario usar RfC u otros procesos para llegar a decisiones que de otra manera podrían manejarse en RM, si RM no es un buen proceso para ello en ese caso particular. (Solo uno de los numerosos ejemplos: las plantillas a menudo se renombran a través de TfD de múltiples plantillas en las que se deben eliminar varias plantillas, fusionar algunas y renombrar una o más. Vea también otros ejemplos ya publicados en la discusión de VPPOL. Hay muchos más). Su noción de que la única forma posible de llegar a decisiones sobre títulos de artículos es a través de un RM es simplemente patentemente falsa. — SMcCandlish ☏ ¢ 😼 13:41, 15 de enero de 2024 (UTC) [ responder ]
Para que quede claro, ¿estás de acuerdo con que cualquier decisión de "no consenso" aprobada en WP:MOVEREVIEW se lleve a la estación de servicio Village (política), incluso muchos meses después del cierre? Randy Kryn ( discusión ) 14:19, 15 de enero de 2024 (UTC) [ responder ]
Siempre que no hay "consenso" sobre algo ( y es algo sobre lo que la gente va a seguir peleándose), en algún momento se debe llegar a un consenso al respecto. Hay muchas maneras de hacerlo, incluyendo esperar un buen rato y volver a hacer la misma pregunta (por ejemplo, repetir la regla de base en este tipo de caso); esperar o no esperar un rato pero hacer una pregunta diferente (por ejemplo, proponer un cambio a un nombre diferente de uno de los que no se pudo llegar a un consenso); abrir una RfC independiente sobre el tema (generalmente solo se trata de una pregunta amplia, como una franja de artículos, y en la que hay algún tipo de disputa fundamental como "la regla no se aplica a este tema" o "este es/no es un nombre propio", no solo una disputa rutinaria de "mis fuentes dicen esto" versus "mis otras fuentes dicen aquello" sobre algún artículo específico); abrir una RfC de ese tipo en una página de discusión de pautas; abrir una RfC de ese tipo en un tablón de anuncios que sea pertinente; o, si se trata de un asunto de P&G, abrir una solicitud de comentarios en VPPOL. No sería adecuado recurrir a VPPOL si no se tratara de un asunto de P&G, pero en este caso lo es.
En realidad, sería preferible hacerlo "muchos meses después del cierre" , por la misma razón por la que desaconsejamos enfáticamente reabrir el mismo RM poco después de que se cerró sin consenso, o reabrir el mismo RfC poco después de que no se llegó a un consenso. Nadie [o nadie que debería ver cumplido su deseo de campo de batalla] quiere continuar la misma discusión improductiva que fracasó recientemente. Lo que sí queremos ver es o bien una discusión diferente y refinada que pueda superar el obstáculo original, o bien mucho más tarde volver a plantear la misma pregunta para ver si se puede llegar a un consenso entre un grupo diferente de editores actualmente activos. O, en ese sentido, plantear la pregunta variante pero más tarde en lugar de pronto. No hay burocracia que seguir aquí.
PD: La razón por la que existe MRV es porque es una (no la única) forma posible de cuestionar el resultado de un cierre, al solicitar su revisión por parte de administradores no involucrados (y hacerlo en WP:AN es todavía la forma habitual de hacerlo; los relacionados con RM eran tan frecuentes que el proceso se trasladó a su propio tablón de anuncios como lo fue WP:DRV ). Su existencia no significa que la comunidad en un ámbito aún más amplio tenga prohibido de alguna manera examinar la cuestión, por ejemplo, en VPPOL. Simplemente piense en las implicaciones de esa idea por un momento. Mencione cualquier otra toma de decisiones de cualquier tipo en la que los administradores puedan tomar su propia decisión de "microconsenso" y la comunidad no pueda discutirla, y mucho menos anularla o pasarla por alto. (Le ahorraré el problema: no existe, ni siquiera para cuestiones de gran importancia como decisiones de bloqueo indefinido. ¡Diablos! Incluso WP:ARBPOL está sujeto a la revisión y modificación por consenso de la comunidad). También es importante que MRV exista para un único propósito: determinar si el que cerró el debate se equivocó al resumir el debate de RM (en este caso, una decisión de "no consenso"). No es expresamente para reexaminar ninguna justificación (o agregar más) para determinar si las páginas deberían moverse y a qué nombres. Pero la discusión de VPPOL trata exactamente de eso (es un "mega-RM" en un ámbito más amplio del que RM hace posible), en función de los argumentos y fuentes de P&G que se apliquen.
PPS: Otro ejemplo más de cómo se utilizan otros procesos además de RM para llegar a los títulos de los artículos: si una RfC sobre un cambio de regla o una nueva regla llega a un consenso claro, entonces las páginas simplemente se mueven manualmente (o se RM/TRed si están bloqueadas por una redirección editada) para cumplir con ella. Así es como se limpió el lío de la sobrecapitalización de las especies. No se requirió de RM adicionales en absoluto (aunque en teoría podría haber surgido alguno si se hubiera disputado algún caso particular). Es especialmente interesante que: a) la decisión de minúsculas fue tomada por RM en primer lugar, b) MRV la confirmó como un cierre no defectuoso, y c) la comunidad reexaminó la pregunta a través de RfC (basándose en la afirmación de los fanáticos de las mayúsculas de que RM y MRV tenían un nivel de consenso insuficiente). Es un caso exactamente paralelo, salvo que se trata de revocar un consenso que no gusta en lugar de tratar de resolver un fracaso en llegar a un consenso. Estuviste presente durante todo eso, pero no planteaste ninguna de esas falsas afirmaciones de "jurisdicción equivocada" o "proceso equivocado". Es obvio por qué: porque quienes intentan usar la RfC para revocar una decisión de RM estaban tratando de obtener una excepción de MoS (y AT y NCCAPS), y tú apoyas constantemente la "rebelión" temática, ignorando todas las políticas y otras consideraciones para defender la causa de la defensa especial de excepciones específicas para cada tema y wikiproyecto, incluso cuando es demostrable que no se pueden justificar por el uso en fuentes independientes del tema. — SMcCandlish ☏ ¢ 😼 16:06, 15 de enero de 2024 (UTC) [ responder ]
Un buen ensayo/resumen (¿por qué no haces más ensayos? Muchos de ellos se pueden copiar y pegar con un poco de edición). Te estaba yendo bien en el frente personal hasta el final. No sabía nada sobre la RfC de especies y no sé qué camino habría tomado. Cuando estoy de acuerdo con una minúscula (puede que te hayas dado cuenta o no), probablemente no comente ni esté en desacuerdo. Randy Kryn ( discusión ) 16:26 15 ene 2024 (UTC) [ responder ]
Aquí pensé que ya había publicado más ensayos de los que debería. No estoy tratando de que esto sea "todo sobre ti". Pero si tu última oración significa que, debido a que te sientes presionado por mí, ahora te negarás a apoyar las medidas de quejas de MoS/NC/AT con las que estés de acuerdo y solo te opondrás a las que no, no puedo ver que eso sea constructivo y solo aumentaría la percepción de "siempre defender el desafío de MoS". Pero tal vez quisiste decir algo completamente diferente. Sí, he notado que a veces estás de acuerdo con el uso de minúsculas; no creo que nadie haya sugerido que quieras poner todo en mayúscula, solo que tienes un historial de apoyar el uso de mayúsculas cuando lo desean (incluso en ausencia de uso de fuentes independientes) las personas centradas en un tema en particular (y, en relación con esto, de hacer o apoyar afirmaciones de que algo "es un nombre propio" cuando no hay suficientes fuentes para llegar a esa conclusión). — SMcCandlish ☏ ¢ 😼 17:51, 15 de enero de 2024 (UTC) [ responder ]
No, no me arrepiento de editar. Parece una forma extraña de abordar Wikipedia. Quise decir que si veo una solicitud de traslado de minúsculas con la que estoy de acuerdo, la mayoría de las veces otros ya han intervenido lo suficiente como para aprobar esa solicitud, así que sigo adelante. Solo hay una cierta cantidad de horas en una hora. Randy Kryn ( discusión ) 00:00, 16 de enero de 2024 (UTC) [ responder ]
Te entiendo. A mí me pasa lo mismo. Mi tiempo de RM ha ido disminuyendo, especialmente a medida que me encargo de cosas más importantes. Ya tengo demasiados asuntos pendientes. — SMcCandlish ☏ ¢ 😼 02:11, 16 de enero de 2024 (UTC) [ responder ]
"considerado/considerado como uno de los más grandes/mejores"
Hola, gracias por tus contribuciones en la discusión sobre "considerado como uno de los mejores de todos los tiempos" en WT:MOS#MOS:PUFFERY . ¿Cómo se determina el consenso en esa página, ya que no parece haber habido actividad durante más de 10 días? RevertBob ( discusión ) 20:05 15 ene 2024 (UTC) [ responder ]
@ RevertBob : No creo que haya surgido un consenso claro de eso en absoluto, y tendría mucho que ver con el lugar, porque no es realmente un asunto de MoS excepto de una manera muy superficial, sino principalmente una mezcla de preocupaciones de WP:OR y WP:NPOV , con un poco de WP:V incluido. Creo que esto tendrá que ser un RfC cuidadosamente estructurado, probablemente en WP:VPPOL . Se plantearon una serie de cuestiones, y un punto sorprendente fue que algunos editores piensan que es mejor (cuando hay fuentes para respaldar) afirmar directamente "es/fue uno de los mejores lo que sea " que cubrirse con "se considera uno de los mejores lo que sea ", y eso no es lo que esperaba. Todos los argumentos presentados hasta ahora deben tenerse en cuenta al redactar un RfC sobre esto. — SMcCandlish ☏ ¢ 😼 01:17, 16 de enero de 2024 (UTC) [ responder ]
Resultados escolares
Hola, tengo una solicitud extraña que básicamente implica pedir más contexto sobre un comentario que escribiste en esta convocatoria de propuestas de 2017. La razón por la que te pregunto en particular es porque, hasta donde sé, eres el único que mencionó a los distritos escolares en esa discusión y que sigue siendo un editor activo aquí.
Entonces, la historia comienza cuando me topo con un artículo sobre un distrito escolar que probablemente no cumpliría con GNG y busqué en Wikipedia:Artículos para eliminar/Resultados comunes#Educación . Allí dice: "Los lugares poblados y legalmente reconocidos" incluyen distritos escolares, lo que transmite una notabilidad casi presunta a los distritos escolares según Wikipedia:Notabilidad (geografía). No tengo idea de cuál es el origen de este consenso (o si alguna vez hubo uno). De todos modos, noté que esto entraba en conflicto con lo que realmente se afirma en WP:GEOLAND . Entonces, intenté crear una RfC hace unos meses. Puedes leerla en Wikipedia:Bomba de pueblo (política)/Archivo 188#Distritos escolares y GEOLAND . Un montón de personas pensaron que mi RfC no era clara o no estaban seguros de si había algo que estaba tratando de cambiar del status quo... y realmente me gustaría no andar en círculos tratando de entender qué sucedió. Hasta donde sé, esta es la única convocatoria de propuestas que realmente ha tenido algo que ver específicamente con los distritos escolares. Por eso, agradecería mucho que me demostraran que estoy equivocado. No estoy tratando de cambiar lo que sucedió, solo quiero entender por qué esto ha sido una fuente de tanta confusión. Clovermoss 🍀 (discusión) 21:30 15 ene 2024 (UTC) [ responder ]
Este último (en WP:GEOLAND específicamente): los lugares poblados y legalmente reconocidos generalmente se presumen notables, incluso si su población es muy baja. Incluso los lugares abandonados pueden ser notables, porque la notabilidad abarca toda su historia . Los distritos censales , Abadi y otras áreas que no se reconocen comúnmente como un lugar (como el área en un distrito de irrigación) no se presumen notables. Más abajo, WP:NGEO establece: Las características geográficas deben ser notables por sus propios méritos. No pueden heredar la notabilidad de organizaciones , personas o eventos . Los distritos escolares están "legalmente reconocidos", siendo jurisdicciones/organismos gubernamentales formalmente establecidos para un propósito específico. Pero personalmente no estoy seguro de que realmente constituyan "lugares" en el sentido que se entiende aquí, especialmente dada la advertencia sobre los "distritos censales" que sigue; un distrito escolar se parece mucho, mucho más a un distrito censal que a un pueblo o incluso a un vecindario con nombre. Yo creo que los distritos escolares deberían ser abordados como organizaciones (organismos gubernamentales, específicamente), y por lo tanto sujetos a WP:NORG (de hecho, WP:SCHOOLOUTCOMES dice específicamente que las pautas de notabilidad actuales para escuelas y otras instituciones educativas son [ WP:N y WP:NORG] . Los distritos escolares son "instituciones educativas" (fueron instituidos legalmente y pertenecen completamente a la educación). WP:NORG también cubre explícitamente a las escuelas, y también cubre las divisiones de los gobiernos municipales (como un subconjunto de las divisiones de las organizaciones), y todas las organizaciones en general, aunque no menciona a los distritos escolares en particular. Material pertinente de NORG, por atajo seccional:
WP:ORGSIG : Ninguna empresa u organización se considera inherentemente notable. Ninguna organización está exenta de este requisito, sin importar qué tipo de organización sea , incluidas las escuelas. (Pero vea también WP:SCHOOLOUTCOMES , especialmente para universidades). Si la organización individual no ha recibido ninguna o muy poca atención de fuentes independientes , entonces no es notable simplemente porque otras organizaciones individuales de su tipo son comúnmente notables o simplemente porque existe ... "Notable" no es sinónimo de "fama" o "importancia". No importa cuán "importante" los editores puedan creer personalmente que es una organización, no debería tener un artículo independiente en Wikipedia a menos que fuentes confiables independientes de la organización le hayan dado una cobertura significativa.
WP:NONPROFIT : Las organizaciones cuyas actividades son de alcance local (por ejemplo, una escuela o un club) pueden considerarse notables si existe evidencia sustancial y verificable de cobertura por parte de fuentes independientes confiables fuera del área local de la organización. Cuando la cobertura es solo de alcance local, considere agregar una sección sobre la organización a un artículo sobre el área local de la organización. Es muy difícil interpretar que esto no se aplica también a los distritos escolares, especialmente porque la recomendación es fusionar las escuelas NN en artículos sobre el área local (ciudad, etc.) en lugar de sobre el distrito escolar, aunque yo haría esto último si el distrito fuera notable, por ser un objetivo más pertinente y específico.
Misma sección: Unidades locales de organizaciones más grandes: En algunos casos, un capítulo o suborganización local específico que no se considera lo suficientemente notable para su propio artículo puede ser lo suficientemente significativo como para mencionarlo en el contexto de un artículo sobre la organización matriz. Si el artículo matriz crece hasta el punto en que es necesario separar la información en un nuevo artículo, recuerde que cuando separa un artículo sobre un capítulo local, el capítulo local en sí debe cumplir con las pautas de notabilidad de Wikipedia , sin hacer referencia a la notabilidad de la organización matriz. Tenga cuidado de no separar una sección que se consideraría no notable por sí sola. Esto se escribió torpemente teniendo en mente a las fraternidades, pero en realidad no se limita a ellas, y no hay ninguna razón por la que esto no se aplique también a los distritos escolares, que son unidades altamente locales de una organización de gobierno de una ciudad más grande.
Misma sección: Procura que el artículo sea bueno, no que haya varios esbozos permanentes : los capítulos, divisiones, departamentos y otras subunidades individuales de organizaciones notables rara vez son lo suficientemente notables como para justificar un artículo independiente. La información sobre los capítulos y las filiales normalmente se debe fusionar en el artículo sobre la organización principal. ... La información sobre los subcapítulos de organizaciones notables se puede incluir en prosa o en una lista breve en el artículo principal sobre la organización. Esto incluye claramente "división, departamentos y otras subunidades", y no es específico de ningún tipo de organización en particular, por lo que incluiría a los gobiernos municipales.
WP:NSCHOOL : Todas las universidades, colegios y escuelas, incluidas las escuelas secundarias, escuelas intermedias, escuelas primarias (elementales) y escuelas que solo brindan apoyo a la educación general deben cumplir con las pautas de notabilidad para organizaciones (es decir, esta página), la pauta de notabilidad general o ambas. Las organizaciones e instituciones educativas con fines de lucro se consideran organizaciones comerciales y deben cumplir con esos criterios. (Véase también WP:SCHOOLOUTCOMES ) Esto solo menciona a las escuelas específicamente, pero el razonamiento en él no es una nueva regla, es una explicación de las reglas existentes y cómo ya se aplican, y ya se aplican también a los distritos escolares.
No tengo idea de cuál es la historia completa de estas páginas, pero WP:SCHOOLOUTCOMES (y todo el resto de WP:OUTCOMES ) es un ensayo que intenta resumir los patrones de resultados y las razones para ellos; es mayormente viejo y en mal estado y en este punto en particular parece ser un razonamiento circular: ha hecho una afirmación que no es defendible, pero la gente lo acepta porque eso es lo que dice, el ensayo es tratado (como WP:BRD y WP:AADD ) casi como si fuera una guía. Tiene razón sobre las escuelas, pero es lo que equivale a un WP:POLICYFORK sobre los distritos, porque cita incorrectamente a WP:GEOLAND como la guía de control cuando necesariamente es WP:NORG, ya que los distritos escolares son definitivamente organizaciones pero rara vez se los concibe como lugares, y solo para fines administrativos cumplen una función jurisdiccional, por lo tanto son exactamente paralelos a los tramos censales que se descartan como "lugares".
En resumen, creo que esto es motivo para otra convocatoria de propuestas, para eliminar la afirmación incorrecta de notabilidad presunta de WP:SCHOOLOUTCOMES y para que los distritos sean tratados exactamente igual que cualquier otra subdivisión local de cualquier organización (en este caso gubernamental). Si se reparara eso, habría que ajustar algún otro consejo, para sugerir la fusión de escuelas no notables con distritos escolares notables o con el artículo de ciudad/pueblo en ausencia de uno de los primeros, porque muchos distritos escolares (probablemente la mayoría de ellos) no son notables y deberían fusionarse con ciudades/pueblos en una subsección bajo gobierno.
La convocatoria anterior parece haber fracasado porque no ofrecía suficiente material contextual. Lo que recomendaría es utilizar el material anterior (neutralizando algunos de mis argumentos editoriales) en un cuadro desplegable como ... (cada una de esas plantillas tiene que estar en su propia línea). Luego, presentar una propuesta de convocatoria similar a la siguiente:{{collapse top|left=y|Pertinent guideline and other material:}}{{collapse bottom}}
El ensayo WP:SCHOOLOUTCOMES afirma que los distritos escolares son presumiblemente notables como "lugares poblados", sobre la base de WP:GEOLAND (en WP:NGEO ). Sin embargo, esa directriz excluye específicamente cosas como los tramos censales que normalmente no se consideran lugares en el sentido habitual, y esto también podría aplicarse a los distritos escolares. Mientras tanto, los distritos escolares son organizaciones (divisiones de gobiernos municipales más grandes), mucho más que lugares, y parecen estar sujetos a la directriz WP:NORG , al igual que las escuelas y los propios gobiernos municipales. (Específicamente, WP:ORGSIG y WP:NONPROFIT en varias partes parecen directamente aplicables a los distritos, junto con la intención detrás de WP:NSCHOOL ). La redacción del ensayo parece ser una WP:POLICYFORK , que necesita una resolución de una forma u otra.
Opciones para abordar el problema:
Opción 1: Los distritos escolares no son presumiblemente notables y están sujetos a WP:NORG . Actualice esa directriz para mencionarlos específicamente y revise WP:SCHOOLOUTCOMES para que esté de acuerdo.
Opción 2: Los distritos escolares son presuntamente notables, están sujetos a WP:GEOLAND y no están sujetos a WP:NORG . Actualice ambas pautas para indicar esto.
Opción 3: Algún otro enfoque (especificar).
[Complete el cuadro de colapso de citas de pautas y ensayos aquí.]
[Luego, cree una subsección "Comentarios (distritos escolares)" y una subsección "Discusión (distritos escolares)", desambiguadas de otras secciones similares en la página VPPOL.]
Como comentario aparte (ya que no es neutral), tal vez como parte de su propio voto, tal vez agregue: "Lo que se mencionó más arriba: no es necesario tener un artículo sobre el distrito escolar para abarcar todas las escuelas en un área determinada: podrían estar incluidas en otro artículo geográfico, como la ciudad o pueblo local ; y además: el sentido común dicta que cuando un distrito escolar que de otra manera no amerita un artículo cubre más o menos la misma área que un pueblo o ciudad, o incluso un condado o municipio, tanto el distrito como sus escuelas deberían estar incluidos en ese artículo " .
Entonces, supongo que eso ya está haciendo la mayor parte del trabajo, aunque no creo que quiera "ejecutarlo" yo mismo. — SMcCandlish ☏ ¢ 😼 01:11, 16 de enero de 2024 (UTC) [ responder ]
Me diste mucho en qué pensar. :) No tengo mucha experiencia con las RfC, así que realmente aprecio tu razonamiento detallado aquí. Lo único que me salta a la vista de inmediato como un posible problema con las opciones es que me preocupa que la opción n.° 3 conduzca a una discusión sobre minucias que harían descarrilar una nueva RfC. Por ejemplo, hubo una buena cantidad de personas en la RfC anterior que se oponían al concepto de que los distritos escolares tuvieran que cumplir con la GNG (¿actuando como si fuera una SNG?) y discusiones sobre las diferencias (si las hubiera) entre las juntas escolares y los distritos escolares. El último argumento podría llevar a un mayor énfasis en GEOLAND si teóricamente hay distritos escolares que no están bajo la jurisdicción de las juntas escolares (que son organizaciones). ¿Crees que debería cambiar las opciones para reflejar estas preocupaciones o crees que estoy pensando demasiado? Clovermoss 🍀 (discusión) 01:59 16 ene 2024 (UTC) [ responder ]
Tendría que consultarlo con la almohada. Los consejos escolares son una especie de organizaciones, pero son cuerpos de funcionarios, no organizaciones enteras en el sentido habitual; son básicamente como una junta directiva, un consejo asesor, etc. Es decir, la distinción entre un distrito escolar y un consejo escolar es ilusoria; algunos distritos son administrados por consejos escolares y otros no (por ejemplo, controlados directamente por el ayuntamiento o por algún otro medio). Pero no he estudiado detenidamente el RfC original, así que tendría que leerlo todo para buscar "trucos" que el borrador anterior no haya tenido en cuenta, y ese podría ser uno de ellos. Aunque también debe ser conciso. PD: una "opción 3: nombra tu veneno" (que a menudo resuelve "no hacer nada") también podría incluirse ya que la gente inventa sus propias opciones de todos modos y puede ser antagónica al respecto si no estaba ya allí. En última instancia, la gente que quiera intentar hilar fino tratará de hacerlo de todos modos. Definitivamente querrán hacerlo en algunos casos, porque si prevaleciera la opción 1, significaría muchos AfD o al menos fusiones apresuradas para evitar AfD. Esta es una convocatoria de propuestas sobre la que esperaría mucho FUD . — SMcCandlish ☏ ¢ 😼 02:10, 16 de enero de 2024 (UTC) [ responder ]
Creo que la idea de ponerle nombre a tu veneno es buena, mi línea de pensamiento era más bien que tal vez habría un veneno recurrente lo suficientemente fuerte como para que valga la pena tener una cuarta opción desde el principio. Voy a dormir sobre todo esto también. Desafortunadamente, trabajo a tiempo completo durante la noche, por lo que la parte real de dormir se retrasará un poco. No necesitas preocuparte por apresurarte a leerlo todo, me alegro de que estés dispuesto a darme tu opinión. Contáctame cuando quieras. Clovermoss 🍀 (discusión) 02:42 16 ene 2024 (UTC) [ responder ]
@ Peter coxhead : No es una pregunta que MoS aborde, ya que la separación de sílabas siempre está cambiando (inclinándose con el tiempo a una menor separación cuanto más familiar se ha vuelto un término, y parece haber diferencias regionales/dialectales en el hábito). Este parece ser casi el mismo argumento que antisemitismo versus antisemitismo , donde las personas a favor de la coherencia y un tipo particular de lógica prefieren el primero, porque semita es un nombre propio, y así es como se escriben habitualmente esas palabras ( antiamericano , paneuropeo , proarmenio , etc.), y otros a favor de la simplicidad y la concisión tipográficas, que es una lógica de otro tipo, quieren lo segundo. En ese sentido, el antisemitismo parece estar dominando en Wikipedia a pesar del hecho de que está cambiando a minúsculas el nombre incrustado semita , lo que en sí mismo parece ser un gesto antisemita de ya no tratar su nombre como propio. Este parece ser el caso simplemente porque la versión en minúsculas, unida, es la ortografía más común en la prensa [21]; Esta es la falacia del estilo común , y WP WP no está escrito en estilo de noticias , que está impulsado obsesivamente por la concisión y la conveniencia. La ortografía antisemitismo claramente domina en los libros [22]. El uso en revistas es muy mixto [23] (la primera página de resultados es principalmente la forma comprimida, pero al revisar las páginas de resultados posteriores se muestra una mezcla de aproximadamente 50:50). El caso subantártico se complica por el hecho de que varias fuentes tienden a tratarlo como un nombre propio con mayúscula ( Sub-Antártico o Subantártico ) de una región de la Tierra, como Hemisferio Occidental y Ártico, etc., por lo que realmente hay cuatro opciones: sub-Antártico , Sub-Antártico , subantártico y Subantártico . Existen otros desacuerdos geográficos como este, por ejemplo, Transcaucasus (también conocido como Transcaucasia , ahora Cáucaso Sur ) también ha sido escrito por fuentes como Trans-Caucausus y Trans-Caucasia (con mayúscula como nombre de lugar; no veo el uso de trans-Caucasia , transcaucasia , etc.). Para su caso, probablemente sea una cuestión de preguntar en una RfC sobre qué ortografía usar en nuestros artículos, o en una RM simplemente mover el artículo y luego imponer la coherencia ortográfica en el texto después. Algunos enlaces: [24][25][26] — SMcCandlish ☏ ¢ 😼 17:33, 18 de enero de 2024 (UTC) [ responder]
WP:CONVENIR
@Thebiguglyalien , Snow Rise y Levivich :
Me había olvidado de ello, pero lo que se discutió con cierta extensión en " Discusión de usuario:Snow Rise/Archivo 22#Consejos para el futuro en los años de WikiProject " no debería olvidarse, y vale la pena desarrollarlo más. Aunque esa discusión fue más inmediatamente sobre WP:YEARS y "sus" artículos, WP:ITN , y algunos otros detalles, lo que Snow Rise dijo allí (en parte parafraseando a Levivich) resuena fuertemente y es ampliamente aplicable: [E]stos son artículos en.Wikipedia al fin y al cabo, y cualquiera sea su formato y consideraciones únicas, se rigen por las mismas políticas de contenido que cualquier otro contenido orientado al usuario.... [L]a razón por la que tenemos un estándar objetivo basado en WEIGHT es para prevenir las percepciones idiosincrásicas de la "importancia" de un tema... para prevenir no sólo sesgo en nuestro contenido, sino también la introducción de discordia insuperable en el proceso de construcción de consenso cuando se utiliza un estándar tan subjetivo [como lo que un wikiproyecto temático podría preferir subjetivamente]. ... [E]ste es principalmente un problema de comportamiento. ... Estoy seguro de que cualquier solución tiene que basarse en nuestros estándares RS /WEIGHT existentes. Es simplemente el único enfoque que se puede adoptar en este proyecto sin que los engranajes se bloqueen constantemente más allá de nuestra capacidad de reparación. [No aplicar P&G en todos los temas de manera uniforme] está desvinculando nuestro proceso de un estándar objetivo e invitando a nuestros editores a hacer lo que actualmente no se les permite hacer: basar el contenido en sus propias evaluaciones de lo que es realmente "importante" ...
Todo esto es central para todo el problema de las "rebeliones temáticas" contra nuestro WP:P&G (que rápidamente se extienden a tirar por la ventana a WP:CIV y WP:NPA ), y algunos otros problemas de jardines amurallados (ITN, DYK, FAC y varios otros me vienen a la mente). Estas observaciones de política se aplican mucho más allá de las políticas de contenido central en sí mismas, incluyendo las pautas sobre títulos, cuestiones de estilo, notabilidad y otras consideraciones, excepto cuando un tema tiene su propia página de convenciones de nombres a nivel de pauta (no el ensayo de WP:PROJPAGE ), página de MoS, pauta de notabilidad de tema o lo que sea (y algunas de ellas necesitan reexaminarse y revisarse; gran parte de su texto data de la década de 2000 y a menudo es problemático, especialmente con respecto a temas que no reciben mucha atención editorial; pero ese será un tema para otra ocasión). El asunto volvió a plantearse recientemente en Wikipedia:Bomba de pueblo (propuestas)#Sanciones generales (Darts) , un caso muy típico en el que un tema de nicho con editores a largo plazo que dicen "este es nuestro tema" choca con otros editores y se convierte en un campo de batalla a largo plazo.
Según recuerdo de la discusión original, la primera idea fue revisar WP:PROJPAGE , pero no se revisa con tanta frecuencia, no es una política y está dirigido solo a la salida de los wikiproyectos, por lo que no aborda la promoción de puntos de vista temáticos y el comportamiento de jardín amurallado por parte de facciones o equipos que no son wikiproyectos, ni individuos con este tipo de inclinación. Entonces, la idea después de eso fue revisar WP:CONLEVEL con un complemento WP:CONVENUE (usurpando el atajo WP:CONVENUE de mi ensayo, que puede ser útil para algunos puntos/redacción, junto con WP:PROJPAGE). Thebiguglyalien redactó algo en un sandbox aquí, y Snow Rise tuvo algunas objeciones al respecto (una de las cuales se mencionó en el hilo vinculado arriba), pero todos se pusieron a trabajar y quedó en el camino. Por mi parte, creo que gran parte de ese borrador es correcto, pero exagera algunas cosas, pasa por alto algunas otras y es aproximadamente diez veces demasiado largo; todo el concepto debe comprimirse en un par de oraciones concisas, un solo párrafo; la comunidad no estaría dispuesta a aceptar una adición de política grande y compleja, según el principio WP:CREEP .
No estoy seguro de cómo proceder, pero creo que esto debería hacerse, incluso si lleva algo de tiempo y trabajo. — SMcCandlish ☏ ¢ 😼 07:31, 19 de enero de 2024 (UTC) [ responder ]
Como dije en la discusión de dardos, creo que esto es algo que debería suceder. Y estoy de acuerdo en que sería ideal si pudiéramos reducir los posibles cambios a un solo párrafo o menos. Y ahora estoy haciendo una insinuación, pero también recuerdo haber sugerido hace un año que las páginas de discusión de WikiProject podrían tener un banner con el siguiente texto: "Esta página sirve como tablón de anuncios para el tema y para la discusión sobre el proyecto en sí. Si quieres discutir cambios en los artículos de este tema, hazlo en sus respectivas páginas de discusión o en WP:Village Pump ". Thebiguglyalien ( discusión ) 17:19 19 ene 2024 (UTC) [ responder ]
Algo así podría ser una buena idea, además de sugerir VP para eso (no es para discutir cambios en artículos específicos). Pero probablemente necesitaríamos ajustar la política primero, para que ese wikiproject-talk-templating fuera según esa política. — SMcCandlish ☏ ¢ 😼 17:38, 19 de enero de 2024 (UTC) [ responder ]
Hola SMc, gracias por el comentario. Mi segunda crítica: dudaría en introducir un nuevo concepto importante (CONVENUE) además del concepto existente (CONLEVEL) a nivel de políticas, porque cuanto menos conceptos haya, más simple conceptualmente será la política y mejor.
También creo que se podría lograr el mismo resultado con solo hacer un cambio en la sección de políticas existente en WP:CONLEVEL . CONLEVEL también es WP:LOCALCONSENSUS , pero la política actual no contiene las frases "consenso local" o "consenso global". Debería.
El segundo párrafo de CONLEVEL debería trasladarse en su totalidad a WP:PGCHANGE , dejando espacio para un nuevo segundo párrafo que explique más explícitamente la idea de los niveles de consenso.
El nuevo párrafo 2 debería explicar la relación entre el "consenso entre un grupo limitado de editores, en un lugar y momento determinados" y la participación, el lugar de celebración y la publicidad (debería explicar la importancia de {RFC} y FRS, CENT y VPP/VPR). Levivich ( discusión ) 06:02 20 ene 2024 (UTC) [ responder ]
Buen comentario. Parece un enfoque razonable, pero me he quedado sin energía para el día. Lo pensaré pronto. — SMcCandlish ☏ ¢ 😼 06:11, 20 de enero de 2024 (UTC) [ responder ]
My concern is that, ultimately, some level of cultural change will have to accompany a policy change. Most editors generally agree that global consensus beats local consensus, but being willing to do something about it is another matter. ANI regularly sees cases where editors are causing disruption but it's overlooked because it's "not that big of a deal" or "this is overblown", and CONLEVEL seems like exactly the sort of issue that would fall into that trap. It's not until we get into a WP:DARTS type situation where several editors without much "social capital" are being incredibly uncivil that it gets any sort of attention. We can get the wording changed, and that's all well and good, but I worry that things would keep on going the way they have been other than having one more all caps link to use. Thebiguglyalien (talk) 00:14, 22 January 2024 (UTC)[reply]
Yes, this bears some thinking on. Getting community culture to shift is always a challenge. — SMcCandlish ☏ ¢ 😼 00:55, 22 January 2024 (UTC)[reply]
To get my brain moving on this, I reread the discussions and wrote up a quick outline of the points that we considered:
no discrete group of editors gets to make and enforce rules outside of established process, and thereby sidestep the normal community vetting of proposed guidelines – Snow Rise's summary of what we want to accomplish
All articles are subject to WP:WEIGHT, WP:POV, and WP:OR regardless of topical considerations. Editors who frequent one topic cannot decide that "their" articles follow separate standards.
Something's importance or significance should be determined by its coverage in sources, not by the evaluation of one or more editors. Editors must not create their own metrics or rules to determine the significance of a topic.
The media and other sources being biased for/against covering certain topics is not a valid argument for giving them more/less weight.
WikiProjects may not dictate content or create any other rules that must be followed. They operate in a purely advisory capacity. There is no such thing as "WikiProject consensus".
Groups of editors, including WikiProjects, are still subject to WP:OWN. WikiProjects and their members do not own any articles or any other pages.
Consensus on one article does not apply to another article. The talk page of one article cannot be used to dictate rules for a series of articles.
Suggested changes to multiple articles should be widely advertised to the entire community, not confined to one WikiProject or group of editors.
The number of editors supporting a local consensus and the length of time it has stood do not give it additional weight.
This is already expected practice and we are simply codifying it. ARBCOM has also made rulings to this effect (I don't know which cases off the top of my head).
Ideally we can weed this down and condense the main ideas into a few sentences that would fit somewhere under WP:DETCON. Also pinging Snow Rise and Levivich. Thebiguglyalien (talk) 05:05, 15 February 2024 (UTC)[reply]
Ehhhhxcellent as Mr. Burns would say. Thanks for the effort to summarize that long thread, and produce a good summary, and I've taken the liberty of numbering the points for easier reference. I can already think of some ways to condense and wordsmith on it a bit (e.g. merge 5 and 6 and the second half of 2), but will hold off and think on it longer. One thing that strikes me is that the first half of 2, and 3 and 4 are really WP:WEIGHT and WP:NOR concerns, and better addressed elsewhere. They're very good nutshell ecapsulation of principles, but not really directly germane to CONLEVEL and "CONVENUE" matters. — SMcCandlish ☏ ¢ 😼 05:25, 15 February 2024 (UTC)[reply]
Hey all, sorry for my being slow to join the discussion. I was vaguely aware of it, but late January and early February were among the most difficult weeks of my entire life, with some very serious emergencies and personal loss, and I just didn't have the bandwidth/ability to so much as pipe up.
That said, and as you know, I feel this is an issue that's time has well come. Moving what is essentially well-established policy regarding the proper methodology for forming multi-article consensus (that was merely codified in a peculiar place because of the idiosyncrasies of how community consensus developed) to a more appropriate namespace would have immense benefit for short-circuiting a lot of needless conflict that otherwise arises due to a lack of understanding of the limitations of WikiProjects (and small cohorts with their own preferred rules generally). Those issues are unambiguously a direct result of the established limitations not being properly elaborated on in the major policies on consensus, leading to these principles being underappreciated--sometimes even by fairly experienced and conscientious community members.
I know that all I'm doing here is stating the obvious and preaching to the choir, but it's my way of saying my silence since TBUA revived this issue is not from lack of support or appreciation. I've reviewed the above summary by TBUA, and find it essentially accurate, and any little caveats that I have about creative ways members of WikiProjects have sought to do their due diligence in terms of advertising discussions to the broader community while still holding the discussions at WikiProjects and attempting to have the results operate as binding consensus on multiple articles, we can discuss as we get along and try to incorporate into the new proposed wording. I personally am somewhat agnostic on the location of the new policy verbiage, but lean a little towards their being their own 'CONVENUE' section within DETCON. But that too we can work out as we go. I'll drop a more substantial bit of feedback on the more particularized points in a few days, as soon as I am able. Thanks for picking up the ball and running with this, TBUA. SnowRise let's rap 22:45, 16 February 2024 (UTC)[reply]
+1, I basically agree with everything Snow said, especially thanks TBUA for advancing this. (Sorry to hear about the loss and rough patch, hope spring will bring you some relief.) Levivich (talk) 19:27, 17 February 2024 (UTC)[reply]
Yep. I think we are onto something. I just noticed User:Scribolt/Levels of consensus which is at least closely adjacent to some of the things we've been (slowly) talking about. Scribolt, care to join in? The summary above is probably good enough to go through (the original discussion was quite long). — SMcCandlish ☏ ¢ 😼 04:35, 23 February 2024 (UTC)[reply]
Thanks for the ping. I think I see things a little differently in some areas, maybe some of these (slightly disjointed) thoughts might help. I should point out that I'm sympathetic to what you're trying to achieve.
Philosophically, I'm not sure that I agree that an editing consensus impacting multiple articles that should be "respected", if not enforced, cannot develop outside of P&G pages or central noticeboards, which is where a lot of the numbered points above seems to imply. For me, the level of consensus something has (no matter what namespace it occurred in) is a product of participation x correct advertisement x correct venue x how well the scope of discussion applies to the new situation. You can overcome a deficit in one element if the others are in place and are high.
This is very much in line with the first part of Levivich's comment earlier in this thread, but for me trying to define local vs global consensus is a bit of a dead end. You're never going to find a definition that everyone will get behind and for me it's much more valuable to make this a relative term (i.e. the consensus for doing X is bigger than doing Y, because we consider A, B & C when thinking about how much consensus something has). You're never going convince many (including me) that there is a genuinely "global" consensus for doing almost anything.
The "respected" if not "enforced" piece is relevant when something is not well covered in existing P&G. Pointing out to an editor that there was a discussion before on the topic at another article or WikiProject is legitimate and the editor can choose whether to go with it or seek a new and greater consensus (and in these cases the new consensus formed, whether at the article itself, central noticeboard, or even by simply making and justifying their edit) would almost certainly be greater than the original.
In terms of mechanics of multi-page consensus, I'm not sure that something like this was such an awful way of working through things, would we really want every discussion like this to occur on a centralized notice board or P&G page? It might be worth distinguishing between discussions with open ended application vs those with a defined scope.
In terms of any language, while I agree that P&G by definition are likely to represent high levels of community consensus, this is clearly more applicable for some pages than others, so please consider the policy principles that define P&G as follow editing best practices and not the other way around.
Not sure if that was in any way helpful, but I'm glad at least someone read my essay. Scribolt (talk) 13:40, 5 March 2024 (UTC)[reply]
It is good food for thought. "would we really want every discussion like this to occur on a centralized notice board or P&G page?" Probably not, and the idea of establishing to a consensus to do/not do something at a particular article is laced throughout our P&G. However, this applies when the question is legitimately open, when an option is available. The problem arises when some topically-focused editors decide to defy a broad consensus (most frequently MOS:CAPS, but any guideline or policy of any kind could be at issue in a particular case) that already covers the question hand, to instead impose a divergent approach in "their" topic, and may become entrenched about it, hostile to anyone who tries to change it to the P&G-compliant form, or even expresses the idea that this should happen. This is a really bad "topical balkanization" habit with a lot of long-term disruption potential. There are numerous examples of this, that range all over the place, from weak sourcing "standards" being applied by camps of editors in various controverial topics that have resulted into ArbCom-imposed regulation; to a particular wikiproject deciding on its own to repurpose a biographical infobox parameter to contain information that doesn't belong there, and imposing this across many thousands of articles, simply because it suits the preferences of a small number of editors devoted to a certain sort of bio article. We need a generalized approach for dealing with such issues. In theory, just WP:CONLEVEL policy should have been enough, but it has proved ineffective at curtailing this sort of thing. — SMcCandlish ☏ ¢ 😼 03:55, 7 March 2024 (UTC)[reply]
Oh, I agree with the sentiment. But when thinking about what to do, I think it's worth remembering that there's Policy, Guidelines and guidelines. Purely looking at this in terms of consensus is probably the wrong approach. The vast majority of actual policy pages are widely watched. Something like MOS:CAPS is also well stewarded, and it's fair to say it's current state has enjoyed enough oversight to mean that doing something differently should really mean updating the guideline or discussing more centrally. How much community consensus would you say MOS:PK actually enjoys? Based in pagewatchers and edits, I'd say you wouldn't need a hugely attended or advertised discussion elsewhere to have difficulty saying that MOS:PK is the consensus between a limited group of editors. Now, you could say that because it has guideline status it automatically applies, but then the argument becomes that if a rule exists, then it's followed until changed, which is a strengthening of the status of guidelines.
A possible approach would be to a) provide some better tools so that someone uninvolved can asses the strength of a consensus, and b) do something in the behavioural and or RFC closing guidance area to embed this Scribolt (talk) 16:59, 7 March 2024 (UTC)[reply]
There's not a MOS:PK; if you mean something like MOS:PAK, yes there are lots of narrowly topical MoS, NC, and N "guidelines" that were simply declared to be guidelines by a handful of authors back in the wild-and-wooly 2000s when people were just inventing "guidelines" and even "policies" out of nowhere. But these generally are not of much if any concern. Most have not been substantively edited in a decade, and either are innocuous (don't conflict with other P&G or do anything else stupid) and are actually followed (in which case they are fine as guidelines); are innocuous but not followed, for being too out-of-date with what the community's actual practice is (in which case they should be marked {{Historical}}, or updated to ecapsulate actual current best practice in the topic); or they are not innocuous and contain conflicts with other P&G, in which case they need to be repaired (whether actively followed or not), and that might entail RfCs and even a new WP:PROPOSAL process (a result of which might be {{Rejected}}). There are also a lot of WP:PROJPAGE essays, in which various wikiproject try to assert style (most often section layout) preferences, but these are mostly ignored. Where they are not and also are not problematic, they should be make into MoS subpages instead of wikiproject style-advice essays.
The vast majority of the "defy a guideline I don't like" disruption is against some particular provision in a central guideline, like MOS:CAPS and its WP:NCCAPS derivative, or sometimes worse, like ignoring aspects of core content policy to push agendas in particular topics (WWII/Nazis/Jews in Eastern Europe; various fringe or religion subjects; a number hot-button topics in Western and especially American politics; etc.). The topical "guidelines" like MOS:PAK and MOS:COMICS and WP:NCPARTY and WP:NEVENTS are rarely the source of the problem.
But, sure, various pages with {{Guideline}} on them probably need community review for updating (and often paring) or even for demotion to essays or {{Historical}}, especially when they represent hardly any input from anyone and/or they are out-of-step with consensus practice. It's not really clear how to go about this the best way. Generally it's likely to be a matter of WP:VPPOL referenda, but is apt to cause significant drama, especially if the "guideline" in question is the product of a wikiproject and they happen to like it. One such demotion was "WP:Manual of Style/Computing", which was principally authored by only two or three editors, and was basically a pile of opinated WP:CREEP that didn't serve an encyclopedia-building need. Contrast with WP:Manual of Style/Computer science which dated to the same era (as a PROJPAGE) and recently passed a PROPOSAL to become part of MoS; that was a page with significantly more community input, by people who knew better what they were talking about, to address actual encyc.-writing needs instead of impose personal-preference style pecadilloes, and subject to considerable revision after community input. Big difference. — SMcCandlish ☏ ¢ 😼 23:52, 7 March 2024 (UTC)[reply]
Regarding your edit here, don't you think "château" is a well assimilated loanword? Jean-de-Nivelle (talk) 13:14, 20 January 2024 (UTC)[reply]
Disney move
Why did you want the Walt Disney Company to move to Disney in the first place? While it is a common name, it is not the only important Disney. You know Walt Disney himself, right? Please read the guidelines, think, and learn from your actions. GabrielPenn4223 (talk) 15:06, 20 January 2024 (UTC)[reply]
@GabrielPenn4223: Read the RM proposal. The company is by far the WP:PRIMARYTOPIC (that is, the vast majority of reliable-source usages of just "Disney" by itself are in reference to the company, not to any other subjects), and it is the WP:COMMONNAME of the company (that is, the vast majority of RS references to the company are simply as "Disney" not as a longer term). This case is not different in any way from any other routine disambiguation case. The fact that Walt Disney himself might be referred to on second mention as simply "Disney" in a biographical context is completely immaterial. Hatnotes exist for a reason, and {{About|the company|the company founder|Walt Disney}} would resolve any navigational issue. There's a weird fandom-driven "local consensus" happening at that page to defy WP:AT policy and the WP:DAB guideline. It's silly (most especially since Disneystill redirects straight to the company despite that recent discussion). This case not any different from Heinz. The company, H. J. Heinz Company, formerly Heinz Noble & Company, now a subsidiary and brand of larger company Kraft Heinz after a 2015 merger, is the PRIMARYTOPIC for that name. The COMMONNAME of the company-cum-brand is simply Heinz, and the founder, Henry J. Heinz is notable and would be referred to on second mention in a biographical context simply as "Heinz". Heinz doesn't even have a disambiguation hatnote pointing to him, though it could have one; it was probably thought unnecessary since he is mentioned and linked in the first line of the article. If you went and proposed moving Heinz to H. J. Heinz Company, Heinz (company), Heinz (brand) or some other name, you'd be WP:SNOW opposed because such a name would not fit WT:AT and WP:DAB requirements (see also Talk:Heinz/Archives/2015#Requested move 26 March 2015). The difference is that Heinz, unlike Disney, doesn't have a walled-garden fanbase who want things a particular way to suit their WP:ILIKEIT preferences instead of following our WP:P&G like every other subject does. Some day the company article will be at Disney where it belongs, though I'll leave it to someone else to get that done. — SMcCandlish ☏ ¢ 😼 16:38, 20 January 2024 (UTC)[reply]
It should not. Disney should be a DAB page in my opinion. GabrielPenn4223 (talk) 16:45, 20 January 2024 (UTC)[reply]
Not according to WP:PRIMARYTOPIC and WP:DAB (and WP:PRIMARYREDIRECT for that matter). We don't just get to make up our own opinions to suit our personal preferences on such matters; they are governed by policies and guidelines (pretty much explicity to prevent particular popular topics being given special treatment by their fans). — SMcCandlish ☏ ¢ 😼 16:49, 20 January 2024 (UTC)[reply]
Those both go to the same place, so you seem to be the one not reading the material. In particular, read the entire WP:TITLEDAB section in which this is found: nothing in there is invoked unless disambiguation becomes necessary, and it is by definition not necessary for a page if it is the PRIMARYTOPIC; that's what PRIMARYTOPIC even means. — SMcCandlish ☏ ¢ 😼 16:55, 20 January 2024 (UTC)[reply]
Users could also be looking for not limited to: Walt Disney himself as I stated, Disney theme parks, Disney Channel, Disney Studios etc.! This seems to be the primary topic over Disney by usage but not globally. GabrielPenn4223 (talk) 17:15, 20 January 2024 (UTC)[reply]
That's why we have Disney (disambiguation). It's also why we have Heinz (disambiguation). There is nothing different about these cases, other than some Disney fans personally wanting things a certain way to suit their PoV preferences. Disney theme parks, Disney Channel, Disney Studios, etc., are also services, products, or subsidiaries of the Disney corporation. I fear you simply do not understand how WP article titling and disambiguation operate; your arguments strongly suggest this. And you have zero RS in support of your notion that globally "Disney" by itself has a primary referent different from the primary referent in the US (i.e., the Disney corporation, in both cases). I have no idea why you've come to my talk page to argue in circles about this stuff, but it is not constructive, and Wikipedia is not a debate forum. — SMcCandlish ☏ ¢ 😼 17:28, 20 January 2024 (UTC)[reply]
PS: Actually, I now see that you've only been here three weeks; I thought you were a long-term editor already, so that might have come off as unreasonably dismissive, given how long it takes to absorb all of WP's complicated rules and procedures. Article titling on Wikipedia is complex, but the nutshell is that we use the most common name for a subject by default, and disambiguate it only when necessary (on a per-page basis, not on an "everything ever called by this name" basis, and only to the extent necessary). We do not use a longer name than necessary. If something is overwhelmingly the primary topic for a name, it is not disambiguated, and takes that short and recognizable name as the article title, with the disambiguation page being at, e.g., Disney (disambiguation), and other topics by that name being disambiguated one way or another. That DAB page would move to the bare Disney name, without "(disambiguation)", if and only if no primary topic could be determined for "Disney"; but of course there is an overwhelmingly primary topic for that name, the corporation. To get up-to-speed on this stuff, start reading WT:AT from top to bottom, then read WP:DAB and then MOS:DAB. There are also some topical naming conventions pages at Category:Wikipedia naming conventions; the pertinent one here is WP:NCCORP (though a sentence or two in it is subject to an active dispute right now, as being contradictory to policy and several other guidlines). Anyway, Walt Disney Company (and some would move it to The Walt Disney Company to even better agree with the primary-source preference, not being at Disney is an abberation not a norm, and it will not last indefinitely. — SMcCandlish ☏ ¢ 😼 17:39, 20 January 2024 (UTC)[reply]
The Wikipedia Library: Books & Bytes Issue 60, November – December 2023
Three new partners
Google Scholar integration
How to track partner suggestions
Read the full newsletter
Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --13:36, 24 January 2024 (UTC)[reply]
La categoría:Organizaciones de preservación de lenguas ha sido nominada para su eliminación
La categoría:Organizaciones de preservación de lenguas ha sido nominada para su eliminación. Se está llevando a cabo una discusión para decidir si cumple con las pautas de categorización . Si desea participar en la discusión, está invitado a agregar sus comentarios en la entrada de la categoría en la página de categorías para discusión . Gracias. Mason ( discusión ) 23:40 26 ene 2024 (UTC) [ responder ]
Notificación: El servicio de solicitud de comentarios no está disponible
Bueno, no usamos ni deberíamos usar "must" en ninguna parte de MoS ni de ninguna otra directriz a menos que describamos una política o un requisito técnico.
@SMcCandlish , esto es incorrecto. Aquí hay una lista de cinco afirmaciones en la página principal de MOS que utilizan la palabra must . Observe la ausencia de requisitos técnicos y de políticas:
Los cuadros de información , las imágenes y el contenido relacionado en la sección principal deben estar alineados a la derecha.
El encabezado debe estar en su propia línea, con una línea en blanco justo antes.
If a sentence includes subsidiary material enclosed in square or round brackets, it must still carry terminal punctuation after those brackets, regardless of any punctuation within the brackets.
Where such a word or phrase occurs mid-sentence, new terminal punctuation (usually a period) must be added at the end.
Names not originally written in one of the Latin-script alphabets (written for example in Greek, Cyrillic, or Chinese scripts) must be given a romanized form for use in English.
Do you see any here that ought to be presented as mere "should" statements – like, you "should" use proper punctuation at the end of a sentence, but it's sometimes okay if you don't? I don't.
Be clear. Avoid esoteric or quasi-legal terms or dumbed-down language. Be plain, direct, unambiguous, and specific. Avoid platitudes and generalities. Even in guidelines, help pages, and other non-policy pages, do not be afraid to tell editors directly they must or should do something.
If something is actually required, even if it is "only" required by the rules of proper English grammar, then it should be indicated as a "must", not a "should". It is unfair and needlessly confusing to tell editors that something merely should be done this way when we are actually requiring it. There has never been a rule relegating the use of words like must to pages that say "policy" in a box at the top. WhatamIdoing (talk) 21:41, 29 January 2024 (UTC)[reply]
I said "shouldn't" for a reason. All of those things need to be revised. 1. "in the lead section are always right-aligned" (we don't appear to have any exceptions, and if one were found in some single-editor stub, other editors would fix it, so this is true). 2. It is correct that it must be on its own line, as a technical matter, but one blank like just before it is not a technical requirement, just a recommentation (and often ignored when a subheading immediately follows a heading or a hatnote after a heading), so needs to be reworded. 3. Should read "it will still carry terminal punctuation after". Just state it as a fact instead of a demand. 4. Should read "is added at the end." 5. Should read something like "also needs a romanized form for use in English." I would bet good money that all this "must" nonsense was added by a particular editor, now topic-banned from all of MoS, who was on a years-long campaign to make MoS emphatic and excessively prescriptive (in the direction of that person's particular preferences). It has taken many years to clean up after them, and I'm not surprised there are little bits still left to repair. PS: Please do not approach Wikipedia as if a bureaucracy. We absolutely do not need a rule that says we "must" avoid using "must" in things that are not policies or technical requirements. It's just sensible writing, and avoiding "must" in our guidelines simply matches 99.99999% of the rest of our guideline material. Consensus exists regardless of whether it has been recorded in a rule we do not need to record, and when so close to zero of our guideline material says "must" that you can only find 5 examples, that is clearly an overwhelming consensus on the matter. — SMcCandlish ☏ ¢ 😼 21:58, 29 January 2024 (UTC)[reply]
What's your underlying worry with the word must? It seems to be particular to the word itself, because your suggestions have the same level of force, just using other words. I don't think we should tiptoe about in a way that suggests we have people with Pathological demand avoidance in mind. If editors must do something, then they must; there's no benefit to trying to cover that up by saying "always" or "have to" or any of the other synonyms for must.
PS: What I want is for editors to stop saying that guidelines should not use words like must, out of the mistaken and misguided belief that only policies and technical requirements "deserve" to make firm demands on editors. If the community is making firm demands, then those firm demands need to be communicated with clarity and accuracy on every page, not just on pages that have a certain label at the top. (There are a lot more than five examples available, if you want to see them. Here's a list of 108 guidelines using the word must. That's 40% of the guidelines – far too widespread to suggest that it's the work of just one opinionated editor, and far too accepted to pretend that there isn't community backing for this.) WhatamIdoing (talk) 22:27, 29 January 2024 (UTC)[reply]
What's your fondness for it? The concerns are that to anyone familiar with the norms of technical documentation, the word "must" indicates an asbsolute, inflexible requirement, and there is no such thing coming from a style guideline (any policy or technical requirement such a page happened to be contextually reminding editors about comes from an authority external to the guideline, either the policy in question or the technical specs of MW). To anyone not familiar with tech-writing norms, the term still indicates a policy-level requirement, which nothing in MoS is, and it produces basically a "micro-WP:POLICYFORK" of MoS material posing as policy and conflicting with the WP:P&G definition of guidelines as always permitting commonsense exceptions. There absolutely is a benefit to using other teminology, even "always" or "never" if the case really calls for it, rather than "must", namely avoiding the technical confusion that something will break if it isn't done as advised, and the non-technical confusion that someone might be sanctioned if they don't do as advised. This stuff matters. I have no idea why you've this simple copy-editing matter as the hill to die on, but I guaratee you if I open an RfC at VPPOL proposing non-"must" changes to all of the above instances that it will be a WP:SNOW in favor of making them. — SMcCandlish ☏ ¢ 😼 22:40, 29 January 2024 (UTC)[reply]
I like it because it's clear. Style guidelines do have absolute, inflexible requirements. See, e.g., the placement of the lead image or infobox. It will absolutely, inflexibly, invariably be placed on the right.
I don't think that "must" should be conflated with "enforced in software" ("something will break if it isn't done as advised"), and it's wrong to think of breaking a policy as resulting in sanctions. People get sanctioned for violating essays all the time. There are more block log entries citing the essay Wikipedia:Tendentious editing than there are blocks that happened because of violating the policy Wikipedia:Verifiability or the Wikipedia:Editing policy – and we know that both of those policies are violated every day of the week.
I think you would be surprised by the response to your hypothetical RFC. A clear question would be "Shall we first repeal the long-standing policy statement that says guidelines are permitted to use the word must, and if so, shall we then change the wording of all sentences in the Manual of Style currently using the word must, such as those declaring that punctuation "must" be added at the end of sentences, so that they no longer use that particular word?"
That sounds like a loser of a proposal to me. WhatamIdoing (talk) 23:31, 29 January 2024 (UTC)[reply]
If you phrased it that way you would be yelled at for making a non-neutral pseudo-RfC abusing argument to emotion by making fake claims of a "repeal", when nothing at issue about the term "must" would be actually be raised about anything beyond a handful of usese when it does not actually refer to a "must" situation (requirement by policy or technical limitations). I have no idea why you're picking a silly fight about this trivia; we usually seem to get along, but you are coming off as excessively aggressive about this one particular thing, and I'd like that to stop. — SMcCandlish ☏ ¢ 😼 23:51, 29 January 2024 (UTC)[reply]
"Must" situations are not limited to technical limitations and policy requirements. This is not true in the tech doc world; this is not true on Wikipedia. It may be your personal preference, but it isn't true. WhatamIdoing (talk) 23:53, 29 January 2024 (UTC)[reply]
This is just turning circular. Let's stop. — SMcCandlish ☏ ¢ 😼 23:57, 29 January 2024 (UTC)[reply]
As for why I care: When good editors say "Oh, guidelines can't say 'must'" – even though they have policy-level authorization to do so, with none of the limitations you have assumed – then POV pushers and wikilawyers say "When it says 'must', it means 'optional'" when they don't like what the guidelines say, and they say "Well, it says 'should' or 'may', but it really means 'must', because we're just too polite to use hard words like must in a guideline". We lose coming and going when you say that guidelines can't or shouldn't communicate hard requirements, or that certain words are taboo when communicating that requirement.
The placement of the lead image on the right is a hard requirement. There are lots of ways to communicate that, and I don't honestly care which one is chosen. I want you (and anyone else) to stop telling other editors that it's taboo to communicate that hard requirement with the word must. The other options can be better, prettier, nicer, clearer, more alliterative, more concise, more parallel, or any other virtue you can think of; I just don't want you to keep telling people that it's wrong for a guideline to use the word must when communicating a hard requirement that arises from no source higher than the community's views of what that guideline needs to tell people. Editors really must place lead images on the right; we should not be telling them that this is a bad way to express that hard requirement. WhatamIdoing (talk) 00:01, 30 January 2024 (UTC)[reply]
I'm not sure what part of "This is just turning circular. Let's stop" sounded like an invitation to repeat your viewpoint yet again in two more paragraphs. If "There are lots of ways to communicate that, and I don't honestly care which one is chosen", then you're contradicting yourself in demanding "must"-or-bust, and venting at me for no reason about material your profess to not care about the wording of. — SMcCandlish ☏ ¢ 😼 03:55, 30 January 2024 (UTC)[reply]
(Check the timestamps; you posted while I was writing.)
I'm not demanding "must or bust". I'm demanding that you stop telling editors that "must" is not permitted or appropriate in guidelines. Write whatever you think will be most helpful in the guidelines themselves, but:
So long as we have a policy explicitly saying guidelines are permitted to use the word must, don't tell other editors that we can't use "must" in guidelines. It's officially permitted, even if you don't like it.
When 40% of guidelines currently use the word must, don't tell other editors that we don't actually use "must" in guidelines. We don't need any more misinformation going around about that fact.
WhatamIdoing (talk) 04:31, 30 January 2024 (UTC)[reply]
Well, I don't respond to "demand that you stop telling editors" anything. You don't control what I say. Please just drop this; it's starting to irritate, a lot, and you should have picked up on that some time ago. — SMcCandlish ☏ ¢ 😼 08:37, 30 January 2024 (UTC)[reply]
Why I'm opposing the Universal Code of Conduct Coordinating Committee Charter Ratification
A note for my talk-page stalkers – here's my opposition vote comment:
The "even those which would not normally be in the scope of the U4C" portion of this is not acceptable at all: "Movement government structures may also refer UCoC enforcement cases or appeals, even those which would not normally be in the scope of the U4C, to the U4C." Nope. U4C has to stay within its scope or this will just turn into a "forum-shop my buddies to get a result the community denied me" kangaroo court. This even directly contradicts previous rulemaking in the same document: "The U4C will not take cases that do not primarily involve violations of the UCoC, or its enforcement."
This is also problematic (aside from the grammar error in it): "Provides a final interpretation of the UCoC Enforcement Guidelines and the UCoC if the need arises, in collaboration with community members enforcement structures". This "collaboration" is undefined, and too vague to be meaningful.
There may be other issues with it as well, but these two parts alone were enough to trigger my immediate opposition. Policy writing is hard, and the drafters of this are not trying or thinking hard enough yet.
The vote is somehow only open until 2024-02-02. Can anyone say "rush job" and "ramrod"?
The voting page: meta:Universal Code of Conduct/Coordinating Committee/Charter/Voter information
The draft charter: meta:Universal Code of Conduct/Coordinating Committee/Charter
Main page of the UCoC Coordinating Committee: meta:Universal Code of Conduct/Coordinating Committee
— SMcCandlish ☏ ¢ 😼 03:52, 30 January 2024 (UTC)[reply]
Improper close of MOS botany
I recommend you undo your Plant Descriptions thread closure at WT:MOS. As you know from your own work on MOS:CS and your recent proposal to add it to the general WP MOS, the thread is indeed absolutely an MOS issue, WP:BOTANY does not have its own MOS under active development. It's also not a sourcing matter -- Meteorquake is describing the order in which content sections should be presented, and why it being unorganized as now causes confusion, which seems like exactly the kind of thing MOS:CS is set up around.
Meteorquake was correctly told to check with WT:BOTANY. But as this can be nothing other than a style issue, and as BOTANY has no MOS project set up yet, the thread is improperly closed, and the description and edit summary are inaccurate. SamuelRiv (talk) 00:26, 31 January 2024 (UTC)[reply]
"Meteorquake was correctly told to check with WT:BOTANY" is entirely correct, and that should be sufficient. There is no "improperly" about closing it; if you think otherwise, feel free to point me to the policy that says so. But it's not an admin close; you can just go revert me if you insist on it. The primary concern raised in that WT:MOS thread has nothing to do with article writing style or even article structure in the strict sense (what sections need to exist per MOS:LAYOUT and in what order). It is about content and sourcing pertaining to the phenotypic presentation of a plant in different environments. I.e., it's about whether sufficient source research on a given plant has been done by our editors. It's also very secondarily about the information architecture of the information that is available, i.e. whether the material is grouped in sections in a sensible manner, but MoS has no rule about this, and it's an article-by-article determination. WT:BOTANY needs to be made aware of the problems, with the topically competent participants there being the most likely editors to address those issues in the affected articles (which might be numerous and may be disparate in their cleanup needs, in ways no MoS line item could ever address).
"BOTANY has no MOS project set up yet" doesn't even really make sense. There is no such thing as a wikproject's "MOS project". The MOS:CS discussion is about the nonsensical situation that we have a long-standing style advice page that is actually followed and has MOS:FOO shortcuts, i.e. is basically treated as if it's part of MoS, but it not titled, tagged, and categorized as one, but as a wikiproject style essay. That WP:BOTANY has no corresponding page, either as a guideline or as an essay, is just immaterial. The vast majority of wikiprojects have never generated a style advice essay, much less gotten it elevated to MoS guideline status, because most topics do not have style matters we need to address that are topic-specific. The lack of more such essays and guidelines is generally desirable, for WP:CREEP and especially WP:MOSBLOAT reasons: We don't need more rules than we already have (actually need fewer of them), most especially style rules, which are subject to more dispute than any other kind. — SMcCandlish ☏ ¢ 😼 02:01, 31 January 2024 (UTC)[reply]
Never mind; I reverted my own close and left a more detailed note about why this is off-topic. Nothing was wrong with closing it, but I'm tired of lame arguments. — SMcCandlish ☏ ¢ 😼 05:03, 31 January 2024 (UTC)[reply]
— SMcCandlish ☏ ¢ 😼 23:50, 31 January 2024 (UTC)[reply]
A barnstar for you!
Also an opportunity to still thank for your support for the NEC Nijmegen rename! gidonb (talk) 10:10, 3 February 2024 (UTC)[reply]
Didn't even remember that one. I comment in lots and lots and lots of RM discussions. :-) — SMcCandlish ☏ ¢ 😼 10:17, 3 February 2024 (UTC)[reply]
Yes, we usually look forward and there is always so much to do on WP. After identifying someone as a good candidate for a barnstar, it can be fun to see how you collaborated. For example. gidonb (talk) 10:41, 3 February 2024 (UTC)[reply]
Ah yes! I did come closer to ArbCom election, twice, than any other non-admin candidate. I still think we need at least one non-admin in ArbCom, every tranche, since when it is all admins all the time, it's a "who's watching the watchmen?" problem. But I'm unlikely to run again. Me being one of main shepherds of MoS (and thus a blockader of constant attempts to change it willy-nilly to suit people's personal writing-preference pecadillos) means there will always be a large contingent of editors angry with me, so I'm ultimately just never going to be a suitable candidate. Someone else who does entirely non-controverial work around here should run. Besides, I really don't have time for it now. In that era, I did. — SMcCandlish ☏ ¢ 😼 11:09, 3 February 2024 (UTC)[reply]
Well, at least you tried!!! In my 20+ years as a Wikipedian I have never submitted myself to anything, or any article I wrote, though there were times I ran into cool historical stuff during my research. Just one example. I did try all kinds of change, for example renaming the Belgian province of Luxembourg, you joined me, and we went down in flames. Since then the standards have been changed, making such a move virtually impossible. Over the years at WP, through trial and error, I have learned to put the stuff that does come your way without asking (I was always happy it did) more front and center so people write to you, at least on average, more focused on content and at a more pleasant tone. gidonb (talk) 16:07, 3 February 2024 (UTC)[reply]
A pleasant tone is rare in style matters, for reasons. Because every single editor detests at least one line item in MoS, and I get in the way of them forcing a change to suit their preferences (which would just turn into years of slow revert-warring with others who have different preferences), some subset of editors are perpetually pissed off at me. It's just how it goes. — SMcCandlish ☏ ¢ 😼 21:50, 3 February 2024 (UTC)[reply]
I sure see that you deal with a lot of unpleasantness on your talk page. Take a look how my talk page starts every year and see if this will work for you. I really hated all this negativety poured over me and it has become much less since I use this system. Just a friendly tip of something that works for me, for someone who deserves better! Thanks again for all that you do and until the next collaboration! gidonb (talk) 01:40, 4 February 2024 (UTC)[reply]
Which diff am I looking for? — SMcCandlish ☏ ¢ 😼 02:25, 4 February 2024 (UTC)[reply]
It's not a diff. Look at your LI and give me a call sometime ;-) Take care! gidonb (talk) 02:36, 4 February 2024 (UTC)[reply]
Ah, I see: big pile of barnstars. :-) LI? LinkedIn? I don't go there very often, but will stop in. — SMcCandlish ☏ ¢ 😼 03:08, 4 February 2024 (UTC)[reply]
User talk:Eric#Problem
Hi, I would like to bring this problem to your attention. The behaviour of this user seems strange to me; for example you, and I trust you very much, put vecchio in italics, why then did I, who followed the same logic, according to this user get it wrong? However, I follow the indications of a very famous and renowned English dictionary, so I'm not using italics at random. JackkBrown (talk) 03:24, 3 February 2024 (UTC)[reply]
Please use the preview feature before saving. You hit me with ten "new message" notices, to just leave a two-sentence note. I've responded to the issue over at Eric's talk page. — SMcCandlish ☏ ¢ 😼 03:53, 3 February 2024 (UTC)[reply]
@SMcCandlish: sorry for the notifications. And what about my question? The fact that, for example, on the vecchio page, the italics is correct, and on the pages that this user has modified he claims that it's incorrect (https://en.wikipedia.org/wiki/User_talk:SMcCandlish/Special:Contributions/Eric), even though I have consulted the English language dictionaries and these foods aren't present? I really don't understand... JackkBrown (talk) 03:59, 3 February 2024 (UTC)[reply]
And now four more "new message" notices, for another short comment. Compose what you want to say. Re-read it. Save it when you are done with it. Please. I've already addressed the substantive matter at Eric's page. In short: the italics are not needed in this case, because "Parmesan cheese" or just "Parmesan" for short is an entirely assimilated term in English. Parmigiano Reggiano probably is not, though I'm not certain that would be capitalized that way in Italian; I suspect it owuld be parmigiano reggiano because most Latin-derived languages do not capitalize adjectives derived from proper nouns (I have not studied Italian in any depth, though). Vecchio would be italicized because that is not a term used in English, except in highly specialized material about Italian theatre. And again, "italicized" in this particular context means "marked up with {{lang|it|...}} which produces the italics and also does language encoding". — SMcCandlish ☏ ¢ 😼 04:25, 3 February 2024 (UTC)[reply]
@SMcCandlish: but I'm not referring to "Parmesan", which was not in italics before, I'm referring to the fact that he deleted all the other italics (https://en.wikipedia.org/wiki/User_talk:SMcCandlish/Special:Contributions/Eric; to "pizzoccheri", "tortelloni", etc., uncommon in English language, according to "Collins Dictionary" and other dictionaries). JackkBrown (talk) 04:29, 3 February 2024 (UTC)[reply]
"Tortelloni" is also assimilated into English (or most would think so). Pizzoccheri certainly isn't. But I'm not going to get into a big dispute about this. I warned you a while back that you were likely to run into conflict with other editors if you choose to focus your attention on italicizing Italian terms in English, and here it has happened as predicted. And you're still re-rediting and re-re-editing every comment you make on a talk page. I edit-conflicted with you twice trying to respond, and nothing you've added to your original post was necessary in the first place. Please stop doing that. It's one thing if you need to correct an error, but you seem to have great difficulty for some reason in just making your point and posting it, instead of making one third of your point, then posting that partial thought immediately for no reason, only to make another partial point a moment later, then another partial point another moment later, and so on. It's quite frustrating. — SMcCandlish ☏ ¢ 😼 04:39, 3 February 2024 (UTC)[reply]
@SMcCandlish: "tortellini" is assimilated in the English language, but not "tortelloni". JackkBrown (talk) 04:41, 3 February 2024 (UTC)[reply]
In any case, he didn't delete my edits because he thought these terms were common, he claimed that "We don't italicize the term that is the subject of the article throughout the article", absolutely NONSENSE (User talk:Eric#Problem), he also deleted the italics that had already been there for some time (on "pecorino romano"); I repeat, he did this for his own interests, not for a question of known or unknown, he didn't speak of this. In any case, yes, it's difficult for me to express my ideas, because I'm not listened to (by you yes, but by others almost never). JackkBrown (talk) 04:47, 3 February 2024 (UTC)[reply]
And now seven more "you have a message" notices from you. What is the problem here? Why can you not just compose a message, think about it for a moment and re-read it a couple of times, edit it as needed, THEN post it, and leave it alone? Both "tortellini" and "tortelloni" are common enough in English. "We don't italicize the term that is the subject of the article throughout the article" is obviously not correct for terms that are foreignisms in English. But what he might have been meaning to say is something like "This term has not been italicized throughout the article, so it should not have been italicized by you in this particular spot." I'm not really sure, and do not have a lot of incentive to get involved in this dispute over trivia. — SMcCandlish ☏ ¢ 😼 05:26, 3 February 2024 (UTC)[reply]
@SMcCandlish: that's fine, but it's very bad that every little mistake I make (I make very few and correct them if I can) is made out to be a huge thing, and that instead really problematic users like him are left alone. There's no unequal treatment, I'm fed up. I have given so much, too much, to this encyclopaedia, and in return I have only received criticism, some of it constructive. Good night and excuse me. JackkBrown (talk) 05:48, 3 February 2024 (UTC)[reply]
This may not be a good hobby for you if a disagreement about italics or capitalization makes you think someone else is "really problematic". We do not need to have a battleground about such matters. — SMcCandlish ☏ ¢ 😼 06:04, 3 February 2024 (UTC)[reply]
"at 85", "at age 85", "at the age of 85", etc.
@Martinevans123, Necrothesp, Julietdeltalima, and MapReader:: It's unlikely that the short forms (or at least the semi-short one) constitute "an Americanism omitting vital words". There is likely dialectal variation on this even within the UK itself. There's a whole book about the subject of "She gave him a book" versus "She gave a book to him" construction variety across British English itself: Gerwin, Johanna (2014). Ditransitives in British English Dialects. Topics in English Linguistics ser., no. 50.3. De Gruyter Mouton. ISBN 9783110352146. Probably something to get at a library (perhaps through inter-library loan) unless you have access to such material via some kind of institutional account. It's one of those stupid-expensive academic volumes, at US$138. My own n-grams showed broad usage distribution when it came to the age phrasing. The thread's now archived at Wikipedia talk:Manual of Style/Archive 227#Aged etc, but in summary: it's probably good that we did not get toward instituting some "rule" about this, based on anecdotal speculation about what sounds best to any of us. Best left to editorial discretion at a particular article (even a particular sentence, e.g. one might have an early sentence use the long form and a later sentence use one of the shorter ones to avoid unnecessary repetitive verbiage). — SMcCandlish ☏ ¢ 😼 03:08, 15 February 2024 (UTC)[reply]
I think you nailed it early on, with your bracketed comment “each of them works better in different sentence structures”. There may well be national differences in which formulations ‘feel’ more natural in different contexts, but if we were able to nail them down precisely at WP, we ourselves would be writing books for $138 a time. MapReader (talk) 05:21, 15 February 2024 (UTC)[reply]
I actually started writing a Style Guide for English with a Global Audience in the 21st Century (among other working titles), and years later it's only fractionally done (60,000 words). Writing a serious book takes tremendous discipline and focus (which would mean largely abandoning WP for a long period of time) to do all the research and then actually synthesize it into something useful. I do have co-authorship of one book under my belt, but honestly it was mostly assembled by the other author, from material I'd already written in the course my "day job". Writing comprehensive non-fiction from scratch is really challenging. I'll probably finish one on the history and politics of tartans and Highland dress before I finish the style book. — SMcCandlish ☏ ¢ 😼 15:16, 21 February 2024 (UTC)[reply]
Title caps question
Greetings, SMcCandlish! Hey, here's a title caps question for you. Shouldn't "Sitting on Top of the World" actually be "Sitting On Top of the World", with the word "on " capitalized? I was sorta thinking it should, because MOS:TITLECAPS says to capitalize "the first word in a compound preposition (e.g. Time Out of Mind)". I'm not sure though, so, what do you think? — Mudwater (Talk) 15:56, 18 February 2024 (UTC)[reply]
P.S. The reason I'm asking is that I'm planning on creating an article about Sitting On Top of the Blues, an album by Bobby Rush, and I want to use the appropriate capitalization for that. — Mudwater (Talk) 19:54, 19 February 2024 (UTC)[reply]
@Mudwater: It's on, since this is a prepositional phrase with a noun referent (on + top) which in turn is modifying another prepositional phrase with another noun-phrase referent (of + the world/blues). It's not a compound preposition like out of (a chaining of two prepositions into a new meaning; sometimes these completely fuse, as in upon, onto, into, within, without, and the Northern British equivalent of the latter, outwith, picked up from the Scots language, plus some vernacular spoken English novelties like outta; others do not fuse, e.g. "out in[to]", "from around", etc., as in "going out in[to] the world", "reaching from around the side"). Rather, "on top of" (a contraction of on the top of) has top which is a locational noun, not a preposition. That is, it's an obscured prepositional phrase with a noun object, not a compound preposition. There are lots of these (some more common in one dialect than another): "going out back", "moving up front", "coming from behind" (with "behind" in its locational noun sense, not the prepositional use in a phrapse like "stand behind the line"). This particular "on top of" case is confusing because it's become a stock phrase, and may be on the way to evolving into a compound preposition (some fused examples of that process would be inside, outside, alongside, contractions from longer Middle English phrases that used side as a noun). One could say "going out back on Sunday", "moving up front in time with the others", "coming from behind out of nowhere", etc., and similarly juxtapose two prepositional phrases with the first modifying the second, as in sitting on top of the world, but they don't form customary collocations like "on top of". There are a few other such collocations, like "in front of", "at/in the front/rear/back/side of", but treated as any other prepositonal construction in a title: "Go to the Back of the Line", "Alone in Front of the Jury". (In a few hundred years, may have a fused novel preposition, infronta.)
So anyway, "Sitting on Top of the World" and Sitting on Top of the Blues are what to use. Broad advice that serves well on virtually all style questions: If there's any doubt, presume it's poorly founded and just follow the most applicable general MoS rule, as a default. (If you think some codified exception to it might apply but are not sure, presume it does not.) If you skirt the rule based on subjective doubt, it invites unnecessary dispute which would likely not arise otherwise. Put another way, if you can imagine some doubt, leave it to someone else with a bee in their bonnet about it to make the case that the doubt is well-founded and that an exception applies or should be made. Don't do the work for them (you'll find it thankless, since such propositions always meet with objection from others). — SMcCandlish ☏ ¢ 😼 14:24, 21 February 2024 (UTC)[reply]
Excellent, that's great stuff! Thanks! — Mudwater (Talk) 01:45, 22 February 2024 (UTC)[reply]
"Template:R from project" listed at Redirects for discussion
Gracias por mejorar la calidad de los artículos en febrero. - La imagen, tomada en un cementerio el año pasado después del funeral de un familiar lejano pero querido, conmemora hoy, con agradecimiento por sus logros, a cuatro sujetos mencionados en la página principal y a Vami_IV , un amigo aquí. Escuche música de Tchaikovsky (un artículo donde aparece uno de los cuatro ), cantada por el sujeto de hoy (cuya actuación en el escenario disfruté hace dos días). -- Gerda Arendt ( discusión ) 17:37 20 febrero 2024 (UTC) [ responder ]
Seriously? You're going to start an AN thread and make an evidence-free bad-faith accusation, all because you're not getting your way at an essay about the disrutiveness of style-warrior behavior? Really? Every heard of using the talk page? — SMcCandlish ☏ ¢ 😼 21:39, 21 February 2024 (UTC)[reply]
Spectacles in photograph
They're at least one size too big for you. Tony (talk) 03:20, 22 February 2024 (UTC)[reply]
I like 'em big and nerdy. The frames mostly keep out of my vision. — SMcCandlish ☏ ¢ 😼 03:26, 22 February 2024 (UTC)[reply]
Reason endorsed. Tony (talk) 04:05, 22 February 2024 (UTC)[reply]
Especially important with an ultra-wide monitor! Mine visually fits more or less perfectly within my periperhally visible frames. — SMcCandlish ☏ ¢ 😼 12:29, 22 February 2024 (UTC)[reply]
Yer talkin' to someone who did a PhD in perhiperal vision. :-) Tony (talk) 23:00, 22 February 2024 (UTC)[reply]
Ah so! I especiall like this pair for the movies, too; I can get the whole screen in without having to move to the back rows. — SMcCandlish ☏ ¢ 😼 02:59, 23 February 2024 (UTC)[reply]
Hi, I just wanted to check in again in case you may have missed my message. If you have time to take a look at my recent edit request on the Dahua Technology Talk page, I would greatly appreciate it. Thank you, Caitlyn23 (talk) 16:22, 5 March 2024 (UTC)[reply]
Notice of Arbitration Enforcement noticeboard discussion
I know we haven't always seen eye to eye on certain items, but you're easily one of the most knowledgeable editors out there about MOS matters and I respect your point-of-view. My question is about linking from infoboxes. Over the past couple of years, infoboxes have been gradually added to several featured biography articles. Many of these articles have links to list of works or awards for quick reference for example, Alec Guinness has a link to works. Does this practice violate the MOS? Is this spelled out anywhere? Should it be? Thanks for any feedback you can provide! Nemov (talk) 16:39, 24 February 2024 (UTC)[reply]
@Nemov: FWIW, I don't recall not seeing eye-to-eye with you; I make a habit of ignoring and forgetting usernames to the extent I can so that I stay focused on content instead of personalities. :-)
As to the question: Is this only about links that go out to another article like Alec Guinness on stage and screen, or ones that link in-article to a section below? I think with regard to the Guinness case (and similar stuff is very often done at band and album and single articles, to link to discographies, to previous/next album in chronological sequence, to album from song, etc.; and there are many other such cases), this is basically an integration of navbox features into the infobox, to avoid having a separate right-hand navbox sidebar. In many cases, it's going to be technically redundant with a page-bottom navbox, but there seems to be widespread community tolerance of providing multiple forms of navigation to account for the different ways various individual readers respond to information-architectural features. E.g. navboxes themselves are technically reundant to categories and vice-versa. This is covered in a general way at WP:CLNT.
I just searched that page for the word "infobox" and it does not appear. I searched MOS:INFOBOX for "nav", and the relevant material there is this: "As with navigation templates, the purpose of the infobox is for its utility, not appearance; therefore, infoboxes should not be arbitrarily decorative. ... Like navigation templates, infoboxes should avoid flag icons. For more information about flag icons, see MOS:FLAG. ... Other types of templates: Wikipedia:Navigation templates – article footers designed to provide links to several related articles". That's it. Nothing relevant for a "nav" search at WP:WikiProject Infoboxes. Template:Infobox provides an example of merging an infobox into {{Sidebar}} as a sub-box (and the implication is that it works the other way around, too, since {{Infobox}} and more specific infoboxes based on that meta-template also support the sub-box functionality).
There seems to be no pro or con guideline material (unless it's in some other page) that pertains to having navigational features in infoboxes (either as line-items like in the Guinness case, or as sub-boxes). Per the lead material at MOS:INFOBOX, an infobox primarily serves as a nutshell that "summarizes key features of the page's subject" ("features" is rather poor wording; I'm going to go change that to "facts" or "details") and "show[s] information relevant to the article subject"; "relevant" at least in theory could include some navigational material to closely related articles (I'm more skeptical regarding links to sections within the same article). There appears to be broad acceptance, so far, of navigational features also being present in infoboxes, at least in certain types of infoboxes and in certain forms, but it's not clear whether this is actually a best practice. So, something to perhaps raise as a question at WT:MOSINFOBOX. History that occurs to me is that WP's infoboxes actually originated as a form of navigation, and were first implemented at articles that were part of a series on related subjects. They were only later generalized to other sorts of articles because their features were thought useful. Given the level of discord that arises about infoboxes, I'm hesitant to say more, ha ha. — SMcCandlish ☏ ¢ 😼 19:41, 24 February 2024 (UTC)[reply]
Gracias por la atenta respuesta. Sí, esto tiene que ver con el enlace a un artículo relacionado por separado, como Alec Guinness en el escenario y en la pantalla . No creo que tenga sentido si el enlace va a una sección del artículo. Nemov ( discusión ) 20:11 24 feb 2024 (UTC) [ responder ]
Espero que ayude de una forma u otra. Sé que no es una respuesta sencilla, pero al menos WT:MOSINFOBOX es claro como el lugar donde buscar aclaraciones, proponer algunos consejos/límites/prácticas, etc. — SMcCandlish ☏ ¢ 😼 00:23, 25 de febrero de 2024 (UTC) [ responder ]
Solicitud de comentarios: Solicitud de comentarios sobre lengua y lingüística
Hola, he trabajado un poco en la página, he añadido más reseñas, he notado tus amables modificaciones, ¿podrías echarle un segundo vistazo? Sinceramente, creo que este trabajo es notable y alimenta una discusión muy actual sobre la IA; el libro es muy opinativo, y tal vez esta sea la razón por la que su página de Wikipedia se lee como opinativa, aunque hice todo lo posible por mantener un punto de vista neutral. Gracias Andrea Saltelli Saltean ( discusión ) 17:33, 3 de marzo de 2024 (UTC) [ responder ]
@ Saltean : Lo trabajé un poco más y eliminé la mayoría de las etiquetas de limpieza, ya que el tono ha mejorado enormemente. Pero nada va a resolver el problema de la notoriedad cuando la mayoría de las fuentes son entrevistas y sitios web no notables escritos por personas al azar, y lo que no es así son principalmente reseñas rutinarias que no indican que el trabajo tenga un significado duradero. — SMcCandlish ☏ ¢ 😼 19:37, 3 de marzo de 2024 (UTC) [ responder ]
MOS: Consulta biográfica: nombrar a jueces del Tribunal Superior del Reino Unido en artículos complementarios
Ey,
¿Tiene WP:MOSBIO alguna orientación sobre cómo nombrar a los jueces del Tribunal Supremo del Reino Unido en artículos fuera de sus respectivas biografías? Actualmente estoy trabajando en rescatar un borrador en el que es necesario hacer referencia a una sentencia del Tribunal Supremo y al juez que la emitió. Las fuentes sobre la sentencia en sí describen al juez como el Sr. Juez <nombre> . No puedo decir con certeza si esto es algo que está cubierto por MOS:JOBTITLE o una aplicación extraña de MOS:CREDENTIAL , o si hay alguna otra orientación más específica en otro lugar. ¿Tiene alguna idea sobre esto? Sideswipe9th ( discusión ) 20:03, 3 de marzo de 2024 (UTC) [ responder ]
@Sideswipe9th: That would be a CREDENTIAL matter + MOS:HONORIFICS and MOS:MR. WP doesn't use Mr[.], Mrs[.], Ms[.], Mx[.] (or foreign equivalents like French M./Mssr., Mme., Mlle.) in any manner like this[*] (some newspapers do it, including various British ones as well as The New York Times, as an old-fashioned-ism). "Justice Gwynneth Knowles" or whatever would be appropriate, when it's necessary to indicate that they're a justice, but after that's established, just "Knowles" would usually work. (That said, all or almost all of these persons are Sir/Dame also, and whether use that in any particular construction is often subject to some debate. It doesn't seem conventional to write "Mrs. Justice Dame Gynneth Knowles" for whatever reason, and "Dame"/"Sir" is only ever used when first name is present, so not "Dame Knowles"). US and other figures are treated the same way with regard to the judidical titles, e.g. "Chief Justice John Roberts", thereafter just "Roberts". [* The exception is of course when "Mr." or whatever isn't being used in its normal way and is forming part of a proper name, like the bands Mr. Bungle and Mr. Mister, or the song title "Mrs. Robinson". But the speaker of the US House of Representatives is "job-titled" here as Speaker Mike Johnson not Mr. Speaker Mike Johnson, though the latter is the conventionalized way for him to be addressed by other legislators when in session.]
I think what's happening here is also that people confuse forms of address used when writing to people or introducing them at a function, with how to write about them in the third person. Thus you can sometimes run into things like "the Rt Hon. Alex Crabapple" in running text, despite HONORIFICS saying not to do that. Should just be fixed when encountered without making a big deal out of it, unless someone's going around doing this all over the place, then they need to be pointed at the guideline and asked to stop.
There's a closely related problem in which some editors from WP:PEERAGE and WP:ROYALTY have gone around in a WP:FAITACCOMPLI manner, misusing (over numerous objections) the |name= parameter of {{infobox officeholder}} or {{infobox person}} to hold an honorific form of address that is neither the name nor how the person would normally be written about in third person, but how they would be addressed in a letter or when introduced at a speaking engagement. See, e.g., Gwynneth Knowles, Margaret Thatcher, David Cameron, etc. This is confusing to readers and editors alike, and not even really encyclopedic information, since virtually zero of our readers need to write a letter to David Cameron, and even if they did, WP is not advice on the etiquette of how to best do that (though the form of direct address arguably might be coverable somewhere in the article on the general sort of title). The only way to resolve that mess is probably going to be with a VPPOL-level RfC. I don't relish it, because it's going to be yet another instance of topical specialists in conflict with general MoS rules, and that almost always leads to heat and drama. — SMcCandlish ☏ ¢ 😼 21:02, 3 March 2024 (UTC)[reply]
"Justice Gwynneth Knowles" or whatever would be appropriate, when it's necessary to indicate that they're a justice, but after that's established, just "Knowles" would usually work. Awesome, I'll make that change in a moment.
It might be helpful if some direct guidance on this could be added somewhere in the MOS? It's not clear from the plain reading of CREDENTIAL or HONORIFICS how to handle this specific type of name (UK High Court justices) in practice. Quite a lot of them tend to be allowed to use The Honourable or The Right Honourable honorifics, and while those are generally excluded outside of their own biographies it's unclear how that also interacts with the Justice title. Sideswipe9th (talk) 21:13, 3 March 2024 (UTC)[reply]
In theory MoS could be clearer on this, though it may take a little research. — SMcCandlish ☏ ¢ 😼 05:51, 5 March 2024 (UTC)[reply]
Feedback request: Religion and philosophy request for comment
La biblioteca de Wikipedia : Libros y bytes
, número 61, enero-febrero de 2024
Bristol University Press y British Online Archives ya están disponibles
Resultados de 1Lib1Ref
Lea el boletín completo
Enviado por el equipo de entrega de mensajes de MediaWiki en nombre del equipo de la Biblioteca Wikipedia --16:32, 5 de marzo de 2024 (UTC) [ responder ]
Nominación para la eliminación de Plantilla:Lang-ang/doc
Según este informe de AE, se le recuerda formalmente que debe mantener la civilidad en las discusiones de MOS, que sigue estando sujeto a sanciones y que la civilidad se aplica en todas partes en Wikipedia. Supongo que si termina nuevamente en AE, el resultado será significativamente más severo. ScottishFinnishRadish ( discusión ) 23:45, 13 de marzo de 2024 (UTC) [ responder ]
@ScottishFinnishRadish: Noted, but please beware of presumtion of guilt, which your notice is heavily laced with. Anyone may "end up at" AE, AN[I], or any other noticeboard, with various accusations made against them which may not be true.
In particular, in this case I demonstrated that while I had displayed some civility issues, many of the accusations were false, especially with regard to "assuming bad faith", which I provably did not do, and which is what my sanction actually pertains to, not incivililty. "Assuming bad faith" and "incivility" are not in any way synonymous. I would expect that an AE admin would understand all of this deeply and clearly. — SMcCandlish ☏ ¢ 😼 01:55, 14 March 2024 (UTC)[reply]
@ScottishFinnishRadish: I find it rather concerning, in a WP:ADMINACCT way, that after you posted above what amounts to an unreasonable threat to use administrative powers in response to me ever simply being accused of something again, after I successfully defended myself against false accusations of the same sort already, that you have produced no response of any kind to the concerns I've raised about that. I've let this lie for 7 months and that is more than long enough for you to address them. — SMcCandlish ☏ ¢ 😼 12:55, 16 October 2024 (UTC)[reply]
I assessed the consensus of uninvolved administrators at AE, and informed you of the result. That you disagree with the result isn't unexpected, but it is what it is. As far as admincond goes, I didn't see anything requiring a response. You asked no questions, and said how you thought you comported yourself in the AE report. My close was based on the consensus of uninvolved administrators, which was clear after reading the discussion. I'd be OK closing this with a reminder about that restriction... I think that serves as well as anything... Concur... Adding a sentence to the "reminder" that civility applies everywhere on Wikipedia should be enough there... That seems fair to me.ScottishFinnishRadish (talk) 13:24, 16 October 2024 (UTC)[reply]
@ScottishFinnishRadish: You did that but also included what is very difficult to not interpret as a block/ban threat simply for being accused again, simply for reappearing on the AE radar, ever, regardless of the evidence: I expect that if you end up at AE again the result will be significantly more severe. You also improperly commingled two entirely severable matters ("reminders about that restriction" and "'reminder' that civility applies everywhere") in a grossly misleading way that implies they are identical or one a subset of the other: leading with civility, tying that in the same sentence to my restriction (which is AGF not CIVIL), then reinforcing this policy- and sactions-incorrect admixture with another semantic tie of the latter back to civility, doubling down on the error.
Let's rewrite your message with substitute terms and you should see why it's problematic and to what extent: "You are formally reminded to not litter in the park, that you remain on probation [for tax evasion], and that not littering applies everywhere within the city limits. I expect that if you end up at court again the result will be significantly more severe." — SMcCandlish ☏ ¢ 😼 16:48, 16 October 2024 (UTC)[reply]
I had assumed that explicitly linking to the sanction would adequately communicate the sanctions I was referring to. The last part, noting that if you ended up at AE again (for a related issue, which I suppose I could have explicitly said) that I expected you'd see a more severe result was based on my reading of the discussion and the good faith that was extended in accepting that you had forgotten about the existing sanctions. ScottishFinnishRadish (talk) 17:11, 16 October 2024 (UTC)[reply]
I understand that (and why) you thought what you wrote was "good enough" or "clear enough" or however you might like to phrase that. But that's not actually responsive in any way to my points about why it was malformed and alarming to the point of being inappropriate (for multiple reasons). If you're going to continue just dodging this, then don't bother; I've made the point and you can actually respond to it or not, but it doesn't magically go away. — SMcCandlish ☏ ¢ 😼 02:54, 17 October 2024 (UTC)[reply]
Feedback request: Religion and philosophy request for comment
Disregard
– No such RfC by the time I got there, and I see a lot of noise at that and related pages generated by anonymous proselytizers who probably get reverted a lot.
¡Gracias por mejorar la calidad de los artículos en marzo! - Subí fotos de las vacaciones en Madeira (desde casa, al menos el primer día) y recuerdo a Aribert Reimann . -- Gerda Arendt ( discusión ) 20:57, 20 de marzo de 2024 (UTC) [ responder ]
Definitivamente, en minúscula, ya que se trata de un título de trabajo genérico. La tercera viñeta sugiere poner en mayúscula un puesto/cargo/título único como tema de su propio artículo (y, se supone, en oraciones en la misma línea, por ejemplo, "el cargo de Ministro de Paseos Tontos se creó en 1970"), e incluso esto es dudoso, porque es al menos conceptualmente contradictorio con todo lo demás en la sección. Pero no significa que se deba hacer esto con títulos de trabajo genéricos como "director de operaciones" o "profesor" o "oficial de control de animales". — SMcCandlish ☏ ¢ 😼 04:12, 22 de marzo de 2024 (UTC) [ responder ]
Se necesita ayuda para la página Ciencia romana: orígenes, desarrollo e influencia hasta la Baja Edad Media.
@Saltean: Fixed that for you. You should have been able to use the "Move" function to do this, as I did. Where it is and what it's called will vary depending on which skin you are using and which gadgets or other scripts you have installed (for me, it is in the top menu, as Page > Move, but I'm not sure that's the default appearance, and in some situations it might be just in the main menu and not under a "Page" submenu, and in some it might be named something like "Move page" or "Rename"). — SMcCandlish ☏ ¢ 😼 12:00, 27 March 2024 (UTC)[reply]
Thanks, also for your extensive work on the page. Andrea Saltelli Saltean (talk) 16:21, 27 March 2024 (UTC)[reply]
You're welcome. I do so much grammar, citation formatting, and other minor-cleanup fixing that I have a lot of it on "auto-pilot", pretty much. Various scripts I've installed (and in some cases written) tend to help with it. — SMcCandlish ☏ ¢ 😼 16:17, 28 March 2024 (UTC)[reply]
Possible farewell
Hello SMcCandlish. I am about to start an arbitration request. I don't have high expectations and I am even thinking I may get an indefinite block as boomerang, but it is something I have to address. I hope I don't get blocked and I may not get an indefinite but just in case I wanted to highlight my appreciation for the time you have taken in responding to my queries in a detailed and quality manner. Sincerely, Thinker78(talk) 05:19, 28 March 2024 (UTC)[reply]
@Thinker78: Commented over there. I doubt ArbCom will act on this (and not in a boomerang manner; they'll just conclude there's not enough of a case there). I don't think you should have been blocked over any of this, much less for a week, or had unblock requests rejected, or had talk-page access revoked – it was all an unnecessary overreaction and dog-pile on top of that overreaction, and has an entirely punitive feel to it, since it was not actually preventing any harm to the project. But ... I think your taking a "butt-hurt" venty stance on the matter didn't help. I don't mean that as a strong criticism; it's a reactive approach I've taken too many times myself, so I just know from experience that it tends not to end well! I've also appreciated your activity around here, despite us having conflicts on some style matters and such. Every long-term editor is an asset to the 'Pedia and its audience, and I hope this flare-up of WP:DRAMA doesn't discourage you from continuing. Sometimes it is good to take a break after such things, though. Either entirely, or just mostly. I've done both many times, and am in the middle of one of the latter for the most part, after a recent pillorying at AE. Finding other stuff to keep me busy, including a lot of reading, and baby steps towards learning another language, via Duolingo and some other materials. I've barely been checking in here, for a few weeks now, and it's been a nice change of pace. — SMcCandlish ☏ ¢ 😼 16:15, 28 March 2024 (UTC)[reply]
Well, I see that ANI did act (with a community ban), but not on that request so much as all the followup after it. I guess you get a break mandatorily now. I would think that after 6 mo. or so, an appeal would be successful if you do it right. There's no question that you're generally a productive editor; something just snapped recently, and needs repairing. :-) — SMcCandlish ☏ ¢ 😼 00:05, 6 April 2024 (UTC)[reply]
One more academic reference for the page on "Resisitng AI "
Hi! I continue monitoring for new pieces treating McQuillan's Resisting AI as they appear, and one just came out in the International Journal of Communication 18(2024), Book Review 967–970; see the text here.
Could the notability warning be removed? Thanks for your help and Happy Easter. Andrea Saltelli Saltean (talk) 17:22, 31 March 2024 (UTC)[reply]
Will look into it as time permits, but I have a lot going on right now. In the interim, it would not hurt to look for more, via scholar.google.com, scholar.archive.org, and if you qualify for it, by getting an account at WP:The Wikipedia Library (apply at https://wikipedialibrary.wmflabs.org/) and using its resources to search through journals that are not available via the other means (see here for a list of the research materials available; it's impressive). — SMcCandlish ☏ ¢ 😼 02:22, 1 April 2024 (UTC)[reply]
Thanks, I use Wikipedia Library. I got it after the one thousand edit I think. Good also for research. Best! Andrea Saltelli Saltean (talk) 06:53, 5 April 2024 (UTC)[reply]
Found one more citation and added it. This book really appears to be having an impact. A test: Google Scholar for "resisting AI" for 2023 gives 124 citations, for 2024 40 citations ... wish my own papers has such a rate of growth. Best Andrea Saltelli Saltean (talk) 08:33, 10 April 2024 (UTC)[reply]
... and two more citations from academic articles added today. Best Andrea Saltelli Saltean (talk) 10:51, 11 April 2024 (UTC)[reply]
References in parenthesis
Hi SMcCandlish. Sorry it seems easier to ask than find the relevant sections of MOS, but should reference be in inside or outside parenthesis (when used in article text)? Blah blah (Blah[1]),... Seems logical but Blah blah (Blah)[1],... looks more in keeping with the way articles are styled. I'm betting it's covered somewhere, but I couldn't find anything at MOS:PAREN. -- LCU ActivelyDisinterested«@» °∆t° 16:48, 1 April 2024 (UTC)[reply]
@ActivelyDisinterested: This is covered at Wikipedia:Manual of Style#Punctuation and footnotes. Once in a long while, there is minor dispute about this exact side point, and some editorial discretion is clearly tolerated in practice, though there's a pretty obviously logic to follow. Below, I've tweaked your example text for clarity, by putting distinct text in the parenthetical part. (However, Blah blah (yak)[1],... wouldn't be right, either way; rather: Blah blah (yak),[1]..., since superscripted footnotes always come after the comma, or semicolon, or period/full-point.)
My personal take on this, and what I seem to observe in frequent use, is to do Blah blah (yak),[1]... if the citation covers the entire parenthetical. In such a circumstance, Blah blah (yak[1]),... and Blah blah (yak),[1]... are actually logically equivalent, and a lot of editors prefer the appearance of the latter. Also use Blah blah (yak),[1]... if the citation covers both the parenthetical and the rest of the sentence that precedes it, obviously. When it doesn't, we'd be more expecting Blah blah[1] (yak[2]),... or Blah blah[1] (yak),[2].... But always do Blah blah (yakkety[1] yak[2]),..., or more fully Blah blah[1] (yakkety[2] yak[3]),..., any time the citation covers only part of the claim in the parenthetical.
That MoS section should probably be updated to say something like what I just did (but more concisely), to better reflect actual practice, and to not requireBlah blah (yak[1]),... in circumstances for which Blah blah (yak),[1]... is directly equivalent. — SMcCandlish ☏ ¢ 😼 18:57, 1 April 2024 (UTC)[reply]
Backlog update: The October drive reduced the article backlog from 11,626 to 7,609 and the redirect backlog from 16,985 to 6,431! Congratulations to Schminnte, who led with over 2,300 points.
Following that, New Page Patrol organized another backlog drive for articles in January 2024. The January drive started with 13,650 articles and reduced the backlog to 7,430 articles. Congratulations to JTtheOG, who achieved first place with 1,340 points in this drive.
Looking at the graph, it seems like backlog drives are one of the only things keeping the backlog under control. Another backlog drive is being planned for May. Feel free to participate in the May backlog drive planning discussion.
It's worth noting that both queues are gradually increasing again and are nearing 14,034 articles and 22,540 redirects. We encourage you to keep contributing, even if it's just a single patrol per day. Your support is greatly appreciated!
2023 Awards
Onel5969 won the 2023 cup with 17,761 article reviews last year - that's an average of nearly 50/day. There was one Platinum Award (10,000+ reviews), 2 Gold Awards (5000+ reviews), 6 Silver (2000+), 8 Bronze (1000+), 30 Iron (360+) and 70 more for the 100+ barnstar. Hey man im josh led on redirect reviews by clearing 36,175 of them. For the full details, see the Awards page and the Hall of Fame. Congratulations everyone for their efforts in reviewing!
WMF work on PageTriage: The WMF Moderator Tools team and volunteer software developers deployed the rewritten NewPagesFeed in October, and then gave the NewPagesFeed a slight visual facelift in November. This concludes most major work to Special:NewPagesFeed, and most major work by the WMF Moderator Tools team, who wrapped up their major work on PageTriage in October. The WMF Moderator Tools team and volunteer software developers will continue small work on PageTriage as time permits.
Recruitment: A couple of the coordinators have been inviting editors to become reviewers, via mass-messages to their talk pages. If you know someone who you'd think would make a good reviewer, then a personal invitation to them would be great. Additionally, if there are Wikiprojects that you are active on, then you can add a post there asking participants to join NPP. Please be careful not to double invite folks that have already been invited.
Reviewing tip: Reviewers who prefer to patrol new pages within their most familiar subjects can use the regularly updated NPP Browser tool.
Reminders:
You can access live chat with patrollers on the New Pages Patrol Discord.
Hola, recientemente actualicé Template:SfnRef/doc . Creo que mencionaste algo en la documentación sobre cuándo usar plantillas que forman paréntesis. En las partes que actualicé, solo usé las plantillas más comunes, {{ sfn }} y {{ harvnb }} . Por eso, quería invitarte a que hagas cualquier cambio o hagas cualquier pregunta. Rjj iii ( discusión ) 04:24 8 abr 2024 (UTC) [ responder ]
"Las plantillas más comunes" son las más comunes simplemente porque surgieron antes; usarlas en la mayoría de los artículos en realidad no cumple con WP:CITESTYLE porque difieren en estilo del resultado de las otras plantillas de citas, y se deben usar en su lugar, excepto en un artículo que use CS2 o algún otro medio para generar citas completas que no pongan las fechas entre paréntesis. — SMcCandlish ☏ ¢ 😼 18:10, 8 de abril de 2024 (UTC) [ responder ]{{sfnp}}{{harvp}}
Solicitud de comentarios: Solicitud de comentarios sobre política, gobierno y derecho
Nos vendría bien tu ayuda con 'what', 'which', 'to' (dos veces), 'in', ' froissés ' , ' déchirés ' , y 'like', y quizás ' papier ' , en Talk:Pero ¿qué pasa con el ruido... ? — BarrelProof ( discusión ) 01:17 12 abr 2024 (UTC) [ responder ]
Es un tema espinoso. Hice lo mejor que pude. — SMcCandlish ☏ ¢ 😼 06:12, 12 de abril de 2024 (UTC) [ responder ]
Categoría:Wikipedianos que rechazan una etiqueta de preferencia sexual ha sido nominada para su eliminación
Hecho
La categoría:Wikipedianos que rechazan una etiqueta de preferencia sexual ha sido nominada para su eliminación. Se está llevando a cabo una discusión para decidir si cumple con las pautas de categorización . Si desea participar en la discusión, está invitado a agregar sus comentarios en la entrada de la categoría en la página de categorías para discusión . Gracias. Marcocapelle ( discusión ) 06:41 12 abr 2024 (UTC) [ responder ]
¡Gracias por mejorar la calidad de los artículos en abril! -- Gerda Arendt ( discusión ) 13:32 20 abr 2024 (UTC) [ responder ]
Consejo
Dado que aquí has aportado algunos comentarios extensos sobre la conducta del usuario denunciado, me preguntaba qué sugieres sobre la recurrencia del comportamiento del artículo de la ciudad de Nueva York , como esta mordida de un nuevo usuario , y esta, que no fue mucho mejor. No quiero particularmente crear un nuevo ANI, pero lo haré si es necesario. Seasider53 ( discusión ) 00:14 22 abr 2024 (UTC) [ responder ]
El primero es un poco preocupante, ya que encaja con el patrón de propiedad del "club de los buenos muchachos" y el control del wikiproyecto evidenciado en el ANI original, una noción de que solo Castncoot y sus amigos cercanos en temas de actualidad tienen aportes que importan. El segundo no me parece problemático, ya que proporciona un razonamiento real sobre la calidad del contenido en cuestión. Soy escéptico de que esto sea suficiente para otro ANI, pero si se intensifica, entonces una prohibición de tema parece un resultado probable, dada la evidencia que yo y algunos otros proporcionamos antes, si hay buena evidencia de que el problema ha regresado, más allá de una diferencia única. — SMcCandlish ☏ ¢ 😼 03:32, 22 de abril de 2024 (UTC) [ responder ]
Formas de citación de verbos griegos
Un verbo griego antiguo que termina en "-izein" tiene la terminación de infinitivo, mientras que "-izo" muestra la terminación de la primera persona del singular del presente de indicativo. Los diccionarios tradicionales (Liddell y Scott, etc.) enumeran los verbos bajo la primera forma singular, mientras que para otros fines puede preferirse el infinitivo. No estoy seguro de que haya mucha diferencia. AnonMoos ( discusión ) 08:53 23 abr 2024 (UTC) [ responder ]
Entendido, pero la mayoría de los lectores no lo entenderán, y solo verán un conflicto entre lo que dice WP y lo que dice la fuente citada hasta ahora, por lo que parece que necesitamos dos fuentes, una con formas -izein y otra con formas -izo (o la fuente actual -izein y una que diga que son equivalentes). — SMcCandlish ☏ ¢ 😼 10:51, 23 de abril de 2024 (UTC) [ responder ]
Libros y Bytes – Número 62
La biblioteca de Wikipedia : Libros y bytes
, número 62, marzo-abril de 2024
IEEE y Haaretz ya están disponibles
Clínicas Conectémonos Acerca de la Biblioteca Wikipedia
Consejos sobre Spotlight y la biblioteca Wikipedia
Lea el boletín completo
Enviado por el servicio de entrega de mensajes de MediaWiki en nombre del equipo de la Biblioteca Wikipedia --11:03, 23 de abril de 2024 (UTC) [ responder ]
Solicitud de comentarios: Solicitud de comentarios sobre matemáticas, ciencias y tecnología
¡Buen día! Gracias por contribuir a Wikipedia escribiendo este artículo. He marcado el artículo como revisado. ¡Que tengas un día maravilloso y bendecido para ti y tu familia!
Para responder, deja un comentario aquí y comienza con {{Re|SunDawn}}. (Mensaje enviado a través de la herramienta de curación de páginas , en nombre del revisor).
Gracias. Me alegra ver que esa redirección finalmente se convirtió en un artículo que era WP:SPLIT del extenso Nithyananda , donde todo el contenido de Kailaasa se estaba convirtiendo en un WP:COATRACK . — SMcCandlish ☏ ¢ 😼 10:04, 1 de mayo de 2024 (UTC) [ responder ]
Recordatorio para votar ahora para seleccionar a los miembros del primer U4C
Hecho
Puedes encontrar este mensaje traducido a otros idiomas en Meta-wiki. Por favor, ayuda a traducirlo a otros idiomas.
Estimado Wikimedista:
Recibirá este mensaje porque anteriormente participó en el proceso UCoC.
Este es un recordatorio de que el período de votación para el Comité Coordinador del Código de Conducta Universal (U4C) finaliza el 9 de mayo de 2024. Lea la información en la página de votación en Meta-wiki para obtener más información sobre la votación y la elegibilidad de los votantes.
El Comité Coordinador del Código de Conducta Universal (U4C) es un grupo global dedicado a proporcionar una implementación equitativa y consistente del UCoC. Se invitó a los miembros de la comunidad a presentar sus solicitudes para el U4C. Para obtener más información y conocer las responsabilidades del U4C, consulte la Carta del U4C.
Por favor comparte este mensaje con los miembros de tu comunidad para que ellos también puedan participar.
En nombre del equipo del proyecto UCoC,
RamzyM (WMF) 23:10 2 may 2024 (UTC) [ responder ]
Solicitud de comentarios: Medios, artes y arquitectura solicitan comentarios
Hi, when you use {{cite AFM}} could you please also use {{sfn whitelist|CITEREFO'Donovan1856}} to prevent the false Category:Harv and Sfn no-target errors it causes? Thanks, DuncanHill (talk) 22:52, 13 May 2024 (UTC)[reply]
@DuncanHill: What would be causing that in the first place? It's set (now, correctly) with O'Donovan as author name and 1856 as date. I'm almost done fixing all the manual |John O'Donovan=|1856= stuff that had to be done the way the AFM template was formerly mis-coded (with |author= AKA |last= wrongly containing the entire author name). — SMcCandlish ☏ ¢ 😼 23:16, 13 May 2024 (UTC)[reply]
@DuncanHill: Ah, I see. It just needs to be explicitly whitelisted in Module:Footnotes, and I've made a request to this effect at Module talk:Footnotes#AFM. This template is used frequently enough that this would be better than requiring people to go around manually peppering articles with an {{sfn whitelist}} thing. — SMcCandlish ☏ ¢ 😼 23:37, 13 May 2024 (UTC)[reply]
Should get fixed soon-ish, though I have no control over how quickly the maintainers of the module act on such matters. As a template-editor, I could in theory just go do it, but I'm a wiki-template-language nerd, and can't really Lua my way out of a paper bag, so it's safer to let the Lua module experts deal with it. I noticed you adding the {{sfn whitelist}} template, but it seems like a lot of work to do and then later undo for a temporary display problem that doesn't actually even affect the citations' functionality.
Cuando intentas vaciar una categoría, es útil no tenerla medio llena de falsos positivos. Intento eliminar todas las adiciones a medida que aparecen en mi lista de seguimiento, además de revisar la lista. Cuando llego a un artículo y veo cuál es el problema, no lleva mucho más tiempo solucionarlo si solo necesita una lista blanca. DuncanHill ( discusión ) 23:58, 13 de mayo de 2024 (UTC) [ responder ]
Ah, sí, también tengo algunos flujos de trabajo como ese. :-) — SMcCandlish ☏ ¢ 😼 00:02, 14 de mayo de 2024 (UTC) [ responder ]
YGM
Hola, SMcCandlish. Por favor, revisa tu correo electrónico; ¡tienes un mensaje! Puede que pasen unos minutos desde el momento en que se envía el correo electrónico hasta que aparezca en tu bandeja de entrada. Puedes eliminar este aviso en cualquier momento eliminando la plantilla {{ Tienes un mensaje }} o {{ ygm }} .
Thank you for improving articles in May! - Today's story mentions a concert I loved to hear (DYK) and a piece I loved to sing in choir, 150 years old (OTD). --Gerda Arendt (talk) 15:58, 22 May 2024 (UTC)[reply]
How to use sfnp when there is more than one issue of a journal in the same year?
I've been cleaning up weak citations at Neoplasticism, which has the potential to be a GA. I've bumped up against the question of what to do when there is a need to cite more than one issue of a journal in the same year. The ideal would be {{sfnp|Smith|May 1924|page=123}} but that is interpreted as Smith & May 1924 p.123. I've kludged around it using ref={{sfnref to make 1924a, 1924b etc., but it is far from ideal: in context, Smith (May 1924) p.123 would be "nicer" and easier for inexperienced editors to use. Have I missed a trick or would it need a template enhancement? (If it would, whether it would be 'value for money' is a whole other question.) What do you think? 𝕁𝕄𝔽 (talk) 15:48, 23 May 2024 (UTC)[reply]
@JMF:{{sfnref}} is hardcoded to only accept date parameter input in the form YYYY or YYYYx, where x is a single letter. You can't even do YYYYxz. This whole "1924a" and "1924b" stuff is actually a poor idea (imported wholesale from one or another of the offsite citation styles, probably Chicago/Turabian, though I misremember). It's a poor idea on WP because it presumes that the sources will be listed in a and b order and that this order will never change, which is an assumption that cannot be depended upon in a wiki. The editor adding the material might have put them in backwards order, or some later editor might have moved them around, or another editor might have added a third source from same author and year that goes between the original a and b. It would actually be better for {{sfnref}} to support more specific date formats like Monthname YYYY, as you desire, though it would take some testing with a bunch of templates to ensure that the #CITEREF... anchor ouput this generated actually worked with everything like {{sfnp}} and {{harvp}}. For right now, the solution still actually is to do |ref={{sfnref|Smith|1924a}}. A more manual alternative would be to do |ref=Smith (May 1924), and do citations to this in the form <ref>[[#Smith (May 1924)|Smith (May 1924)]], p. 123.</ref>. There are articles in which I have done this a few times because of an important source author churning out several articles per year. If same page has to be cited more than once, then a ref name is needed, e.g.: <ref name="Smith (May 1924), p. 123">[[#Smith (May 1924)|Smith (May 1924)]], p. 123.</ref> and a later <ref name="Smith (May 1924), p. 123" />. Code-wise, it's a bit ugly, but for the end reader is much more sensible than "Smith (1924b), p. 123", especially since we cannot (per WP:REUSE) expect that every reuse of WP content will include a link between the "1924b" string and the intended specific citation. — SMcCandlish ☏ ¢ 😼 23:07, 23 May 2024 (UTC)[reply]
so even messier than I thought . I hadn't appreciated that the a and b suffixes are position dependent. Which <expletive deleted> thought that idea would survive contact with reality? (Rhetorical question.) 𝕁𝕄𝔽 (talk) 08:12, 24 May 2024 (UTC)[reply]
We've done a lot of stuff that tends to presume "links will always be there for the reader, and will work as the editor presently intends, and will be something the reader will reliably use", all of which are assumptions that can fail for particular use cases. In the grand scheme of things, though, it is probably higher priority to fix all the uncited claims and the claims that fail verification with the sources that are provided, than to resolve potential confusion between two or three of the same-author-and-year citations that are at least present and can be verified with slightly more effort than would ideally be required. — SMcCandlish ☏ ¢ 😼 08:45, 24 May 2024 (UTC)[reply]
Which is what I suspected when I wrote ... whether it would be 'value for money' is a whole other question.. "No further action at this time". --𝕁𝕄𝔽 (talk) 10:03, 24 May 2024 (UTC)[reply]
Feedback request: Politics, government, and law request for comment
Categoría:Los escritores y locutores de deportes de referencia han sido nominados para dividirse
Hecho
Categoría:Escritores y locutores de deportes de fondo ha sido nominada para su división. Se está llevando a cabo una discusión para decidir si cumple con las pautas de categorización . Si desea participar en la discusión, está invitado a agregar sus comentarios en la entrada de la categoría en la página de categorías para discusión . Gracias. Omnis Scientia ( discusión ) 23:01 30 may 2024 (UTC) [ responder ]
Categoría:Escritores y locutores de grupos ha sido nominada para un nuevo nombre. Se está llevando a cabo una discusión para decidir si cumple con las pautas de categorización . Si desea participar en la discusión, está invitado a agregar sus comentarios en la entrada de la categoría en la página de categorías para discusión . Gracias. Omnis Scientia ( discusión ) 23:03 30 may 2024 (UTC) [ responder ]
Categoría:Escritores y locutores de snooker ha sido nominada para dividirse. Se está llevando a cabo una discusión para decidir si cumple con las pautas de categorización . Si desea participar en la discusión, está invitado a agregar sus comentarios en la entrada de la categoría en la página de categorías para discusión . Gracias. Omnis Scientia ( discusión ) 23:03 30 may 2024 (UTC) [ responder ]
Solicitud de comentarios: Solicitud de comentarios sobre política, gobierno y derecho
Hola, ¿te parece bien que eliminen esta redirección [27] para dejar paso a un artículo que escribí sobre el tema: Borrador: Hipotiroidismo en perros , gracias? Traumnovelle ( discusión ) 22:33 8 jun 2024 (UTC) [ responder ]
@ Traumnovelle : Parece un buen plan. :-) — SMcCandlish ☏ ¢ 😼 23:55, 8 de junio de 2024 (UTC) [ responder ]
@ Traumnovelle : Me he olvidado fácilmente de dónde fue la redirección, pero recuerdo que era una sección. Esa sección probablemente podría necesitar una si no lo hiciste ya. — SMcCandlish ☏ ¢ 😼 10:07, 9 de junio de 2024 (UTC) [ responder ]{{Main|Hypothyroidism in dogs}}
Pasé a la lista de enfermedades de los perros, la agregaré ahora, gracias. Traumnovelle ( discusión ) 21:22 9 jun 2024 (UTC) [ responder ]
Ehhhhhhxcelente, como diría el señor Burns (juntando los dedos). — SMcCandlish ☏ ¢ 😼 04:46, 10 de junio de 2024 (UTC) [ responder ]
Solicitud de comentarios: Economía, comercio y empresas solicitan comentarios
Concepto de plantilla de Hatnote: about-distinguish-for
¡Hola, Gary Oldman Person! Recuerdo que una vez me ayudaste con una sangría de nota de sombrero de sección de Bette Davis. Esta es un poco diferente, ya que se trata de una consulta sobre una nota de sombrero de primera página (perdónenme o corríjanme si la terminología es incorrecta).
Entonces, con algunas cosas con títulos similares, creo que hay casos en los que simplemente About-For, Distinguish-For, etc., etc. funcionan bien, o incluso solo About, For, Distinguish, etc. También existe Redirect-Distinguish-For, que he usado al menos una vez. Pero no puedo entender exactamente por qué no hay un About-Distinguish-For. Sé que he editado algunos recientemente en los que sentí que era la mejor opción, pero me di cuenta de que no existe. Siento que es lo suficientemente cercano a Redirect-Distinguish-For como para que valga la pena formatearlo para su uso. Usar dos notas de sombrero separadas, en las que la segunda termina creando un salto de línea/segunda línea sin ninguna razón, no es bueno.
Solo para un pequeño ejemplo, no el mejor, usemos esta película independiente, Departure (2015). Esbozo, necesita trabajo. Pero sobre "película de 2015". No debe confundirse con película de 2008. Para otras películas con el mismo título, consulte Departure (desambiguación) § Películas . Simplemente pretenda que son películas más grandes, si es necesario. Primero es identificar o aclarar el artículo, en lugar de lo que los redirigió allí. Segundo, este título alternativo en particular que podría causar confusión es el MÁS notable que vale la pena destacar para distinguirlo, porque es el ganador del Oscar en idioma extranjero. Y por último, la desambiguación no es solo salidas generales, sino una lista de algunas otras películas de varios años que también se titulan Departure (en alguna variación ortográfica/gramatical). ¡Si es necesario, reemplácelos con cualquier nombre principal/secundario/otro nombre popular de sustantivos!
Pensé que podría haber alguna manera de manipular la plantilla dentro de la plantilla, para insertar {For} dentro de un tipo de texto personalizado About-Distinguish. No lo sé. Pero, por desgracia, ahí es donde estoy y parece que tengo problemas para articular la necesidad, en mi opinión, por un lado. -- Cinemaniac86 Talk Stalk 05:00, 18 de junio de 2024 (UTC) [ responder ]
@Cinemaniac86: Okay, so we have Departure (disambiguation)#Films, and Departure (2015 film), and 3 other films by the same name (4 counting a film better known by an alternative title), and 10 total counting The Departure and plural Departures variants (but apparently no The Departures).
In this case, I would simply use {{For|other films with the same title|Departure (disambiguation)#Films}}. I really can't see a good rationale for {{About-distinguish|the 2015 film|Departures (2008 film)}}, since neither the title nor the year are a match, and there is no actual reason to try to single out any other movie at all (award or no) among such a number of films. Anyone who is so aware of the details of obscure Oscars categories is already going to know it was a 2008 Best Foreign Film winner not a 2015 winner. I.e., there is far more confusion potential with Departure (1931 film), Departure (1938 film), and Departure (1986 film). Anyone who just encountered a "I really recommend the film Departure" or something will not know which it is, especially if it was in a context like a film class or some other venue that was not wholly focused on recent releases. If The Departure (2015 film) or a Departures (2015 film) also existed (or something like "Chicken Nuggets of Doom, a 2015 Elbonian film re-titled Departure in some markets"), those would also be very likely confusion candidates.
But there are already too many to call them out specifically in a hatnote. {{For|other films with the same or similar titles|Departure (disambiguation)#Films}} is really what is needed (without any other DAB hatnote). And while it doesn't apply to this specific obscure indy film, for many films there could also be a directly related soundtrack album, novel, video game, sequel, earlier or remake film version, derived TV series, overall franchise article, or something else to disambiguate from the 2015 (or whatever year) film.
Maybe there could be a use case for a {{About-distinguish-for}}, I don't think Departure (2015 film) is that use case. And while it would be easy to create such a template, if it does not see [appropriate] use, it will just get deleted at WP:TFD. Wikipedia's been disambiguating things for 23+ years, and has done so fine without such a template, so it's unlikely to prove useful. It's important to remember that these hatnotes exist only to help readers be sure they have arrived at the right article when they just guess at a title, or click on something that provides the title but insufficent context for that person to positively identify it among the alternatives. A purpose they do not serve is trying to "educate" or PoV-sway readers with an editorial opinion about what is most popular or important or notable among things with kinda-similar names from different time periods. — SMcCandlish ☏ ¢ 😼 22:04, 20 June 2024 (UTC)[reply]
June thanks
Thank you for improving article quality in June! - Today we have a centenarian story (documentation about it by Percy Adlon) and an article that had two sentences yesterday and was up for deletion, and needs a few more citations. -- Gerda Arendt (talk) 14:01, 20 June 2024 (UTC)[reply]
Inconsistent link-appearance behavior
Hey SMcCandlish, I'm fixing {{Xtn}}'s appearance in dark mode, and I'm not sure I understand the hidden comment left there. Does {{Xtn/sandbox}} work? Snowmanonahoe (talk ·contribs·typos) 17:52, 7 July 2024 (UTC)[reply]
@Snowmanonahoe: Well, the HTML comment seems to indicate that without color: initial, various of these xt-family of templates do not have consistent link-coloring behavior. As for dark mode, I'm not sure which dark mode you mean. I don't see a "dark mode" option in the desktop version (in Vector Legacy, which is what I use). Regardless, this CSS stuff would probably be better moved to a TemplateStyles page at this point. — SMcCandlish ☏ ¢ 😼 02:17, 8 July 2024 (UTC)[reply]
See mw:Reading/Web/Accessibility for reading/Updates/2024-04 for more information on dark mode. It's not on Vector legacy. As for the hidden comment, the part I don't understand is what "consistent link-coloring behavior" means. Snowmanonahoe (talk ·contribs·typos) 03:13, 8 July 2024 (UTC)[reply]
Not sure what's unclear about it. It means links will not be colored consistently. At this distant a remove, I'm not certain under what conditions that problem arose (i.e. whether it was consistently between templates in that group, or consistently from context to context using the same template). But it did arise, and thus the fix was implemented.
I would think the thing to do would be to have color: initial applied by default, and override it selectively for particular conditions in which whatever custom result you want to apply under those particular conditions has been well-tested.
I'm highly skeptical that a specific color such as color: black should ever be set, since it incorrectly presupposes that the conditions of the surrounding block will be known at all times and will be consistent from one context to another, which is not correct (though when it is wrong will probably not be very often). While we can be certain that general running text in an article is going to look a particular way, we have no way to predict what a particular templated condition is going to look like (various templates colorize blocks of text as to background, text color, or both). And these xt-type templates aren't for article text anyway, but generally for use in internal documentation.
When initial is assigned to a non-inherited propery, like display, it defaults to the CSS spec's default. When initial is assigned to an inherited property like color, it inherits the value most recently defined for that context in the stylesheet stack (if there is one, otherwise it gets the CSS-spec default or perhaps the browser default, if they different, and depending on the browser). There must have been a specific reason that both unset and inherit were not getting the job done properly in this case, but I wouldn't recall what the specifics were after so long. — SMcCandlish ☏ ¢ 😼 13:12, 8 July 2024 (UTC)[reply]
Help:Searching
Hi, I asked about this in the talk page, but no one answered - seeing as you're the one who wrote the original clarification of All: vs all: could you please give that talk section a read? I'd have requested an edit to the page, but I'd rather someone else confirm first. – 2804:F14:809B:301:18CD:9D72:3518:7DDA (talk) 19:21, 7 July 2024 (UTC)[reply]
I tried that name based on the pattern of {{redirect-distinguish}} and {{redirect-distinguish-for}}. I was surprised that it wasn't correct and it took me a while to realize that the template I was looking for was named simply {{redirect}}.
I'm asking because it looks like you were involved in deleting a previous page at that name, and I'm not familiar with the context in which you made that decision. Jruderman (talk) 13:00, 23 July 2024 (UTC)[reply]
@Jruderman: I answered this earlier (several days ago) but for some reason the reply didn't save. Anyway, I can't see a problem with {{redirect-for}} redirecting to {{redirect}}. However, also create a {{redirect for}} version, since the hyphenation in the original is actually ungrammatical, and we've been steadily moving away from template names with unnecessary hyphens in them, for several years now. That is, it's much more likely for someone to take a blind guess at "redirect for" than "readirect-for", the latter of which doesn't actually make sense in English. If you go to the store for cookies you don't "go-to the store-for cookies". — SMcCandlish ☏ ¢ 😼 18:06, 26 July 2024 (UTC)[reply]
I think you'd be great: you have a background in IT, you know your way around policy-based and non-policy-based arguments, you have a sense for what's good procedure, you have the page-mover right that lets you move articles without breaking their talk-page archives, and you haven't commented yet.
It's been a bit less than 7 days, but we've had lots of participation and I'd really like Wikipedia to have a good title for this current event. Jruderman (talk) 07:10, 25 July 2024 (UTC)[reply]
In theory; just a matter of whether I'm around at the right time, I guess. RMs usually do run for 7 days, though with the structure of this one being unusual, a little longer wouldn't hurt. — SMcCandlish ☏ ¢ 😼 07:41, 25 July 2024 (UTC)[reply]
Update: Commentary is still coming in, within the current day (as of this posting). Will try to remember to look again tomorrow. It's been over the requisite 7 days since the RM was opened but obviously less than that with regard to the "Motion to conclude" subthread, so better to let it run for a while. — SMcCandlish ☏ ¢ 😼 18:00, 26 July 2024 (UTC)[reply]
Thank you for keeping an eye on this. I agree that it isn't quite time. Jruderman (talk) 19:51, 26 July 2024 (UTC)[reply]
We might be ready now, finally, after two weeks. Thanks in part to you and @Soni: for pushing us to reset a week ago. Jruderman (talk) 21:35, 7 August 2024 (UTC)[reply]
Okay, I will start poring over it. — SMcCandlish ☏ ¢ 😼 22:50, 7 August 2024 (UTC)[reply]
Closed, and with considerable analysis. There's clearly not a "this is the name we should move to" consensus yet, but enough questions involved do have a consensus that the list of possibilities can be sharply narrowed for round 3. — SMcCandlish ☏ ¢ 😼 02:18, 8 August 2024 (UTC)[reply]
You're a true consensus shepherd. Please join the "Believing True Things (on Wikipedia)" Discord server. You've earned your WikiStar. Jruderman (talk) 04:58, 8 August 2024 (UTC)[reply]
Thanks, but I'll have to pass. I have no patience for live/interruptive e-media. I've tried that stuff since all the way back in the IRC and ICQ days, and it just drives me nuts, so I don't use Discord or anything like it, unless I have to for some client-related business reason, and even that's going to be curtailed. — SMcCandlish ☏ ¢ 😼 11:54, 8 August 2024 (UTC)[reply]
For the third round, would it be acceptable to propose a rename to "2024 CrowdStrike-related Windows system outages", or should we stick with open-ended? I think that one has widespread support but it's only been on the table for one or two days. What do you see as the top candidates or top open questions requiring consensus? Jruderman (talk) 12:41, 8 August 2024 (UTC)[reply]
I wouldn't do a one-option RM in this case again, unless and until source research has been done that establishes some particular phrase as the most common. Frankly, that kind of tedious trawling through sources is what needs to happen first and foremost, to see whether such a most-common phrase has emerged. If it has not, then my general sense is that options along the lines "2024 Crowdstrike IT outages" or "2024 Crowdstrike system outages" are most likely to gain consensus. Options like "2024 Crowdstrike IT system outages" are somewhat redundant. "2024 Crowdstrike-[something] IT outages" were seen as long-winded and were often contentious (especially "-triggered" or "-caused", less so "-related", but it was objected to as wishywashy or too vague to be very meaningful). And options that include "Windows", "Microsoft", or "Azure", or a more specific date, did not have much support and in several cases some direct opposition. But if it came to a scenario where still no common name can be determined, then a list that includes most such options would be hard to fault, and would mostly prevent the problem of people injecting their own variants yet again and confusing matters too much to assess a clear consensus. Just list and number (or letter) all the plausible ones and see which emerges with the most support and most sensible reasoning in support of it. — SMcCandlish ☏ ¢ 😼 07:33, 9 August 2024 (UTC)[reply]
This is a good comment, want to add it to the main discussion as an Involved editor? Jruderman (talk) 14:59, 9 August 2024 (UTC)[reply]
I've already added a pointer to it at the article talk page, and I'm not an "Involved" editor; that's kind of the point. I'm an uninvolved closer who's made some particular recommendations for moving forward in a way that's likely to attain a consensus instead of a round 4, round 5, etc. — SMcCandlish ☏ ¢ 😼 02:35, 10 August 2024 (UTC)[reply]
– It's launched, I signed up for it, and I've started providing some bibliographical references. — SMcCandlish ☏ ¢ 😼 22:52, 7 August 2024 (UTC)[reply]
Hi, I see you're a member of WP:Anthropology, would you be interested in joining a sub project on oral tradition? Kowal2701 (talk) 13:57, 26 July 2024 (UTC)[reply]
A taskforce/workgroup about that would be a good idea probably. It's not a subfield in which I do a whole lot of reading, but I have some interest in it particularly with regard to Gaelic and broader Celtic folklore, as well as modern Internet memetics as a folkloric subject. — SMcCandlish ☏ ¢ 😼 17:56, 26 July 2024 (UTC)[reply]
Yeah, personally I'm most interested in African traditional oral history, I'd recommend Jan Vansina's Oral tradition as history [28] Kowal2701 (talk) 18:02, 26 July 2024 (UTC)[reply]
I have that one in my e-book pile, though haven't gotten around to it yet. — SMcCandlish ☏ ¢ 😼 18:10, 26 July 2024 (UTC)[reply]
It might make sense to merge the bibliography and ‘sources for people interested but unfamiliar’ sections, although I really like the way you’re formatting it Kowal2701 (talk) 08:33, 9 August 2024 (UTC)[reply]
@Kowal2701: Yep, already working on it. I didn't notice the sectional redundancy until just after that edit. I'm merging them, and fleshing out the citations with {{cite book}}, etc., so they are easily re-usable in articles. — SMcCandlish ☏ ¢ 😼 08:49, 9 August 2024 (UTC)[reply]
Sounds good Kowal2701 (talk) 09:24, 9 August 2024 (UTC)[reply]
Done. A bit tedious, but it may prove helpful, especially given the number of workgroup participants with interest in the areas covered by those bibliography entries (esp. Africa, but I saw someone specifically mention Homeric, too). — SMcCandlish ☏ ¢ 😼 12:12, 9 August 2024 (UTC)[reply]
yeah I've messaged loads of people and a few said they're interested but not knowledgeable enough about it, and it'll be good for newcomers to wikipedia when they browse wikiprojects for the first time Kowal2701 (talk) 12:38, 9 August 2024 (UTC)[reply]
Nina Dobrev has an RfC
Done
Nina Dobrev has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Anthony Whitaker (talk) 10:22, 5 August 2024 (UTC)[reply]
Happy First Edit Day!
Nitpicky
About this edit summary: There's only one Clause in that sentence. Whether we should put a comma between the Phrases "a correct name for A, B, and C" and "or a valid name for D and E" probably depends less on rules and more on our best guess at whether people might misread the phrases as "a correct name for A, B" and "[either] C or a valid name for D and E". WhatamIdoing (talk) 17:54, 12 August 2024 (UTC)[reply]
Yes, I was using "clause" in the vague sense, as a shorthand, not being linguistically precise. They are really distinct complex items in a two-item list (item 1 is "a correct name for plants, fungi, and algae" and item 2 is "a valid name for animals and protozoa". Given that one of these items contains its own internal commas, an argument would actually be sensible for a semicolon between them, but a comma seems to suffice. No punctuation at all does not suffice, as it results in amibiguity which may be confusing and require the reader to stop, re-read the sentence, and consider how to to parse it to arrive at a sensible (and the probably intended) meaning. This stoppage is more likely for someone not already deeply familiar with the terms and their referents, but we have to assume that the average reader of any guideline here is not a subject-matter expert. — SMcCandlish ☏ ¢ 😼 02:10, 14 August 2024 (UTC)[reply]
If it weren't such a short section, I'd suggest a two-item bulleted list. WhatamIdoing (talk) 02:22, 14 August 2024 (UTC)[reply]
Wouldn't mind. A two-item bullet list can actually be helpful as a form of emphasis, and perhaps these two criteria really should be emphasized as elements of some precision. — SMcCandlish ☏ ¢ 😼 03:19, 14 August 2024 (UTC)[reply]
I'm trying to avoid any changes at all to that page until the RFC is settled. But perhaps next month, assuming it gets adopted, we'll make that formatting change. (If it doesn't get adopted, then we'll have to think about whether to preserve it in its {{historical}} state or to re-write it.) WhatamIdoing (talk) 04:58, 14 August 2024 (UTC)[reply]
(Confused) That doesn't sound like you. VanIsaac, GHTV contWpWS 05:15, 14 August 2024 (UTC)[reply]
Well, I'm generally not one to change a text (meaningfully) that is under active discussion. While adding a comma for clarity isn't likely to arouse objection, reformatting stuff into a list might, so holding off on it seems reasonable. More broadly, much of what I do around here is preventing and defusing chaos. I tend not to run away from the chaos, but dump cold water on it. — SMcCandlish ☏ ¢ 😼 11:25, 14 August 2024 (UTC)[reply]
Oral tradition taskforce
I notice that you are a template editor, in the very old days I used to request help from John Carter and or Tim! both long gone, I was wondering if you could cast your gaze over the Oral tradition taskforce categories that frame the project. It would be appreciated. I think that I totally dont get the mix with the literature project at the same time, but then the whole thing seems fraught these days...
Any help would be appreciated - even if I got it totally wrong for that matter. JarrahTree 13:46, 15 August 2024 (UTC)[reply]
Discussion at Wikipedia talk:Content forks § Where was the WikiProject process fork move review and RfC?
El artículo se discutirá en Wikipedia:Artículos para eliminar/Rojo (insulto) hasta que se llegue a un consenso, y cualquier persona, incluido usted, es bienvenida a contribuir a la discusión. La nominación explicará las políticas y pautas que son motivo de preocupación. La discusión se centra en evidencia de alta calidad y en nuestras políticas y pautas.
Los usuarios pueden editar el artículo durante la discusión, incluso para mejorarlo y abordar las inquietudes planteadas en la discusión. Sin embargo, no elimine el aviso de eliminación del artículo de la parte superior del artículo hasta que la discusión haya finalizado.
– sgeureka t • c 08:20, 20 de agosto de 2024 (UTC) [ responder ]
agosto gracias
¡Gracias por mejorar la calidad de los artículos en agosto! -- Gerda Arendt ( discusión ) 19:43 20 ago 2024 (UTC) [ responder ]
Capitalización consistente de los descriptores raciales "negro" y "blanco"
Según tu comentario aquí :
Existe un consenso en contra de escribir "negro" con mayúscula y "blanco" con minúscula.
Y discusiones anteriores como ésta :
Consenso contra el cambio de MOSCAPS para escribir "negro" con mayúscula cuando se utiliza como descriptor racial o étnico.
Lo pensaré. A la gente le gusta discutir y pelearse por estas cosas, y mi tolerancia al "drama" es baja en este momento. Pero sí, tiene que ser "blanco y negro" o "blanco y negro", pero no "blanco y negro" y ciertamente no "blanco y negro". Me inclinaría por la opción de capitalización uniforme, ya que estos sirven como etnónimos (una forma de nombre propio), y es menos discordante en una larga cadena de ellos tenerlos todos en mayúscula que tener uno o dos en minúscula como para denigrarlos (por ejemplo: "demografía de asiáticos orientales, hispanos, negros, del sur de Asia, del Pacífico y austronesios, blancos, semíticos y nativos americanos..."). — SMcCandlish ☏ ¢ 😼 23:50, 25 de agosto de 2024 (UTC) [ responder ]
Nuevas páginas patrullan el retraso de septiembre de 2024
@ BarrelProof : Me parece que sí, ya que es como "la frontera México-Guatemala" y "estudio interdisciplinario de arqueología-ecología": una relación entre dos cosas independientes/iguales. Un vehículo de gas y electricidad tiene dos fuentes de energía independientes, y no existe algo como "gas[-]electricidad" como término unitario pero de varias palabras (como "electricidad estática") que se podría escribir con un guión como modificador compuesto ("una descarga estática-eléctrica"). — SMcCandlish ☏ ¢ 😼 03:57, 28 de agosto de 2024 (UTC) [ responder ]
La biblioteca de Wikipedia : Libros y bytes
, número 64, julio-agosto de 2024
El Grupo Hindú se une a la Biblioteca Wikipedia
Presentación de Wikimanía
Nuevo script de usuario para buscar fácilmente en la biblioteca de Wikipedia
Lea el boletín completo
Enviado por el equipo de entrega de mensajes de MediaWiki en nombre del equipo de la Biblioteca Wikipedia --16:34, 11 de septiembre de 2024 (UTC) [ responder ]
Solicitud de comentarios: Solicitud de comentarios sobre política, gobierno y derecho
¡Gracias por mejorar los artículos de octubre! - Mi historia de hoy es una cantata de 300 años de antigüedad, basada en un himno de 200 años de antigüedad cuando se compuso la cantata, basada en un salmo de unos mil años de antigüedad, - así decía el estribillo de DYK de 2015. Había olvidado la discusión sobre la charla. -- Gerda Arendt ( discusión ) 16:11 20 oct 2024 (UTC) [ responder ]
La plantilla de fusión/discusión propuesta que agregaste a WP:V
Hola, en diciembre de 2023, añadiste una plantilla de fusión propuesta a la sección ABOUTSELF de WP:V y enlazaste a una discusión en la página de Discusión. Tenía curiosidad por la discusión, así que hice clic en el enlace para leerlo, recibí un mensaje en la página de Discusión que decía que no se podía encontrar el tema y luego lo encontré en los archivos. Me pregunto si esa plantilla de fusión debería eliminarse en este momento, pero no soy un editor con mucha experiencia, así que dudo en editar una página de políticas y pensé que en su lugar te consultaría. Dado que el tema te interesa, también señalaré que, en respuesta a una pregunta que hice en la Casa de Té, Pigsonthewing agregó texto a la sección BLPSPS correspondiente señalando que "No se refiere a una organización respetable que publique material sobre a quién emplea o a quién y por qué otorga premios, por ejemplo". Gracias, FactOrOpinion ( discusión ) 19:00, 23 de octubre de 2024 (UTC) [ responder ]
La fusión claramente necesita consenso para realizarse, y debería realizarse. Personalmente, me alejé de ella debido al comportamiento de un solo editor que se negó a ceder en un tema que le molestaba, pero este problema interpersonal no debería retrasar la fusión de estas secciones de políticas redundantes (tres de ellas, en realidad, no dos). Dado el nivel de búsqueda de detalles sobre cada palabra de ese material de políticas, soy escéptico de que la adición no discutida de Pigsonthewing sobreviva al escrutinio del consenso. Parece demasiado específica, como algo que estaría en una lista de ejemplos en una guía o ensayo, y no es una redacción de políticas. — SMcCandlish ☏ ¢ 😼 01:44, 24 de octubre de 2024 (UTC) [ responder ]
Everyone involved in the merge discussion walked away from it many months ago, so it's not clear to me that someone will now act on it. Should the Discuss link at least be updated so that it links to the archived discussion? Re: Pigsonthewing's addition, no doubt the wording could be improved, but I hope that consensus could be achieved for some related text. (It was intended to clarify the BLPSPS statement "Never use self-published sources ... as sources of material about a living person, unless written or published by the subject of the article," which I'd asked about in the context of a WP article about a notable academic, as I'd thought that policy meant that I couldn't use a self-published statement from a professional society about an award it gave.) FactOrOpinion (talk) 15:50, 24 October 2024 (UTC)[reply]
Yes, the link in the tag should be updated. I might work up the drama stomach to just re-open the discussion, or even just WP:BOLDly do the merge and conforming revision and see whether I get reverted by the same lone hold-out. But I have a lot going on right now. As for Potw's material and the issue you and he were trying to solve with it, the real solution is rewriting the BLP-specific material entirely to be more clear, instead of leaving unclear wording in place, and tacking on explanatory exceptions, which will simply grow in number as needs for exception to the poorly worded original material arise. It likely that the revision already covered by the merge discussion would obviate this problem anyway. — SMcCandlish ☏ ¢ 😼 16:11, 24 October 2024 (UTC)[reply]
OK, I've updated the Discuss link. No rush on however you choose to follow up. If you do reopen the discussion, I may chime in about how the proposed text reads to someone who isn't as experienced and is trying to make sense of and abide by policies. FactOrOpinion (talk) 18:09, 24 October 2024 (UTC)[reply]
Curious what it is now. — SMcCandlish ☏ ¢ 😼 18:10, 24 October 2024 (UTC)[reply]
This comment focuses on draft #3 but also applies to the existing version of the WP:V page. In point 1, I wondered whether "The material" refers to the material added to the WP page or to the source material, and similarly for "It" at the beginning of points 2 and 3. I'm pretty sure that standard grammar says that the referent is the SPS, and that's clearly the intended referent of "its" in point 4. But I question that interpretation, as it surprises me that there would be so many constraints on the contents of the source material, whereas the constraints make more sense to me as restrictions on material added to the WP article and the BLP footnote implies that the source material can contain a statement about third parties as long as it isn't introduced into the article using that source. So that's a long explanation for: I'd clarify the meaning of "The material" / "It." I've also sometimes wondered if my judgment about what constitutes "unduly self-serving" is OK, but I doubt that that can be easily defined, so I'll trust my judgment and hope that if it's off, someone else will remove what I added.
Re: whether the revision obviates the problem I mentioned, I don't think it does, as my concern was really about the text of BLPSPS, not the text of BLPSELFPUB. BTW, I noticed that someone removed the merge template from the BLP page, so if you do reopen the discussion, you may want to reintroduce it there. FactOrOpinion (talk) 00:16, 25 October 2024 (UTC)[reply]
The referents clarity issue is probably easily soluble. But "unduly self-serving" is typical "leave it to an editorial consensus on a case-by-case basis" WP wording. Changing that to some kind of bright-line test of some time would be a very substantive alteration and entail a great deal of new debate. — SMcCandlish ☏ ¢ 😼 00:28, 25 October 2024 (UTC)[reply]
Invitation to participate in a research
Done
Hello,
The Wikimedia Foundation is conducting a survey of Wikipedians to better understand what draws administrators to contribute to Wikipedia, and what affects administrator retention. We will use this research to improve experiences for Wikipedians, and address common problems and needs. We have identified you as a good candidate for this research, and would greatly appreciate your participation in this anonymous survey.
You do not have to be an Administrator to participate.
The survey should take around 10-15 minutes to complete. You may read more about the study on its Meta page and view its privacy statement .
Please find our contact on the project Meta page if you have any questions or concerns.
Gracias por tus comentarios, pero solo para aclarar, lo que está en juego es la línea de nacionalidad en el cuadro de información. El artículo contradice tu aparente conclusión. Travelmite ( discusión ) 10:05 25 oct 2024 (UTC) [ responder ]
Cambios de administrador
Comprobar cambios de usuario
Novedades sobre directrices y políticas
Arbitraje
Misceláneas
Irresoluto
Hecho
— Mudwater (Talk) 01:45, 22 February 2024 (UTC)
The redirect Template:R from project has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 February 20 § Template:R from project until a consensus is reached. —a smart kitten[meow] 00:16, 20 February 2024 (UTC)
Template:Blockquote paragraphs has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Gonnym (talk) 12:40, 20 February 2024 (UTC)
Actualmente hay una discusión en Wikipedia:Tablón de anuncios de administradores sobre un problema en el que puede que hayas estado involucrado. Gracias. Jessintime ( discusión ) 19:20 21 feb 2024 (UTC) 
Indiferencia
is a whole other question.) What do you think? 𝕁𝕄𝔽 (talk) 15:48, 23 May 2024 (UTC)
. I hadn't appreciated that the a and b suffixes are position dependent. Which <expletive deleted> thought that idea would survive contact with reality? (Rhetorical question.) 𝕁𝕄𝔽 (talk) 08:12, 24 May 2024 (UTC)is a whole other question.
You are invited to join the discussion at Wikipedia talk:Content forks § Where was the WikiProject process fork move review and RfC?. 142.113.140.146 (talk) 15:21, 18 August 2024 (UTC)