De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Plantillas de citas
... y en realidad

asin & isbn [ editar ]

|asin=acepta números de 10 dígitos que pueden ser ISBN de 10 dígitos o números de 10 dígitos que comienzan con 630 o 631 que no son (actualmente) ISBN pero son ASIN. Tenemos Categoría: CS1 maint: ASIN usa ISBN donde realizamos un seguimiento |asin=con un valor numérico que probablemente sea un ISBN; el número se verifica como un ISBN numéricamente válido.

He modificado el Módulo: Citación / CS1 / Identificadores / caja de arena para que emita mensajes de error (rojo) cuando |asin=tiene un valor numérico asignado que no comienza con 630 o 631. Además, he modificado el código de validación ISBN-10 para que emite un mensaje de error cuando |isbn=tiene un valor asignado que comienza con 630 o 631 (probablemente un ASIN):

Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin=412346789X}}
VivirTítulo . ASIN  412346789X Comprobar |asin=valor ( ayuda ) .
SalvaderaTítulo . ASIN  412346789X Comprobar |asin=valor ( ayuda ) .
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin=6305277001}}
VivirTítulo . ASIN  6305277001 .
SalvaderaTítulo . ASIN  6305277001 .
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin=6317484546}}
VivirTítulo . ASIN  6317484546 .
SalvaderaTítulo . ASIN  6317484546 .
Comparación de libros de citas
Wikitexto{{cite book |title=Title |isbn=412346789X}}
VivirTítulo . ISBN 412346789X.
SalvaderaTítulo . ISBN 412346789X.
Comparación de libros de citas
Wikitexto{{cite book |title=Title |isbn=6305277001}}
VivirTítulo . ISBN 6305277001Compruebe el |isbn=valor: ID de grupo no válido ( ayuda ) .
SalvaderaTítulo . ISBN 6305277001Compruebe el |isbn=valor: ID de grupo no válido ( ayuda ) .
Comparación de libros de citas
Wikitexto{{cite book |title=Title |isbn=6317484546}}
VivirTítulo . ISBN 6317484546Compruebe el |isbn=valor: ID de grupo no válido ( ayuda ) .
SalvaderaTítulo . ISBN 6317484546Compruebe el |isbn=valor: ID de grupo no válido ( ayuda ) .

Si se acepta, la Categoría: CS1 maint: ASIN usa ISBN desaparecerá; estos errores asin categorizan en Categoría: errores CS1: ASIN . El mensaje de error para |isbn=63[0|1].......reutilizar un suplemento de mensaje de error existente actualmente solo se usa para errores de identificación de grupo ISBN-13 / ISMN.

- Trapense el monje ( charla ) 20:42, 24 de enero de 2021 (UTC)

No veo por qué no sería aceptado. Parece no controvertido e intuitivo. 98.0.246.242 ( conversación ) 21:09, 24 de enero de 2021 (UTC)
A mí también me parece bien.
Hablando de ASIN, actualmente no generamos datos COinS para ASIN y OL porque primero necesitaríamos comunicar la información del TLD ASIN y el tipo OL A / M / W / X al módulo COinS. Hace algunos meses, estaba en el proceso de idear alguna forma de cómo lograr esto con cambios mínimos, pero dado que la organización interna se cambió considerablemente recientemente y usted está más familiarizado con ella, le agradecería si pudiera echarle un vistazo a esto por un probable solución más general.
- Matthiaspaul ( charla ) 22:19, 24 de enero de 2021 (UTC)
Quizás tenga una solución. Si asin()obtiene un puntero ID_list_coins_t{}en Module: Citation / CS1 / Identifiers / sandbox , asin()puede sobrescribir el identificador simple con una URL correctamente ensamblada. Si también cambiamos id_handlers['ASIN']['COinS']a algo distinto nilen el Módulo: / Configuración Cita / CS1 / caja de arena , Módulo: Cita / CS1 / Monedas / caja de arena utilizará ese valor (la URL) en un &rft_id=atributo:
{{cite book/new |title=Title |asin=6305277001}}
Título . ASIN  6305277001 .
'"`UNIQ--templatestyles-0000002C-QINU`"'<cite class="citation book cs1">''Title''. [[ASIN (identifier)|ASIN]]&nbsp;[//www.amazon.com/dp/6305277001 6305277001].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=%2F%2Fwww.amazon.com%2Fdp%2F6305277001%23id-name%3DASIN&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
Supongo que este mismo esquema también funcionará |OL=. Además, con un pequeño ajuste, sobrescriba un valor de identificador simple erróneo con nil(cada función de identificador en ~ / Identifiers / sandbox), y un pequeño ajuste en ~ / COinS / sandbox para que pueda detectar nilvalores de identificador, evitar identificadores erróneos de entrar en los metadatos.
- Trapense el monje ( charla ) 17:54, 26 de enero de 2021 (UTC)
Perdón por la larga demora, trapense, solo ahora encontré el momento de echar un vistazo a la solución propuesta. Me parece bien, gracias.
También es deseable obtener algunos medios para suprimir la generación de metadatos para identificadores erróneos.
- Matthiaspaul ( charla ) 12:49, 28 de febrero de 2021 (UTC)
He pirateado el módulo: Citation / CS1 / Identifiers / sandbox para suprimir la generación de metadatos para identificadores erróneos. Los valores de los identificadores que el apoyo Accept-as-escrito de marcas ( |doi=, |isbn=, |eissn=, y |issn=) se incluyen en los metadatos si se ha hecho lo que independientemente de validez. |sbn=admite el marcado de aceptación como está escrito, pero no se incluye (nunca se ha incluido) en los metadatos porque no creamos una URL para él, porque rft.sbnno es una clave definida por COinS y porque sbnno está registrada en info-uri.info (para el info:esquema URI ).
Este cambio rompe casi todos los casos de prueba en la charla del módulo: Cita / CS1 / casos de prueba / identificadores . |sbn=no está roto porque no se crean metadatos para ese parámetro. Descubrí un error de larga data en Module: Citation / CS1 / Configuration / sandbox for |ismn=. La id_handlers['ISMN'].COinSasignación era 'nil', una cadena, cuando debería ser nil, el tipo de datos (representa la ausencia de un valor). Eso estaba provocando que el conjunto de módulos agregara un par k / v con formato incorrecto a los metadatos para las citas que usan . Arreglo que rompe todos los casos de prueba.rft_id=<ismn value>|ismn=ismn
- Trapense el monje ( charla ) 21:01, 9 de marzo de 2021 (UTC)
Ahora veo algunos mensajes de error falsos que no reconocí hace dos meses, por lo tanto, asumo que este es un nuevo problema posiblemente causado por los cambios anteriores:
  • Sin ASIN, TLD no válido:
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin-tld=xy}}
VivirTítulo . |asin-tld=requiere |asin=( ayuda )
SalvaderaTítulo . |asin-tld=requiere |asin=( ayuda )

pierde el mensaje "Check | asin-tld = value".

  • Sin ASIN, TLD válido:
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin-tld=de}}
VivirTítulo . |asin-tld=requiere |asin=( ayuda )
SalvaderaTítulo . |asin-tld=requiere |asin=( ayuda )

está bien.

  • ASIN válido, TLD no válido:
Comparación de libros de citas
Wikitexto{{cite book |asin=6305277001 |title=Title |asin-tld=xy}}
VivirTítulo . ASIN  6305277001 Comprobar |asin-tld=valor ( ayuda ) .
SalvaderaTítulo . ASIN  6305277001 Comprobar |asin-tld=valor ( ayuda ) .

tiene un mensaje adicional "| asin-tld = requiere | asin =".

  • ASIN válido, TLD válido:
Comparación de libros de citas
Wikitexto{{cite book |asin=6305277001 |title=Title |asin-tld=de}}
VivirTítulo . ASIN  6305277001 .
SalvaderaTítulo . ASIN  6305277001 .

está bien.

  • ASIN no válido, TLD no válido:
Comparación de libros de citas
Wikitexto{{cite book |asin=xyz5277001 |title=Title |asin-tld=xy}}
VivirTítulo . ASIN  xyz5277001 Comprobar |asin-tld=valor ( ayuda ) .
SalvaderaTítulo . ASIN  xyz5277001 Comprobar |asin-tld=valor ( ayuda ) .

tiene el mensaje "| asin-tld = requiere | asin =" en lugar de "comprobar | asin = valor".

  • ASIN no válido, TLD válido:
Comparación de libros de citas
Wikitexto{{cite book |asin=xyz5277001 |title=Title |asin-tld=de}}
VivirTítulo . ASIN  xyz5277001 Comprobar |asin=valor ( ayuda ) .
SalvaderaTítulo . ASIN  xyz5277001 Comprobar |asin=valor ( ayuda ) .

tiene un mensaje adicional "| asin-tld = requiere | asin =".

  • ASIN válido, sin TLD:
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin=6305277001}}
VivirTítulo . ASIN  6305277001 .
SalvaderaTítulo . ASIN  6305277001 .

está bien.

  • ASIN no válido, sin TLD:
Comparación de libros de citas
Wikitexto{{cite book |title=Title |asin=xyz5277001}}
VivirTítulo . ASIN  xyz5277001 Comprobar |asin=valor ( ayuda ) .
SalvaderaTítulo . ASIN  xyz5277001 Comprobar |asin=valor ( ayuda ) .

está bien.

No he tenido la oportunidad de investigar esto hasta ahora.
- Matthiaspaul ( charla ) 00:01, 30 de marzo de 2021 (UTC)
Creo que he solucionado estas preocupaciones moviendo la prueba asin-tld-require-asin a Module: Citation / CS1 / Identifiers / sandbox . A la prueba no le importa cuál es el valor asignado, solo que cuando |asin-tld=tiene un valor, |asin=también debe tener un valor. La validación de |asin-tld=es manejada por asin(). La prueba de validación tld se realiza antes de la prueba de validación del identificador; asin()termina con un mensaje de error en el primer error.
Este código de prueba también funciona de la misma manera para |doi-broken-date=sin |doi=y |pmc-embargo-date=sin|pmc=
{{cite book/new |title=Title |doi-broken-date=April 2021}}→ Título . |doi-broken-date=requiere |doi=( ayuda )
{{cite book/new |title=Title |pmc-embargo-date=2 April 2021}}→ Título . |pmc-embargo-date=requiere |pmc=( ayuda )
- Trapense el monje ( charla ) 22:57, 2 de abril de 2021 (UTC)

No estoy seguro de entender por qué la Categoría: CS1 maint: ASIN usa ISBN debería eliminarse. Es una categoría muy útil, y un ISBN para un ASIN no significa que sea un ASIN no válido, solo uno redundante que debería convertirse en un ISBN. Headbomb { t · c · p · b } 17:19, 1 de febrero de 2021 (UTC)

Esto pertenece más al hilo ya archivado en Help_talk: Citation_Style_1 / Archive_75 # Added_asin-tld = _range_checking , pero como no quiero iniciar un nuevo hilo para este pequeño fragmento, estoy secuestrando este solo para anotar ese apoyo para los ASIN polacos ("pl"), que se introdujeron a principios de este mes, ahora también se ha agregado al |asin-tld=parámetro de la plantilla . - Matthiaspaul ( charla ) 15:23, 29 de marzo de 2021 (UTC)

"Iniciar sesión en Facebook" [ editar ]

¿Deberíamos agregar "Iniciar sesión en Facebook" (y "Iniciar sesión en Facebook - Facebook", "Iniciar sesión en Facebook | Facebook") a Categoría: Errores de CS1: título genérico ? 83 resultados en espacio para artículos. -  Finnusertop ( charla ⋅ contribuciones ) 04:10, 24 de febrero de 2021 (UTC)

83 hits no es exactamente mucho, pero lo agregaría de todos modos:
Otros hilos relacionados:
  • Help_talk: Citation_Style_1 / Archive_73 # Addition_to_generic_title
  • Help_talk: Citation_Style_1 / Archive_70 # Wayback_Machine
  • Help_talk: Citation_Style_1 # generic_title
- Matthiaspaul ( charla ) 13:59, 24 de febrero de 2021 (UTC) (actualizado a las 21:43, 5 de marzo de 2021 (UTC))
Agregado a la caja de arena:
Comparación de libros de citas
Wikitexto{{cite book |title=Log into Facebook}}
VivirInicie sesión en Facebook . Citar utiliza un título genérico ( ayuda )
SalvaderaInicie sesión en Facebook . Citar utiliza un título genérico ( ayuda )
- Matthiaspaul ( charla ) 21:43, 5 de marzo de 2021 (UTC)
@ Matthiaspaul : uno más relacionado con Facebook: "Redireccionando ...". La búsqueda de "Redirigiendo ... facebook" arroja 8 resultados, pero esta no es la forma correcta de buscar. -  Finnusertop ( charla ⋅ contribuciones ) 20:04, 11 de marzo de 2021 (UTC)
Esta búsqueda encuentra ~ 80 resultados.
- Trapense el monje ( charla ) 20:27, 11 de marzo de 2021 (UTC)
Agregado a la caja de arena:
Comparación de libros de citas
Wikitexto{{cite book |title=Redirecting...}}
VivirRedirigiendo .. . Citar utiliza un título genérico ( ayuda )
SalvaderaRedirigiendo .. . Citar utiliza un título genérico ( ayuda )
- Matthiaspaul ( charla ) 14:55, 20 de marzo de 2021 (UTC)

título genérico [ editar ]

Se agregaron internet archive wayback machine~ 560 visitas

Estos fueron agregados por REFLINKS c. 2012.

- Trapense el monje ( charla ) 13:08, 3 de marzo de 2021 (UTC)

Y agregó webcite query result~ 300 hits
Y estos fueron agregados por reFill y reFill 2.
- Trapense el monje ( charla ) 19:09, 18 de marzo de 2021 (UTC)
Y otros wikiwix's cache~ 200 hits
- Trapense el monje ( charla ) 19:22, 25 de marzo de 2021 (UTC)

¿Debería cite comic ser parte de CS1? [ editar ]

Como se titula, ¿debería incorporarse {{ Cite comic }} en el módulo CS1? (Discusión anterior en 2013: Charla sobre plantillas: Cite el cómic # CS1 )

Algunas observaciones sobre la plantilla:

  • En Charla de plantilla: Citar cómic # Campo de idioma (2011 y 2013), hubo algunas quejas sobre la falta de la |trans-title=que ya está disponible en CS1.
  • Aparte de eso, la plantilla también carece de cosas por el estilo |url-access=, |archive-url=, |via=, etc.
  • |isbn=no está disponible y debe introducirse manualmente en el formato de |id=ISBN 0123456789.
  • No se generan COinS.

Nota: La plantilla tiene una pantalla única para los diversos campos de autor ( |writer=, |artist=, etc.) y pueden no ser fáciles de combinar en CS1; por lo tanto, menciono esto pero no lo convierto en una nominación oficial al tfm.ネ イ( charla ) 15:36, 3 de marzo de 2021 (UTC)

Parece que no sería tan difícil convertirlo en un envoltorio de {{ citation }} o {{ cite book }}. Pruébelo en la caja de arena. - Jonesey95 ( charla ) 16:25, 3 de marzo de 2021 (UTC)
Depende de lo que se quiera decir con cite comic. ¿Es un problema específico? Entonces probablemente el análogo más cercano sea {{ cite magazine }}. ¿Es una antología o una colección? Entonces probablemente el más cercano sea {{ cite encyclopedia }} o uno de los otros redireccionamientos de ese tipo. El otro problema, por supuesto, es similar al que tiene {{ cite AV media }} y las notas, ya que tiene muchos otros campos para las personas que no son el autor (y que posteriormente no encajan necesariamente en el mecanismo CS1 / 2 está bien). Izno ( charla ) 03:37, 21 de marzo de 2021 (UTC)

Vinculación automática [ editar ]

Vuelva a vincular automáticamente el título cuando |hdl=y |hdl-access=se proporcionen de forma similar a cómo funciona con un archivo |doi=. Agregue hdl como una opción para |title-link=with |hdl=for cite journal. Sería útil si la combinación de |hdl=, |hdl-access=y |title-link=funcionara también para cite report, techreport o web. Gracias. - Whywhenwhohow ( hablar ) 04:30, 8 de marzo de 2021 (UTC)

El contenido de PMC a veces es obsoleto en comparación con el artículo de la revista y no debería ser el predeterminado cuando hay un doi o hdl gratis. La existencia de los parámetros |doi-free=o |hdl-free=debería hacer que doi o hdl tengan prioridad y se utilicen en lugar de pmc para el enlace del título. - Whywhenwhohow ( hablar ) 23:59, 8 de marzo de 2021 (UTC)
¿Cuál es el proceso para implementar estas recomendaciones? - Whywhenwhohow ( hablar ) 05:27, 26 de marzo de 2021 (UTC)
¿Por los artículos que editas? Agregue la URL que desea vincular como |url=parámetro. De esa manera, la lógica de qué cosa de alguna manera anula qué otra cosa puede ser tan complicada como quieras y el resto de nosotros no tenemos que tratar de entenderla o recordarla. - David Eppstein ( charla ) 06:14, 26 de marzo de 2021 (UTC)

Estilo de plantilla obtuso [ editar ]

¿Por qué se suprimen las etiquetas de volumen, número y página en {{ cite journal }}? Por ejemplo, volumen = 5 número = 37 página = 17 se traduce como un inescrutable 5 (37): 17 . ¿Por qué no mostrar vol: y p:? También hay una inconsistencia. Por ejemplo, si se utilizan {{ cite news }} o {{ cite web }}, la página se muestra como "p". y páginas como "pp."  JGHowes  talk 18:26, 12 de marzo de 2021 (UTC)

Porque fuera de Wikipedia, las revistas académicas y académicas comúnmente usan ese estilo, por lo que cs1 | 2 lo refleja. ha utilizado este estilo desde sus inicios . Ha habido algunas discusiones, intermitentes, sobre cambiar eso.{{cite journal}}
- Trapense el monje ( charla ) 18:43, 12 de marzo de 2021 (UTC)
La última discusión de planificación y la última discusión no planificada . Estoy bastante cerca de comenzar un RFC, solo necesito escribir algunas cosas. - Izno ( charla ) 19:45, 12 de marzo de 2021 (UTC)
No sé para cite journal pero {{ cite book }}, si pones algo además de un número simple en | volume =, no está en negrita, ej. [1] , así que ahí está. Quiero decir, no debería ser un gran problema cambiar la plantilla de la revista para que muestre "vol. X"; pero, de nuevo, es un problema menor del estilo de las citas y, siempre que la fuente sea identificable de forma única, no deberíamos preocuparnos demasiado por eso. RandomCanadian ( charla / contribuciones ) 20:10, 12 de marzo de 2021 (UTC)
Eso sucede porque escribió |volume=vol. 1 qué valor hace que Module: Citation / CS1 muestre un volumen sin negrita porque el valor tiene cinco caracteres de longitud. No deberías estar haciendo lo que hiciste. Es responsabilidad de las plantillas dar formato a los valores proporcionados en los parámetros cuando se procesa la cita. Si esta discusión o alguna otra discusión nos lleva a cambiar cómo se renderiza para que se traduzca como 'vol. < valor de volumen > ', su cita se mostrará como' vol. vol. 1. ' y alguien tendrá que arreglarlo. No incluya texto superfluo en los valores de los parámetros cs1 | 2.{{cite book}}|volume=
- Trapense el monje ( charla ) 20:31, 12 de marzo de 2021 (UTC)
Eso fue en gran medida una solución intencional porque personalmente no estoy contento con ese formato; lo he visto usado para revistas pero no para libros. RandomCanadian ( charla / contribuciones ) 20:39, 12 de marzo de 2021 (UTC)
Con todo respeto, ¿no es más sencillo no utilizar plantillas CS1? Luego, formatea la cita como mejor te parezca. La razón fundamental detrás de enfatizar el volumen fue hacer que la gente se diera cuenta de que se trata de una fuente de varias partes, cuya búsqueda no termina con la localización del título, se debe profundizar más para encontrar la parte adecuada. El peso en negrita se usa como énfasis para distinguir el énfasis que se le da al título, que está en cursiva. Y, obviamente, la representación de la plantilla del parámetro de volumen es confusa y contradictoria, y las instrucciones son inadecuadas. Usaría una cita a mano alzada en lugar de tratar de descubrir las tonterías. 98.0.246.242 ( conversación ) 01:09, 13 de marzo de 2021 (UTC)
El único problema de hacer una cita a mano alzada es que, si está tratando de que el artículo sea promocionado a GA o FA, es probable que encuentre objeciones al formato de cita inconsistente.  JGHowes  talk 01:30, 13 de marzo de 2021 (UTC)
No usar plantillas de citas es algo malo, en mi opinión, en particular si es solo por razones de estilo. Si existe una demanda para admitir algo que nuestras plantillas actuales no permiten, las plantillas deben mejorarse en lugar de no utilizarse.
- Matthiaspaul ( charla ) 13:14, 13 de marzo de 2021 (UTC)
Las plantillas son formularios. ¿Alguna vez usaría un formulario que requiera que ingrese su nombre en mayúsculas si tiene más de 5 caracteres y en minúsculas de lo contrario? Esto no es solo un mal diseño de plantilla, carece de sentido. El módulo debería emitir el error "no usar - ilógico" (en letras rojas, por supuesto). En caso de que la gente piense que esto acaba de aparecer, no es así. Se ha señalado durante años. 64.61.73.84 ( conversación ) 15:23, 14 de marzo de 2021 (UTC)
Las plantillas también son funciones. Si se usan, agregan valor (como un formato más consistente de las citas en los artículos, mantenimiento central, verificación de errores, legibilidad por máquina y generación de metadatos). Estas características ayudan directa o indirectamente a mejorar la calidad del contenido que proporcionamos y también ayudan a una multitud de otros proyectos).
Con respecto al mensaje de error, como puede ver a continuación, estamos en el proceso de agregarlo.
- Matthiaspaul ( charla ) 17:21, 14 de marzo de 2021 (UTC)
Funcionalmente, estas son plantillas de ayuda de editor, no de administrador / programador. Las diversas peculiaridades y las tonterías no envejecen bien. 98.0.246.242 ( conversación ) 02:45, 15 de marzo de 2021 (UTC)
Lo anterior me hizo preguntarme con qué frecuencia |volume=vol. ...se usa en . Esta búsqueda dice que hay más de 14.5k artículos con parámetros mal formados (tiempo de espera de búsqueda). De ellos, unos 1400ish son números romanos (también se agota el tiempo de espera). A modo de comparación, hay alrededor de 72 artículos en kish que se usan con valores que no comienzan con 'V' o 'v' (y sí, se agota el tiempo de espera).{{cite book}}|volume={{cite book}}|volume=
Si vamos a mirar |volume=, también deberíamos mirar |issue=aunque {{cite book}}no es compatible |issue=: ~ 100 (tiempo de espera agotado).
Cambiar a las mismas búsquedas, solo un nombre de plantilla diferente da resultados de búsqueda no concluyentes (todos agotados), por lo que hacer un juicio basado en estos es prácticamente inútil:{{cite journal}}
|volume=[Vv][^Ii\|\}]- ~ 870
|volume=[Vv][Ii]* *[\|\}]- ~ 1450
|issue=[Ii][^Ii\|\}]- ~ 500
Lo que creo que se puede decir es que como |page=y |pages=, deberíamos estar capturando |volume=y |issue=cuando estos tengan algún tipo de texto adicional que se parezca al nombre del parámetro.
- Trapense el monje ( charla ) 23:03, 12 de marzo de 2021 (UTC)
Y he pirateado Module: Citation / CS1 / sandbox y Module: Citation / CS1 / Configuration / sandbox para implementar esto. Una sola función hace ambas cosas |volume=y |issue=. Las pruebas no distinguen entre mayúsculas y minúsculas y buscan varios designadores de volumen y problema:
|volume= el valor comienza con:
volume
vol (con o sin punto terminal)
v. (requiere un punto terminal porque 'v' puede ser un número romano permitido)
|issue= el valor comienza con:
issue
iss (con o sin punto terminal)
i. (requiere un punto terminal porque 'i' puede ser un número romano permitido)
no (con o sin punto terminal)
¿Hay otros patrones que deberíamos buscar?
- Trapense el monje ( charla ) 23:45, 13 de marzo de 2021 (UTC)
yo añadí
number
nr (con o sin separador de terminales)
En raras ocasiones, también he visto dos puntos (:) usados ​​en lugar de un punto (.), Por lo tanto, he agregado: y = como separadores detectados.
Creo que deberíamos mover los patrones a / Configuration para facilitar la localización.
Comparación de revistas de citas
Wikitexto{{cite journal |number=I.3 |title=Title |volume=Vol:3 |journal=Journal}}
Vivir"Título". Diario . Vol: 3 (I.3). |volume= has extra text (help)
Salvadera"Título". Diario . Vol: 3 (I.3). |volume= has extra text (help)
- Matthiaspaul ( charla ) 15:29, 14 de marzo de 2021 (UTC)
Modifiqué los patrones de un solo carácter ('v', 'i', 'n') para que capten < char > < space >. Los espacios en blanco se recortan de los valores de los parámetros antes de la entrega al módulo, por lo que estos ajustes capturan, |volume=V 123etc.
Mantener los patrones locales a la función hasta que nos decidamos por lo que hará el código es mejor por ahora. Sí, debería moverse antes de la próxima sincronización.
- Trapense el monje ( charla ) 16:31, 14 de marzo de 2021 (UTC)
Se agregaron las formas plurales "volúmenes", "vols", "números", "nos", "ediciones" (más variantes). Rara vez visto, pero dado que admitimos rangos de parámetros, podrían ocurrir.
Comparación de revistas de citas
Wikitexto{{cite journal |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
Vivir"Título". Diario . I – II (3, 5).
Salvadera"Título". Diario . I – II (3, 5).
Comparación de revistas de citas
Wikitexto{{cite journal |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
Vivir"Título". Diario . vols. I – II (núms. 3, 5). |volume= has extra text (help); |number=tiene texto extra ( ayuda )
Salvadera"Título". Diario . vols. I – II (núms. 3, 5). |volume= has extra text (help); |number=tiene texto extra ( ayuda )
Cite la comparación de revistas
Wikitexto{{cite magazine |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
Vivir"Título". Diario . Vol. I – II no. 3, 5.
Salvadera"Título". Diario . Vol. I – II no. 3, 5.
Cite la comparación de revistas
Wikitexto{{cite magazine |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
Vivir"Título". Diario . Vol. vols. I – II no. nos. 3, 5. |volume= has extra text (help); |number=tiene texto extra ( ayuda )
Salvadera"Título". Diario . Vol. vols. I – II no. nos. 3, 5. |volume= has extra text (help); |number=tiene texto extra ( ayuda )
- Matthiaspaul ( charla ) 18:51, 30 de marzo de 2021 (UTC)
Si se va a ejecutar alguna forma de RFC a continuación, diferir la acción en estos casos hasta después podría crear menos fricción. Puede suceder, por ejemplo, que el RFC elimine el problema para el que se crearon estos formularios, en cuyo caso nadie los perderá. Kanguole 15:35, 14 de marzo de 2021 (UTC)
No importa. cs1 | 2 es responsable de la anotación utilizada al renderizar |volume=y |issue=. Estas pruebas detectan un volumen inapropiado y emiten anotaciones en los valores asignados a los parámetros. Las anotaciones adicionales inapropiadas siempre serán inapropiadas independientemente del resultado de un rfc (si hay un rfc).
- Trapense el monje ( charla ) 15:44, 14 de marzo de 2021 (UTC)
Tengo la esperanza de que estos mensajes sean mensajes de mantenimiento ocultos cuando se implementen inicialmente. Dada la discusión actual sobre los guiones en VPP, nos convendría evitar ser sordos a las preocupaciones de los editores sobre los mensajes de error y los cambios en las plantillas de CS1 basados ​​en discusiones limitadas. - Jonesey95 ( conversación ) 04:36, 15 de marzo de 2021 (UTC)

Borrador de RFC [ editar ]

He redactado un borrador de RFC durante las últimas dos horas basado en la planificación previa realizada. Feliz de ver comentarios sobre cambios de redacción, ajustes audaces, etc. - Izno ( charla ) 22:44, 12 de marzo de 2021 (UTC)
Está bien pensado y muy bien representado. Pero de esta forma, podrá escuchar al editor colectivo rascarse la cabeza a través de Internet. Por no decir que sé cómo hacerlo más sencillo. Yo inclinaría subjetivamente el argumento a favor de una coherencia fácilmente reconocible, y condenaría a los expertos. Renderizar una página "página / p", emitir "problema / no" y volumen "volumen / vol". Luego siéntese y disfrute de discusiones menos infructuosas. 98.0.246.242 ( conversación ) 01:23, 13 de marzo de 2021 (UTC)
Agradezco el esfuerzo, pero creo que de esta forma es demasiado complicado para un RFC y, al dar a los lectores una libertad de elección casi completa, será difícil obtener una imagen clara de las respuestas.
Creo que lo que realmente buscamos es la opinión de la comunidad para comprender mejor las preferencias generales de la comunidad, mientras que, mientras ajustamos las plantillas de acuerdo con el resultado del RFC, la clasificación de los casos de esquina y los detalles esenciales se pueden dejar para más adelante. discusiones locales. Por lo tanto, para mantener las cosas lo más simples posible para ellos (para que obtengan una imagen general), no deberíamos discutir en este RFC:
  1. Qué parámetros deberían ser compatibles con qué plantilla
  2. Consideraciones con respecto a las publicaciones que tienen designaciones tanto de número como de edición
  3. Variaciones de estilo menores entre formas singulares y plurales, listas y rangos
  4. Si debemos agregar comas entre los valores en estilo "abreviado" o no
  5. Si los volúmenes deben presentarse en negrita en estilo "científico" o "simbólico" o no, o dejarlo condicionado a la extensión y al formato interno
(Para la mayoría de estas preguntas, en realidad, no necesitamos la participación de una amplia comunidad, excepto, quizás, la última. Cuando sea necesario, estos temas se pueden abordar en discusiones locales posteriores).
Por lo tanto, los estilos para elegir se pueden resumir en cuatro variantes principales, siendo la # 1 y la # 3 las más importantes (donde V es un marcador de posición para el volumen, N un marcador de posición para el número de problema, P un marcador de posición para el información de la página y todas las demás letras y símbolos del estilo en sí):
  1. "Científico": V (N): P. Ejemplo: 15 (11): 14-23.
  2. "Simbólico": V (N), págs. P. Ejemplo: 15 (11), págs. 14-23.
  3. "Abreviado": Vol. V no. N. ... págs. P. Ejemplo: Vol. 15 no. 11. ... págs. 14-23.
  4. "Completo": Volumen V, número N. ... páginas P. Ejemplo: Volumen 15, número 11. ... páginas 14–23.
Las dos preguntas principales que deben responderse:
  • ¿Deberían cambiar todas las plantillas para utilizar uno de estos estilos para mantener la coherencia o deberían seguir utilizando estilos diferentes según el tipo de publicación? Si todos deben usar el mismo estilo, ¿cuál de estos cuatro? Cuando solo una plantilla en particular debe cambiar a un estilo diferente, los lectores también pueden mencionar esto, pero preguntar por el estilo preferido de cada plantilla individualmente complicaría innecesariamente las cosas.
  • Si hubiera una forma de anular el estilo predeterminado utilizado por una plantilla (como a través de un |periodical-style=scientific/symbolic/abbreviated/fullparámetro, el nombre del parámetro y las palabras clave son solo identificadores de trabajo, los nombres reales podrían discutirse localmente más adelante). Esto permitiría a los editores imponer la coherencia de estilo dentro de un artículo, incluso si las plantillas seguirían teniendo diferentes estilos predeterminados, o cambiar a un estilo de presentación diferente cuando fuera conveniente (por ejemplo, tener algunos medios para usar el estilo "científico" en un estilo muy científico artículo incluso si las plantillas usarían el estilo "abreviado" de forma predeterminada).
- Matthiaspaul ( charla ) 13:14, 13 de marzo de 2021 (UTC)
Comparto la preocupación de que es probable que las cuatro preguntas propuestas inicien un debate de amplio alcance del que será difícil extraer acciones concretas. Puede resultar más provechoso presentar un menú breve de opciones y preguntar por las preferencias de las personas. Además, creo que las discusiones anteriores han identificado tres opciones claras:
  1. status quo
  2. 1 (2): 34–56 para revistas y vol. 1, no. 2, págs. 34-56 para todo lo demás (aunque el número / número tiende a ser algo de diario)
  3. vol. 1, no. 2, págs. 34–56 para todo
Algunas personas abogaron por deletrear completamente "volumen", "número" y "páginas"; tal vez esa podría ser una segunda pregunta.
No creo que sea una buena idea ofrecer más parámetros de opciones de formato. Kanguole 14:31, 13 de marzo de 2021 (UTC)
Con respecto a una opción para anular el formato predeterminado, generalmente soy un defensor de la coherencia, pero también reconozco que algunas personas pueden tener necesidades desviadas en artículos específicos. La idea de tal parámetro es facilitarles la votación por un formato estándar predeterminado en un RfC, incluso si este no es su formato preferido, ya que aún podrían anular el predeterminado donde realmente lo necesiten. Por lo tanto, el resultado del RfC tendrá más posibilidades de ser aceptado por la comunidad en su conjunto. Logre más consistencia en general de forma predeterminada y aún así mantenga a todos contentos. Lugar más amigable, mejor resultado del proyecto. - Matthiaspaul ( charla ) 17:21, 14 de marzo de 2021 (UTC)

Mi comentario sobre ese RFC es que es abrumador y está sobrecargado de información y opciones.

  1. La tabla debe tener una sola columna con todos los parámetros admitidos (VIP para revistas, VP para libros, P para arxiv, I para podcasts, etc.).
  2. El RFC debe ser específicamente sobre explícito (abreviado Vol. 1 no. 2 p. 3) vs implícito (en negrita y posicional 1 (2): 3). Cuestiones Dejar de capitalización fuera, ya que solo deberían aplicarse de conformidad con las reglas de gramática (Vol. 1 . No . 2 . P. 3 . Con separaciones de puntos o Vol. 1 no. 2 p. 3 / Vol. 1, no 2., p. 3 sin separadores o comas, con Vol. en mayúscula o no dependiendo de si sigue un separador de puntos o no).

Headbomb { t · c · p · b } 15:26, 13 de marzo de 2021 (UTC)

Sin responder a nadie en particular, pero tratando de cubrir el comentario:

  1. No estoy a favor de los interruptores personalizados. No lo propondré e intentaré dejar claro en el RFC que eso no está sobre la mesa. Agregar personalización en estas plantillas funciona deliberadamente en contra de cualquier motivo o justificación para tener un RFC.
  2. Yo estoy interesado en esencial y grittys. La comunidad nunca llega a un consenso con un vago "Wikipedia debería hacer esto" que es + - 'por la comunidad porque la comunidad siempre menciona los detalles por separado de alguna manera no estructurada, en lugar de ser invitada a comentar directamente.
  3. Aprecio que haya mucho margen de maniobra en las preguntas. Estoy de acuerdo en que se presenta alguna información (las viñetas enumeradas por Matthias, quizás además de la última viñeta), pero no es parte de la pregunta central. Intentaré aclararlo. (¿El orden de los parámetros en una cita específica es otro? No estoy seguro. Comas otro. No estoy necesariamente de acuerdo en que el número de volumen necesita una coma, pero es un punto de aparición que, dado que todavía no podemos deshacerse de CS2 [muestra su claro sesgo] probablemente esté abierto al desacuerdo).
  4. Deliberadamente le he dado libertad a la comunidad. Si quieren ir "volumen en negrita, con indicador de página, como en el libro de citas, para todas las plantillas, o todas las plantillas al lado de la revista de citas", esa debería ser su elección. La comunidad se va a meter en este tipo de preguntas, lo quiera yo o no, solo por la sensibilidad de las citas.
  5. No, no creo que los debates anteriores hayan ilustrado ninguna opción preferida en particular. Creo que tenemos algunas plantillas que se ven como lo hacen y algunas discusiones previas sobre cómo deberían verse algunas plantillas, pero ninguna que haya examinado el conjunto de forma sistemática. Sin embargo, tengo fe en la comunidad, que la mayoría de la comunidad se adaptará al aspecto general de las plantillas hoy en día en lugar de proponer estilos locos.
  6. Consideré presentar la tabla en una columna o similar. El problema es que no todas las plantillas tendrán todos los parámetros llenos y los lectores pueden estar interesados ​​en cómo se verán las plantillas. Cite journal es quizás el único entre el conjunto que se puede esperar que se complete para los 3 parámetros de manera regular, e incluso entonces sospecho que no tomará mucho tiempo encontrar contraejemplos.
  7. Densidad general de la información: no quiero que la gente busque cómo se ve hoy o qué hacen las plantillas en conjunto. No espero quejas fuertes si falta esa información, pero sí espero quejas. Abierto a sugerencias, puntos de reducción específicos (teniendo en cuenta que algunos 'no hables de estas cosas' se agregarán como se indica), o incluso alguien más bifurcando su propio borrador para comparar.

- Izno ( charla ) 03:27, 21 de marzo de 2021 (UTC)

Bien, he reelaborado las preguntas. Descubrí que odiaba cómo había hecho las preguntas originales porque podía ver que conducían a muchas respuestas no estructuradas. ¿Son mejores las nuevas preguntas para eso? Izno ( charla ) 19:54, 11 de abril de 2021 (UTC)

"No veo una razón para eso" [ editar ]

Sea más específico que WP: IDONTLIKEIT , Usuario: Izno . Gracias CapnZapp ( charla ) 18:44, 15 de marzo de 2021 (UTC)

"No me gusta" y "No veo valor en su adición en este contexto / en esta página" no son equivalentes. - Izno ( charla ) 20:34, 15 de marzo de 2021 (UTC)
No, Izno, no puedes revertir el contenido sin una explicación. He comenzado esta sección de charlas para que explique lo que quiere decir con "No veo una razón para eso". Y el hecho de que no vea "valor" en mi adición no es suficiente. ¿Se supone que debo leer tu mente? ¿O simplemente intente reformular una y otra vez hasta que encuentre una versión que se digne permitir? CapnZapp ( charla ) 11:49, 16 de marzo de 2021 (UTC)
Creo que los siguientes usuarios han explicado suficientemente mis razones para la reversión. Izno ( charla ) 03:31, 21 de marzo de 2021 (UTC)
Esta discusión parece referirse a la Ayuda: Estilo de cita 1 # Using_ | format = ; particularmente esta adición y la subsiguiente reversión . Para mí, no estoy convencido de que la adición sea necesaria porque no me queda claro cómo se benefician los editores habituales del texto añadido.
- Trapense el monje ( charla ) 12:19, 16 de marzo de 2021 (UTC)
Si asumimos que un editor recurrirá a una página de ayuda para encontrar rápidamente punteros concisos, actualizados y enfocados, entonces la nota revertida es un peso muerto. No estoy discutiendo los méritos de su contenido, solo que, en mi opinión, está fuera de lugar en una página que pretende ser una guía práctica. 98.0.246.242 ( conversación ) 04:18, 17 de marzo de 2021 (UTC)

Fechas ISO [ editar ]

¿Podemos agregar soporte para fechas ISO largas, por ejemplo, 2021 16 de marzo? - kwami ( conversación ) 01:43, 17 de marzo de 2021 (UTC)

Umm, ese no es un formato de fecha ISO 8601 . cs1 | 2 se adhiere lo más cerca posible a MOS: DATES ; cuando MOS: DATES permite el formato de fecha YYYY Mes dd, aparecerá cs1 | 2.
- Trapense el monje ( charla ) 02:10, 17 de marzo de 2021 (UTC)
Discusión relacionada: Wikipedia_talk: Manual_of_Style / Dates_and_numbers # ISO_8601
- Matthiaspaul ( charla ) 17:00, 11 de abril de 2021 (UTC)

Ayuda: Estilo de cita 1 / problemas de prueba [ editar ]

Hola,

Algo ha causado que esta página ahora tenga la categoría de enlace rojo Categoría: CS1 errores: texto adicional: problema . No puedo encontrar una edición reciente que haga que aparezca esta categoría. ¿Alguien puede ayudar a solucionar este problema para que la categoría inexistente no aparezca en las listas de errores o crear esta categoría si ahora es necesaria? Gracias. L iz Read! ¡Hablar! 05:06, 18 de marzo de 2021 (UTC)

Gracias. Este es probablemente un problema temporal causado por los preparativos (aún incompletos) para agregar advertencias de texto adicionales |issue=, |number=y de |volume=acuerdo con este hilo: Help_talk: Citation_Style_1 # Obtuse_template_style
- Matthiaspaul ( charla ) 11:09, 18 de marzo de 2021 (UTC)
Fue aún más simple: el ejemplo en Ayuda: Estilo de cita 1 / problemas de prueba contenía |issue=Issuepero faltaba el |no-tracking=yesparámetro que causaba la categorización ahora que agregamos la advertencia de texto adicional "problema" a la plantilla. - Matthiaspaul ( charla ) 18:36, 19 de marzo de 2021 (UTC)

Referencias enumeradas por editor del libro, pero listas de bibliografía por autor del capítulo [ editar ]

Estoy citando un capítulo con un autor específico en un libro que tiene a otra persona como editor, y veo que la cita de Harvard cita el libro por el apellido del editor en la sección de Referencias y por el apellido del autor del capítulo en la bibliografía. ¿Hay alguna forma de solucionar este problema o no ha sido un problema para nadie? Danaphile ( conversación ) 23:48, 19 de marzo de 2021 (UTC)

Al crear un ancla CITEREF, cs1 | 2 siempre usa el nombre del autor si está disponible; de lo contrario, recurre al nombre del editor. Si solo necesita citar el trabajo de un autor de una colección editada, vuelva a escribir la plantilla cs1 | 2 para incluir el autor y la contribución del autor. Si necesita citar las contribuciones de varios autores de una colección editada, omita los nombres de los autores de la cita cs1 | 2 y agregue por cada contribución de autor . Entonces, en el texto del artículo, la plantilla (o ) tiene el nombre del autor y enlaces a la plantilla apropiada que, a su vez, enlaza con la plantilla cs1 | 2.{{harvc}}{{sfn}}{{harv}}{{harvc}}
Un ejemplo: aquí hay un par de {{sfn}}plantillas. [1] [2]

Referencias

  1. ^ Azul 2021 , pág. 13.
  2. ^ Greene 2021 , pág. 45.
Y una plantilla y dos plantillas en §Bibliografía:{{cite book}}{{harvc}}
  • Black, ed. (2021). Todo sobre colores .
    • Azul. "Por qué el azul es el mejor color". En negro (2021) .
    • Greene. "El verde es mejor que el azul porque tiene amarillo". En negro (2021) .
- Trapense el monje ( charla ) 00:20, 20 de marzo de 2021 (UTC)
Gracias por este puntero a {{harvc}} . Esto es extremadamente útil cuando se citan enciclopedias, y no lo sabía hasta ahora. {{ sfnm }} es otro que encontré recientemente. ¿Hay una lista en alguna parte de la familia de plantillas sfn / harv? - Michael Bednarek ( charla ) 03:55, 21 de marzo de 2021 (UTC)
Plantilla: Sfn § Las plantillas de citas de autor – fecha es la única lista que conozco.
- Trapense el monje ( charla ) 11:28, 21 de marzo de 2021 (UTC)

¿Referencia y bibliografía? [ editar ]

¿Existe una manera sencilla de agregar, por ejemplo, {{ cite journal }} solo una vez, ya sea en línea <ref>o en la sección Bibliografía e invocarlo por su nombre en la otra aparición? Parece frágil tener que incluirlo dos veces. Urhixidur ( conversación ) 11:34, 23 de marzo de 2021 (UTC)

{{sfn}}Yo hago eso. Usted da la cita completa, con el rango de páginas completo del artículo, en la bibliografía y tiene referencias breves con las páginas específicas en cada uso. Kanguole 11:41, 23 de marzo de 2021 (UTC){{sfnp}}
Consulte WP: REFNAME . - Jonesey95 ( conversación ) 15:17, 23 de marzo de 2021 (UTC)

Estilo de informe [ editar ]

{{ cite report }} debería, como {{ cite journal }} y otros, citar el título en lugar de simplemente escupirlo en letras romanas. Urhixidur ( charla ) 13:03, 23 de marzo de 2021 (UTC)

{{cite report}}es la forma en que es porque esa fue la forma en que se creó hace tantos años. Para la discusión que se produjo en la época en que emigré {{cite report}}a partir de Módulo: Cita / CS1 , consulte Ayuda Discusión: Cita estilo 1 / Archivo 6 § Cite informe .{{citation/core}}
- Trapense el monje ( charla ) 13:27, 23 de marzo de 2021 (UTC)
Hablamos de citar informe en ocasiones. Por favor, eche un vistazo a los archivos. Izno ( charla ) 14:28, 23 de marzo de 2021 (UTC)

Encontrar errores en los nombres de Vancouver [ editar ]

Basándome en una discusión fuera de wiki sobre lo difícil que es encontrar errores en las listas de nombres de Vancouver, modifiqué las cajas de arena para que informen un enésimo nombre que contenga el error. Es un primer corte y doy la bienvenida a cambios "mejores". Particularmente, no estoy seguro de cuál es la mejor manera de lidiar con vauthors versus veditors y vauthors versus lista de nombres (y la combinación); sin embargo, puede que no sea particularmente importante. Es posible que el codificador interesado desee modificar los datos que informa el módulo.

Agregar "en el nombre X" también puede ser mejor antes de los dos puntos que después. No tengo una opinión firme sobre ese punto, pero me gusta más después que antes.

Los lectores interesados ​​pueden revisar la charla del módulo: Citation / CS1 / testcases / errors en test_vancouver y test_vauthors. Izno ( charla ) 02:42, 27 de marzo de 2021 (UTC)

DOI mayor que 10.49999 [ editar ]

¡Hola! Ahora parece haber DOI válidos con prefijos de 10.50000 y superiores (citados, por ejemplo, aquí ) pero estos hacen que las plantillas los marquen para su verificación ("Verificar | doi = valor (ayuda)"). marcar el rango 10.50000–10.59999? ¡Gracias! - Collin t c 16:10, 28 de marzo de 2021 (UTC)

Ya se ha solucionado en la caja de arena.
- Trapense el monje ( charla ) 16:18, 28 de marzo de 2021 (UTC)
Desde enero . No debería llevar varios meses implementar aumentos de límites de rutina en los identificadores. Headbomb { t · c · p · b } 16:25, 28 de marzo de 2021 (UTC)
Todavía producen un enlace y el mensaje de error se puede suprimir con ((...))alrededor del DOI según la Ayuda: Estilo de cita 1 # Marcado de Aceptar como está escrito . Una búsqueda [2] actualmente encuentra siete DOI en funcionamiento haciendo eso:
  • doi : 10.51134 / sod.2013.039
  • doi : 10.51593 / 20190038
  • doi : 10.51291 / 2377-7478.1099
  • doi : 10.51291 / 2377-7478.1201
  • doi : 10.51405 / 0639-014-002-006
  • doi : 10.51442 / ijags.0009
  • doi : 10.5951 / mathteaceduc.2.1.0042
Una edición de Module: Citation / CS1 / Identifiers obliga a renderizar 4,8 millones de páginas, por lo que tampoco debería actualizarse con demasiada frecuencia. PrimeHunter ( charla ) 18:55, 28 de marzo de 2021 (UTC)
Tenemos una gran cantidad de cambios listos para usar en la caja de arena. Probablemente deberíamos actualizar los módulos en vivo, o al menos publicar una lista de los cambios y discutir si queremos que todos se activen. Una vez cada dos meses no debería suponer una gran carga para los servidores. - Jonesey95 ( charla ) 02:27, 29 de marzo de 2021 (UTC)
En este momento, las actualizaciones son trimestrales, generalmente a principios de los meses 1/4/7/10. Headbomb solo está molesto porque no ha intentado obtener / obtenido consenso para hacerlo más a menudo. Izno ( charla ) 04:33, 29 de marzo de 2021 (UTC)
Estoy molesto porque esta plantilla está controlada por una pequeña minoría de personas que no pueden actualizar la plantilla cuando es necesario actualizarla. No hay ninguna razón o consenso para que estas actualizaciones se realicen una vez cada 43 siglos. Muéstrame el consenso para eso . Headbomb { t · c · p · b } 19:03, 29 de marzo de 2021 (UTC)
Si acababa de iniciar el RFC la última vez que hablamos de esto, es posible que las ediciones se realicen con más frecuencia que trimestralmente. Izno ( charla ) 19:08, 29 de marzo de 2021 (UTC)
Gracias a todos, agradezco la información y el trabajo! - Collin t c 18:35, 29 de marzo de 2021 (UTC)
En mi humilde opinión, no tiene sentido establecer límites superiores en los identificadores para la validación. ¿Con qué frecuencia eso ayudará realmente a los editores? ¿Y con qué frecuencia generará falsas alarmas porque el límite está desactualizado? ¿Y cuánto problema es mantener, cuando las ediciones en el módulo provocan enormes retrasos en la renderización? Mantenlo simple, ahorra tiempo a todos y simplemente elimina esos límites. - Pintoch ( charla ) 09:23, 31 de marzo de 2021 (UTC)
Veo buenos argumentos a favor y en contra de esos límites. Una posible forma de resolver los problemas sería hacer que los límites sean "autoservicios", es decir, crear un archivo de configuración de límites especial, que permitiría anular los límites definidos internamente (solo) en la dirección ascendente. Este archivo no debe estar protegido, de modo que cualquier persona pueda editarlo (excepto, quizás, las direcciones IP), de modo que prácticamente cualquier editor que se encuentre en un límite podría (guiado por la sección de ayuda vinculada en el mensaje de error) editar el archivo y aumentar el límite. Ocasionalmente, un vándalo podría intentar sabotear los límites estableciendo valores demasiado altos o demasiado bajos, pero mientras los límites no se puedan establecer en valores más bajos que los definidos internamente (si es así, el módulo simplemente los ignorará),y mientras la lectura de un archivo de límites posiblemente con sintaxis destruida no provoque ningún error de Lua, no se podría causar ningún daño real, excepto que los límites se deshabilitarían temporalmente de manera efectiva. Siempre que se actualice el conjunto de módulos, los límites internos se actualizarán para reflejar los límites definidos en el archivo de límites (más algún margen). La sobrecarga para implementar un esquema de este tipo debería ser pequeña, pero reduciría el mantenimiento necesario al mínimo y eliminaría la necesidad de esos frecuentes subprocesos de "actualice el límite". ¿Lo mejor de ambos mundos?La sobrecarga para implementar un esquema de este tipo debería ser pequeña, pero reduciría el mantenimiento necesario al mínimo y eliminaría la necesidad de esos frecuentes subprocesos de "actualice el límite". ¿Lo mejor de ambos mundos?La sobrecarga para implementar un esquema de este tipo debería ser pequeña, pero reduciría el mantenimiento necesario al mínimo y eliminaría la necesidad de esos frecuentes subprocesos de "actualice el límite". ¿Lo mejor de ambos mundos?
- Matthiaspaul ( charla ) 13:28, 31 de marzo de 2021 (UTC)
@ Matthiaspaul : No creo que cambiar los permisos necesarios para editar esos límites resolvería el problema de que volver a renderizar todas las páginas que dependen de él es costoso. - Pintoch ( charla ) 14:38, 31 de marzo de 2021 (UTC)
Eso es cierto si sucediera con mucha frecuencia (digamos, cada dos días). Pero los administradores del sitio nos han indicado en el pasado que las actualizaciones ocasionales (digamos, una vez a la semana o cada dos semanas) no son realmente un problema.
Sin embargo, actualizar todo el conjunto de módulos a ese ritmo rápido dificultaría la búsqueda y corrección de errores antes de que los cambios se activen y también supondría una sobrecarga de mantenimiento, no solo para la actualización en sí, sino también para las acciones gnómicas que suelen suceder. en preparación para una actualización e inmediatamente después. La documentación también debe mantenerse sincronizada. Entonces, creo que es bueno que tengamos tiempos semiestáticos más largos entre las actualizaciones para que las cosas se resuelvan; si, en el sistema en vivo, todo fluiría todo el tiempo, sería más difícil detectar problemas.
Personalmente, creo que las actualizaciones del conjunto de módulos no deberían ocurrir con más frecuencia que cada dos meses, pero también estoy contento con el esquema actual de tres meses. Mantener un cronograma semi-fijo ayuda a estructurar el proyecto. Sin embargo, las correcciones de errores para problemas no triviales que ocurren con frecuencia deben implementarse cada vez que estén disponibles para no molestar a muchos lectores más de lo necesario. Y las actualizaciones de límites también podrían ocurrir con mucha más frecuencia, porque mientras tanto tenemos una infraestructura (con páginas de ayuda que se actualizan automáticamente) que hace que sea muy fácil implementarlas, y con solo cambiar un número (casi) no hay riesgo de introducir nuevos errores. La mayoría de los lectores no habrán reconocido esto porque en su mayoría sucedió en silencio,pero a partir de este año, Trappist movió algunas correcciones de errores y limita las actualizaciones al sistema en vivo poco después de que estuvieran disponibles en la caja de arena. Por lo tanto, algunos de los cambios implementados después de la última actualización del conjunto de módulos ya están activos. Creo que esta es una buena solución, pero dadas las actualizaciones de límites necesarias con frecuencia, esto podría volverse tedioso con el tiempo.
Por tanto, creo que algo parecido a mi propuesta podría ser en realidad una solución.
- Matthiaspaul ( charla ) 16:59, 31 de marzo de 2021 (UTC)

Automatización de etiquetas de acceso a URL [ editar ]

Algunos de nosotros en WP: Discord hemos estado charlando sobre la posibilidad de automatizar el parámetro de acceso a URL en esta cita. Floydian sugirió crear un conjunto de datos Lua que tenga un montón de URL para fuentes en línea de uso frecuente, y luego hacer que {{ Citation }} asigne automáticamente la etiqueta de acceso URL asociada con ese sitio web si no se proporciona una manual. Esto no funcionaría para todas las fuentes, ya que algunas seguramente tienen múltiples niveles de acceso u otros factores de confusión, pero incluso si solo podemos usarlo para un subconjunto de fuentes, ayudaría a que estos parámetros se usen mucho más ampliamente y se mantengan al día. hasta la fecha es mejor a medida que aumentan / reducen los muros de pago, y podríamos hacer que el sistema sea más avanzado con el tiempo. ¿Qué piensan todos ustedes? {{u |Sdkb }} charla02:18, 31 de marzo de 2021 (UTC)

Agregando un poco, los conjuntos de datos serían esencialmente listas de URL, similares a las listas blancas y listas negras que usamos, que asignarían esas URL base como, por ejemplo: suscripción, registro, gratis, sitios que son dos o más de esos, y posiblemente otro. categoría para los sitios que se sabe que son gratuitos en determinadas ubicaciones. - Floydian  τ ¢ 02:21, 31 de marzo de 2021 (UTC)
Supongo que tiene en mente el código externo al que llama el módulo cuando se configuran estos parámetros, de modo que se descarga el procesamiento relevante. Una anulación del editor debería ser una opción. En general, porque los humanos deberían tener control sobre todos los procesos, y en particular porque el estado de acceso puede reafirmarse más rápido que las actualizaciones de la base de datos. 64.61.73.84 ( conversación ) 03:15, 31 de marzo de 2021 (UTC)
Sí, la forma en que esto funcionaría es que si alguien lo usara {{citation|url=nonfreesite.com}}, usaría la entrada de la base de datos para nonfreesite.com para mostrar el candado, pero si alguien lo usara {{citation|url=nonfreesite.com|url-access=free}}, se anularía. {{u | Sdkb }}  charla 03:27, 31 de marzo de 2021 (UTC)
"Listas de URL, similares a las listas blancas y listas negras" Ya tenemos una base de datos para esto: Wikidata. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 16:01, 8 de abril de 2021 (UTC)
Aprecio la intención, pero deberíamos pensarlo dos veces antes de agregar listas codificadas como esta; será un trabajo importante de mantener. Me preocupa la creciente complejidad de este módulo y la sostenibilidad de su mantenimiento. ¿Consideraría agregar soporte para esto en un bot en su lugar? Ya hacemos bastante etiquetado con User: OAbot , este tipo de etiquetado fácilmente estaría dentro de su alcance. Además, sospecho que muchos dominios no pueden considerarse en su mayoría como de pago, con la generalización del acceso abierto híbrido entre los editores académicos, por lo que no me queda claro si sería tan útil en la práctica. ¿Quizás tienes dominios específicos en mente? - Pintoch ( charla ) 09:30, 31 de marzo de 2021 (UTC)
Pintoch , no tengo una opinión sólida sobre si deberíamos hacer la automatización a través de un bot o algo más, solo que si queremos que las etiquetas aparezcan ampliamente fuera de los GA / FA, debería haber algún tipo de automatización. Mantener una base de datos de URL con sus estados es mucho menos trabajo que mantener referencias individualmente, ya que es probable que cada sitio web se utilice cientos o miles de veces. No tengo dominios específicos en mente, aunque creo que los grandes periódicos pueden ser un buen lugar para comenzar. {{u | Sdkb }}  charla 10:00, 31 de marzo de 2021 (UTC)
@ Sdkb : entonces les invito cordialmente a llevar a cabo este proyecto a través de WP: OABOT . Si desea seleccionar la lista de fuentes de pago, estoy seguro de que podemos encontrar a alguien que agregue el código Python relevante allí para que funcione. Debería ser mucho más fácil obtener esto a través de BRFA que implementarlo en los módulos de citas. - Pintoch ( charla ) 14:41, 31 de marzo de 2021 (UTC)
Mi reacción instintiva a esta propuesta es que será solo una cosa más por la que los editores se pelean. ¿Qué hacer cuando la URL base puede ser gratuita y puede ser suscripción? ¿A quién se le asignará la tarea de diseñar y mantener esta base de datos? Si el objetivo de esta propuesta es ayudar a que estos parámetros se utilicen mucho más ampliamente , ¿cómo contribuye la aplicación automática del icono de acceso a ese objetivo? Módulo: Citación / CS1 no puede reescribir el wikitexto del artículo, por lo que los editores que miran el wikitexto nunca lo verán, excepto cuando un humano o un bot lo hayan agregado a la plantilla de citas.|url-access=
- Trapense el monje ( charla ) 10:59, 31 de marzo de 2021 (UTC)

formatos de fecha edtf como cs1 | 2 valores de parámetro de fecha (2) [ editar ]

La discusión original está en la charla de ayuda: Estilo de cita 1 / Archivo 33 # edtf formatos de fecha como valores de parámetro de fecha cs1 | 2 y en la misma tarea de fabricador : T132308 . El estándar EDTF está aquí .

En esa tarea de fabricador, puede ver que citoid pronto devolverá las fechas de mes y año en el formato EDTF: YYYY-MM-XXdonde XXson caracteres literales que actúan como marcadores de posición para días no especificados. Actualmente, Citoid está devolviendo estas fechas en un YYYY-MMformato incompatible con MOS: DATE .

Debido a T132308, resucité el código de 2017 que escribí para el formato EDTF, lo modifiqué un poco para acomodar los cambios intermedios en el Módulo: Citación / CS1 / Validación de fecha .

Citoid nos dará plantillas cs1 | 2 con fechas que se ven así cuando la fuente da fechas de mes y año:

{{cite book/new |title=Title |date=2021-03-XX}}
Título . Marzo de 2021.

- Trapense el monje ( charla ) 23:56, 31 de marzo de 2021 (UTC)

Gracias por rastrear esa tarea por nosotros. - Jonesey95 ( charla ) 00:01, 1 de abril de 2021 (UTC)
Citoid realmente debería estar en línea con el MOS aquí. Headbomb { t · c · p · b } 01:10, 1 de abril de 2021 (UTC)
100% de apoyo de mi lado. : thumbsup: - Matthiaspaul ( charla ) 10:14, 1 de abril de 2021 (UTC)

actualización del conjunto de módulos del 10 al 11 de abril de 2021 [ editar ]

Propongo actualizar el conjunto de módulos cs1 | 2 durante el fin de semana del 10 al 11 de abril de 2021. Estos son los cambios:

Módulo: Citación / CS1

  • Agregue soporte para emojis con ensambladores de ancho cero; discusión
  • Corrección err_parameter_ignoredy err_parameter_ignored_suggestvisualización de mensajes para parámetros no admitidos por algunas plantillas (como / / ) pero sugerencias coincidentes (como patrones o reglas individuales); discusión{{cite biorxiv}}{{cite citeseerx}}{{cite ssrn}}
  • Agregar el nombre del parámetro al err_extra_text_pagesmensaje
  • Añadir err_asintld_missing_asin, err_doibroken_missing_doi, err_embargo_missing_pmcmensajes de error que faltan |asin=/ |doi=/ |pmc=parámetros; discusión
  • Refactorizar funciones de estilo y referencia
  • Emite un mensaje de mantenimiento cuando el valor de |ref=es igual al valor predeterminado; discusión
  • Emite un mensaje de mantenimiento cuando |postscript=tiene más de un carácter; discusión
  • soporte i18n para desajuste año / fecha; discusión
  • gato de mantenimiento / separado del gato de mantenimiento de otra plantilla ; discusión{{cite AV media}}{{cite AV media notes}} |others=|others=
  • revertir la conversión de guión "útil"; discusión
  • revisar los mensajes de error; discusión|display-<names>=
  • agregar posición a los errores de Vancouver; discusión
  • admite el formato de fecha incierta edtf; discusión

Módulo: Citación / CS1 / Configuración

  • Eliminar el parámetro que ya no se usa |name-list-format=; discusión y discusión
  • Agregar el nombre del parámetro al err_extra_text_pagesmensaje
  • Agregar err_bad_asin_tldmensaje para |asin-tld=valores desconocidos ; discusión
  • agregar soporte COinS para |ol=y |asin=; discusión
  • Añadir err_asintld_missing_asin, err_doibroken_missing_doi, err_embargo_missing_pmcmensajes de error que faltan |asin=/ |doi=/ |pmc=parámetros
  • Emite un mensaje de mantenimiento cuando el valor de |ref=es igual al valor predeterminado;
  • Emite un mensaje de mantenimiento cuando |postscript=tiene más de un carácter;
  • Agregue soporte para emojis con ensambladores de ancho cero;
  • soporte i18n para desajuste año / fecha;
  • gato de mantenimiento / separado del gato de mantenimiento de otra plantilla ;{{cite AV media}}{{cite AV media notes}} |others=|others=
  • agregue otro título genérico; discusión
  • revisar los mensajes de error;|display-<names>=
  • |ismn=Corrección de errores de COinS; discusión
  • agregar posición a los errores de Vancouver
  • permitieron formas plurales de patrones de texto adicionales para volúmenes, números y números; discusión

Módulo: Cita / CS1 / Lista blanca

  • eliminar el parámetro que ya no se utiliza |name-list-format=; discusión y discusión
  • Desaprobar |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=; discusión
  • eliminar el soporte para los parámetros en desuso |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |sectionurl=, |seriesno=, |timecaption=, |titlelink=(en desuso en 01.09.2021; todos los casos retirados de los espacios de nombres categorizados como de 02.10.2021)
  • añadido después de este post, aplicada al módulo en vivo 10 de abril: Marcos |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, y |origyear=como "desanimado" parámetros por RFC; discusión

Módulo: Cita / CS1 / Validación de fecha

  • soporte i18n para desajuste año / fecha;
  • admite el formato de fecha incierta edtf;

Módulo: Cita / CS1 / Identificadores

  • subir el límite de cinco dígitos sin subcódigo de doi a 59999; discusión
  • error para asin con isbn-10; el error para isbn-10 comienza con 630 o 631; discusión
  • agregar verificación de |asin-tld=valores permitidos ; agregar tlds permitidos; discusión
  • agregar soporte COinS para |ol=y |asin=;
  • cambiar a la codificación 'PATH' para los enlaces ext de identificador; discusión
  • corregir mensajes de error de nivel de acceso; discusión
  • suprimir COinS para identificadores erróneos; discusión

Módulo: Citación / CS1 / COinS

  • agregar soporte COinS para |ol=y |asin=;

Módulo: Cita / CS1 / Sugerencias

  • agregue una pista para el parámetro eliminado |name-list-format=;

- Trapense el monje ( charla ) 17:28, 3 de abril de 2021 (UTC)

  • Con respecto err_doibroken_missing_doi, la discusión vinculada no menciona doi.
  • ¿Qué se entiende específicamente por "funciones de referencia y estilo de refactorización"?
  • Sería mejor posponer otras depreciaciones basadas en la separación de sílabas hasta el cierre de Village Pump RfC
  • Según la discusión vinculada para "Emitir mensaje de mantenimiento cuando el valor de | ref = es igual al valor predeterminado", el valor del cambio propuesto no está claro.
Nikkimaria ( charla ) 19:19, 3 de abril de 2021 (UTC)
Las funciones de estilo / referencia no estaban orientadas al usuario. Por eso se usó la palabra 'refactor'.
No veo una razón para dejar de eliminar las versiones en desuso y para dejar de desaprobar las versiones de guión de los parámetros donde las versiones de guión esencialmente ya se han eliminado (ya sea porque fueron obsoletas y eliminadas o porque había tan pocas en la naturaleza que no- uno los estaba usando). No hago ningún comentario sobre el RFC y sus parámetros asociados; el RFC esencialmente no discutió los parámetros identificados anteriormente, sin embargo, cierra.
"ref es igual al valor predeterminado": identifica las citas que no son necesarias, lo |ref=que significa que se puede eliminar el desorden de wikitext adicional. Eso me parece suficiente, y lo dije originalmente. ¿Qué encuentras poco claro? Izno ( charla ) 21:44, 3 de abril de 2021 (UTC)
Por qué este es un cambio necesario o beneficioso. La discusión vinculada proporciona algunas razones por las que un editor puede haber elegido incluir tales valores. Además, el RfC, aunque no se centró específicamente en estos parámetros, plantea preguntas sobre la práctica más amplia de desaprobar los alias sin guion que siguen a un RfC que no pretendía o requería los mismos. Nikkimaria ( charla ) 00:37, 4 de abril de 2021 (UTC)
... El desorden adicional de wikitext se puede eliminar es suficiente para ser un cambio necesario y beneficioso. Uno de los puntos de discusión desde siempre es que las citas abarrotan el wikitexto. Este cambio elimina un punto de desorden. No me han revertido a donde lo quité . Mi especulación es que las personas que usan (ya sea codificadas o con {{ sfnref }}) escribieron los artículos antes o no sabían o no saben que ni ni son necesarios. Veo que los tres son mucho más probables que los editores que los agregan deliberadamente solo para cumplir con una u otra de las especulaciones de MP como se indica en esa discusión.|ref=default_value|ref=default_value|ref=harv|ref=harv|ref=default_value|ref=harv
Aquí hay algunas razones más para eliminarlo aunque creo que lo anterior fue suficiente:
  1. Como se menciona allí, la harvpalabra clave también está obsoleta ya que es el comportamiento predeterminado para todas las plantillas, por lo que este cambio también hace que las plantillas sean más consistentes, es decir, solo necesita |ref=si necesita establecer algo en un valor no predeterminado (principalmente cuando no tiene autores o editores). Esto facilita la enseñanza a nuevos y antiguos usuarios.
  2. Tener innecesario sirve para confundir a los nuevos editores que pueden pensar que es siempre o incluso a veces necesario, cuando estrictamente no lo es.|ref=default_value
Ahora, ¿cree sinceramente que una de las cualidades en las especulaciones de MP era realmente interesante y, además, que es suficiente para anular el desorden y no enseñar a nuevos usuarios y puntos de coherencia ? No creo que ninguno de sus puntos tenga suficiente interés o carezca claramente de pruebas. Sea específico en su respuesta a lo que crea que es más importante, en lugar de señalar comentarios no específicos de su parte. Izno ( charla ) 02:12, 4 de abril de 2021 (UTC)
|doi-broken-date=sin |doi=ha sido un error desde la actualización del 3 de septiembre de 2019 . Esa actualización utilizada, doibroken_missing_doique se cambió a err_doibroken_missing_doila actualización del 10 de octubre de 2020 . Aquí hay una plantilla de ejemplo simple que muestra que |doi-broken-date=sin |doi=detección de errores ya es funcional (antes de la próxima actualización):
{{cite book |title=Title |doi-broken-date=April 2021}}→ Título . |doi-broken-date=requiere |doi=( ayuda )
|asin-tld=sin |asin=, |pmc-embargo-date=sin |pmc=y |class=sin |arxiv=detección de errores se agregó a la zona de pruebas en esta edición , se reescribió y la |class=detección de errores se eliminó en estas ediciones . Desde entonces, esta funcionalidad se ha dividido entre Module: Citation / CS1 / sandbox y Module: Citation / CS1 / Identifiers / sandbox para resolver los mensajes de error extraños señalados en Help talk: Citation Style 1 § asin & isbn . Debido a que |asin-tld=sin |asin=y |pmc-embargo-date=sin |pmc=detección de errores se agrupa junto con |doi-broken-date=sin |doi=detección de errores, lo incluí err_doibroken_missing_doien la lista anterior.
- Trapense el monje ( charla ) 22:22, 3 de abril de 2021 (UTC)
La discusión de RFC trata sobre los últimos seis parámetros sin guiones que aún no se han desaprobado. Los parámetros en desuso enumerados anteriormente quedaron obsoletos por consenso en esta página de discusión antes de que comenzara el nuevo RFC. No tiene sentido retrasar su desaprobación formal en el código del módulo, ya que ya no existen en una cantidad significativa en la naturaleza; Cualquier parámetro obsoleto perdido que se haya agregado después de que se verificaron y limpiaron los espacios de nombres afectados se pueden arreglar rápidamente. No habrá una ejecución masiva de bots ni montones de mensajes de error rojos. - Jonesey95 ( charla ) 00:55, 4 de abril de 2021 (UTC)
La pregunta que se hace allí es sobre parámetros sin guiones, punto. Nikkimaria ( charla ) 01:11, 4 de abril de 2021 (UTC)
Sí, esa era la pregunta. No ha sido la discusión, de ninguna forma. La discusión es casi exclusivamente si un bot antes de la desaprobación formal es apropiado y si es apropiado que ese bot realice otros cambios cosméticos y si es apropiado hacerlo con parámetros utilizados un millón de veces o más. Ciertamente no ha discutido los parámetros desaprobados por una discusión aquí. Izno ( charla ) 01:48, 4 de abril de 2021 (UTC)
Sin embargo, debido a que esa era la pregunta, se podría anticipar que el cierre abordará esa pregunta. De ahí la necesidad de esperar un resultado allí, en lugar de depender únicamente del consenso local aquí. Nikkimaria ( charla ) 01:56, 4 de abril de 2021 (UTC)
No, los cierres resumen la discusión, incluso si tiende a alejarse de la pregunta. Anticipo que la pregunta en el encabezado de esa discusión no aparecerá en absoluto en el resumen del cierre. Izno ( charla ) 02:21, 4 de abril de 2021 (UTC)
Re el predeterminado para |ref=. Esto se estableció en , como en el esquema de referencia breve del autor-fecha. El módulo ofrece programáticamente un objetivo para selectos anclajes de referencia corta como los generados por {{ harv }} (al mapear el autor y los parámetros de fecha en consecuencia). Eso haría que algo similar o similar sea redundante. O eso es lo que creo que esto significa, de todos modos. 98.0.246.242 ( conversación ) 01:45, 4 de abril de 2021 (UTC)|ref=harv|ref=harv
No, esta discusión trata sobre casos en los que una plantilla como {{cite book |last=Last |first=First |year=2020}}también lo ha hecho |ref=CITEREFLast2020. Ese valor es el mismo que el de las plantillas que se generan automáticamente hoy en día.
|ref=harvya estaba en desuso por separado cuando las plantillas estaban configuradas para hacerlo, en algún momento del año pasado. Izno ( charla ) 02:17, 4 de abril de 2021 (UTC)
Una observación. Puede que sea el momento de deshacerse de la parte "Estilo" del nombre del módulo. Esta colección de módulos y las aplicaciones (plantillas) basadas en él han evolucionado más allá de los elementos de estilo. Existen rutinas de verificación de errores para datos, llamadas a código externo y cumplimiento de estándares que no tienen nada que ver con la presentación. Se está convirtiendo en un formato de cita en toda regla en lugar de simplemente facilitar el formato estilístico de las citas. No hago ninguna representación sobre si esto es algo bueno o malo. 98.0.246.242 ( conversación ) 02:02, 4 de abril de 2021 (UTC)

Seguimiento de las actualizaciones del módulo [ editar ]

Parece que esta actualización ha desaprobado el guión correcto |series-no=, pero no veo una discusión sobre ese cambio. ¿Es esto un error, el cambio no se menciona arriba o es algo más? Pinging Trappist el monje . - Jonesey95 ( charla ) 13:39, 10 de abril de 2021 (UTC)

Esta edición de la caja de arena el 4 de abril (después de que se escribió la lista anterior) aparentemente corrige esta edición .
- Trapense el monje ( charla ) 14:03, 10 de abril de 2021 (UTC)

Otro problema: |issue=Novembercausas y error de texto adicional. Eso sucede debido a este patrón:

'^nos?[%.:=]?'- comienza con noo nosy puede ir seguido de un punto, dos puntos o un signo igual

Podríamos cambiar eso a:

'^nos?%W'- comienza con noo nosy debe ir seguido de un carácter que no sea una letra o un dígito

- Trapense el monje ( charla ) 14:03, 10 de abril de 2021 (UTC)

Apoyo la aplicación de estas dos correcciones de errores lo antes posible (especialmente porque parece que yo causé una de ellas). - Jonesey95 ( charla ) 14:09, 10 de abril de 2021 (UTC)
Sigo pensando en el |issue=tema.
|series-no= restaurado.
- Trapense el monje ( charla ) 14:25, 10 de abril de 2021 (UTC)

Chuj no es compatible en | idioma [ editar ]

He visto varios usos de Chuj en el parámetro de idioma. Su código 639-3 es cac, por lo que si alguien pudiera agregar soporte para él (o mostrarme cómo agregarlo a la lista) estaría muy feliz. ¡Gracias! Remagoxer ( charla ) 20:28, 3 de abril de 2021 (UTC)

cs1 | 2 solo admite idiomas conocidos por MediaWiki que no conocen todos los códigos de idioma ISO 639 . La lista de idiomas admitidos se encuentra en Template: Citation Style documentation / language / doc .
- Trapense el monje ( charla ) 22:35, 3 de abril de 2021 (UTC)
Soy consciente de esto: ¿tendría que ser un cambio de MW más profundo? Sin embargo, también he escuchado que las anulaciones manuales son posibles. Lo siento si estoy un poco confundido, no estoy exactamente seguro de en qué se incluiría este cambio. Remagoxer ( charla ) 23:42, 3 de abril de 2021 (UTC)
cs1 | 2 tiene la posibilidad de anular un nombre de idioma existente si MediaWiki conoce ese nombre de idioma. Por ejemplo, para el código bn, MediaWiki devuelve bengalí, que es el endónimo. Lo que quiere cs1 | 2 es el exónimo, bengalí, por lo que cs1 | 2 anula MediaWiki para representar correctamente el nombre del idioma.
MediaWiki algunas veces cambia los datos del nombre del idioma, pero nunca he logrado que cambien nada por mí. Quizás tengas mejor suerte.
- Trapense el monje ( charla ) 00:29, 4 de abril de 2021 (UTC)

error de lua con parámetro de acceso no válido [ editar ]

|doi-access=fre da esta belleza

  • Wild, Alexander L .; Cuezzo, Fabiana (2006). "Redescubrimiento de un linaje fósil de hormigas dolicoderinas (Hymenoptera: Formicidae: Dolichoderinae) y una descripción de un nuevo género de América del Sur". Zootaxa . 1142 : 57–68. doi : 10.11646 / zootaxa.1142.1.5 . hdl : 11336/85874 . Inválido |doi-access=fre( ayuda )

en lugar de un |doi-access=error no válido .

Esto debería arreglarse antes de la próxima actualización si es posible. Headbomb { t · c · p · b } 22:15, 3 de abril de 2021 (UTC)

Ya está arreglado; es la nota de 'corregir mensajes de error de nivel de acceso' en la notificación de actualización.
- Trapense el monje ( charla ) 22:28, 3 de abril de 2021 (UTC)

RFC sobre los parámetros de la plantilla de citas con guiones cerrados: ¿cómo proceder? [ editar ]

Se ha cerrado el RFC sobre parámetros sin guiones . Como cabría esperar al seguir la discusión, es un cierre de compromiso, pero creo que nos da una especie de camino a seguir.

Los seis sin guiones parámetros de varias palabras que quedan (por mi cuenta) - |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=(y su y variantes), y - se van a colocar en un nuevo (para nosotros) estado llamado "desarrollador desalentado", lo que significa esto: Como Por lo tanto, estos parámetros no deben anunciarse en la documentación, agregar categorías de mantenimiento ocultas (etc.) mientras siguen estando disponibles para su uso por editores de mucho tiempo. Los cinco o más parámetros de derechos adquiridos solo deberían desactivarse después de una discusión posterior que reciba una amplia atención y un claro consenso. Mientras tanto, cualquier editor debe sentirse libre de cambiar manualmente los parámetros sin guiones en sus formas con guiones mientras están haciendo otra cosa en una página.|authornlink=|authorlinkn=|origyear=

Esto significa que podemos continuar con nuestro trabajo para convertir parámetros sin guiones en parámetros con guiones, pero (por ahora) solo mientras hacemos otro cambio sustancial en la página, como corregir otro error de CS1.

Con respecto al código del módulo, creo que esto significa que deberíamos:

  1. Elimine las versiones sin guiones de esos parámetros de nuestra documentación.
  2. Cree una categoría de mantenimiento oculta llamada Categoría: CS1 maint: parámetro desalentado por el desarrollador o algo similar
  3. Cree un mensaje de mantenimiento oculto, por ejemplo, "parámetro desalentado por el desarrollador |accessdate=(ayuda)" o "parámetro |accessdate=utilizado ( |access-date=sugerido) (ayuda) no recomendado por el desarrollador"

También podríamos modificar las reglas de "arreglos generales" de AWB para reemplazar los parámetros sin guiones de modo que se corrijan cuando un editor realiza un cambio sustancial en un artículo usando AWB. Tenga en cuenta que hubo un retroceso cuando se realizó este cambio el año pasado.

¿Hay más que deberíamos hacer? Los comentarios, correcciones, adiciones y sugerencias son bienvenidos. - Jonesey95 ( charla ) 17:49, 6 de abril de 2021 (UTC)

Lo que realmente quiero saber, lo que realmente quiero saber, es ¿cómo me perdí |airdate=? Después de todo esto, ese parámetro se pasó por alto por completo. ¡Argh!
No sé qué pensar sobre el desarrollador desanimado . Fuera del RFC, ¿existe tal cosa? Google arrojó solo 152 resultados para la cadena entre comillas ... uno de ellos, el RFC. La obsolescencia (al menos según yo la entiendo dentro del alcance de cs1 | 2) es "desalentador del desarrollador"; es decir, la desaprobación es el punto en el que comenzamos formalmente a desalentar el uso de algo. Por ejemplo, "desaconsejamos" el uso de porque ninguno de nosotros es lo suficientemente inteligente como para escribir código que pueda analizar de manera confiable una lista de forma libre de nombres humanos para que esos nombres puedan incluirse en los metadatos de la cita. Pero, debido a que hay 22k-ish artículos en Categoría: CS1 maint: texto adicional: lista de autores , no estamos dispuestos a despreciar bastante todavía.|authors=
Eliminar los parámetros sin guiones de la documentación es simple y directo. No estoy tan seguro de la categoría o el mensaje de mantenimiento. Una categoría con un millón o más de artículos parece tan grande que sería desagradable para cualquier persona interesada en corregir esos artículos. Agregar mensajes de mantenimiento normalmente no será un problema, pero para los artículos grandes que se acercan al límite de tamaño de inclusión posterior a la expansión, podría llevarlos al límite y generar enojo antes de que estos parámetros sean oficialmente obsoletos.
Podríamos proponer una versión 'solo para bots' de GENFIXES para que los |accessdate=bots de AWB puedan arreglar, etc., que hagan otras cosas sin imponer la carga a los usuarios normales de AWB que también quieren ejecutar AWB con GENFIXES activado. No aguantaré la respiración por esto porque es un propósito bastante especial.
- Trapense el monje ( charla ) 20:05, 6 de abril de 2021 (UTC)
¿Qué? ¿Trapense no es perfecto? ¿Trapense perdido |airdate=? Para aquellos de nosotros que cometemos errores más de una vez al mes, esto fue, francamente, un alivio. Bienvenido al club, amigo. (Solo mencioné |airdate=una vez en la discusión de RFC de 27,000 palabras, y esa discusión fue dolorosa de visitar, así que puedo ver por qué se perdió).
No sé qué pensar acerca de la frase adjetiva aparentemente inventada "desarrollador-desanimado" (he insertado un guión aquí y arriba, pero no soy lo suficientemente pedante como para tratar de corregir el RFC más de cerca) tampoco, cuando tenemos tenía el concepto perfectamente bueno de la desaprobación durante mucho tiempo. Sin embargo, creo que hay suficiente guía en el RFC para que la usemos como el más cercano pretendía.
Creo que una categoría oculta de más de un millón de artículos está bien (ver Categoría: Personas vivas , por ejemplo), especialmente porque nuestra intención es hacerla más pequeña. Podemos usar esa categoría para encontrar usos de plantilla perdidos de los parámetros que han pasado desapercibidos. Podemos usarlo para ejecutar búsquedas de Petscan y búsquedas en fuentes que nos permitan encontrar artículos donde un bot o un editor de AWB podría dividir los parámetros con guiones mientras realiza un cambio visible (por ejemplo, accessdate y ref = harv , actualmente 10,000 artículos). Podemos rastrear su tamaño a lo largo del tiempo para evaluar la viabilidad de desaprobar y eliminar la compatibilidad con los parámetros en algún momento.
Puedo vivir sin un mensaje oculto. El RFC y su cierre pueden parecer una barrera al principio, pero creo que nos dejan algo de espacio para seguir adelante. Wikipedia, un proyecto grupal dirigido por humanos; las cosas no siempre salen de la mejor manera, pero progresan hacia la cordura con el tiempo. - Jonesey95 ( conversación ) 20:48, 6 de abril de 2021 (UTC)
Le he pedido al vendedor alguna aclaración sobre una frase poco clara. Además, no me preocupan los mensajes ocultos que hacen que las páginas superen el tamaño de expansión de la plantilla. Me complacería monitorear la intersección de esa categoría y la nueva categoría de mantenimiento y solucionar el problema de expansión arreglando los parámetros. - Jonesey95 ( conversación ) 21:24, 6 de abril de 2021 (UTC)
La forma más sencilla de hacer la categoría es tratar la categoría como una propiedad cat: Categoría: CS1 tiene un parámetro desalentado por el desarrollador o algo así. Podemos marcar los seis parámetros en Module: Citation / CS1 / Whitelist con algún tipo de código secreto (me discouragedviene a la mente) y luego modificar validate()para detectar ese código secreto de la misma manera que detecta los falseparámetros obsoletos. validate()luego llama utilities.add_prop_cat()para agregar la categoría. Los parámetros obsoletos vacíos hacen que una cita tenga un parámetro desconocido vacío:|<param>= error; los parámetros vacíos desalentados harían lo mismo.
Parecería que ahora es el momento de actuar (antes de la actualización pendiente) si es que vamos a actuar en absoluto.
- Trapense el monje ( charla ) 21:47, 6 de abril de 2021 (UTC)
Estoy de acuerdo, y el enfoque de detección y el tiempo parecen sólidos, si tiene tiempo para codificarlo. Sería bueno escuchar a otros observadores de la página, pero el RFC y esta nota del más cercano brindan una guía en la que podemos apoyarnos para lograr un consenso. Creo que los mensajes de texto deben ser verdes y estar ocultos de forma predeterminada (o inexistentes; no estoy adjunto a ellos). En cuanto al nombre del gato, ¿qué tal Categoría: CS1: parámetro desalentado por el desarrollador , que parece coincidir con el patrón de las categorías de "propiedades" creadas recientemente? Estaré encantado de escribir una descripción y algunas orientaciones para la página de categoría. - Jonesey95 ( charla ) 22:28, 6 de abril de 2021 (UTC)
Los mensajes de mantenimiento están ocultos por defecto (existen en artículos visibles o no). Supongo que, en última instancia, los gatos de mantenimiento son mejores porque son visibles, por lo que los editores que los ven pueden estar más dispuestos a corregir. Dado que el vendedor parece preferir los mensajes de mantenimiento ... El nombre de la categoría sería Categoría: CS1 mantenimiento: parámetro desalentado por el desarrollador .
- Trapense el monje ( charla ) 22:46, 6 de abril de 2021 (UTC)
Versión de mantenimiento:
{{cite book/new |title=Title |url=//example.com |accessdate=2021-04-06}}→ Título . Consultado el 6 de abril de 2021 .
{{cite book/new |title=Title |url=//example.com |accessdate=}}→ Título .
{{cite book/new |title=Title |url=//example.com |accessdate=2021-04-XX}}→ Título . Consultado el 20 de abril de 2021 . Verifique los valores de fecha en: |accessdate=( ayuda )
{{cite episode/new |series=Series |airdate=2021-04-06}}→ Serie . 2021-04-06.
{{cite book/new |title=Title |url=//example.com |archiveurl=//archive.org |archive-date=2021-04-06}}→ Título . Archivado desde el original el 6 de abril de 2021.
{{cite book/new |title=Title |url=//example.com |archive-url=//archive.org |archivedate=2021-04-06}}→ Título . Archivado desde el original el 6 de abril de 2021.
{{cite book/new |title=Title |author=Blue |authorlink=Blue}}→ Azul . Título .
{{cite book/new |title=Title |author=Blue |authorlink1=Blue}}→ Azul . Título .
{{cite book/new |title=Title |author=Blue |author1link=Blue}}→ Azul . Título .
{{cite book/new |title=Title |date=2021 |origyear=1700}}→ Título . 2021 [1700].
- Trapense el monje ( charla ) 00:40, 7 de abril de 2021 (UTC)
No creo que "Cite tiene un parámetro desconocido vacío: fecha de acceso" sea una redacción precisa para un parámetro admitido (consulte el segundo ejemplo anterior). - Jonesey95 ( conversación ) 04:10, 7 de abril de 2021 (UTC)
Ok, cambiado.
- Trapense el monje ( charla ) 12:51, 7 de abril de 2021 (UTC)
"Desarrollador desanimado" suena realmente extraño. Llamemos a este nuevo estado "desalentado" en el nombre de la categoría y el mensaje.
- Matthiaspaul ( charla ) 09:33, 7 de abril de 2021 (UTC)
Ok, cambiado.
- Trapense el monje ( charla ) 12:51, 7 de abril de 2021 (UTC)
El mensaje oculto podría mejorarse aún más sugiriendo un parámetro de reemplazo si hay un reemplazo definido en la lista de sugerencias (como hacemos para la mayoría de los parámetros que ya no son compatibles). Esto se aplicaría a estos nuevos parámetros "desaconsejados", así como a los denominados parámetros obsoletos.
- Matthiaspaul ( charla ) 11:41, 7 de abril de 2021 (UTC)
Eso convertiría la mensajería de un mensaje de mantenimiento a un mensaje de error. No creo que debamos crear un mensaje de mantenimiento único especial para esta o cualquier otra condición de mantenimiento.
- Trapense el monje ( charla ) 12:51, 7 de abril de 2021 (UTC)
Los comentarios fueron bienvenidos por el OP, así que: esta tempestad en una tetera terminó de manera bastante apropiada, con un quejido (por ahora). En tales casos, la mediocridad obvia a menudo se ve reforzada por la introducción de nuevos términos para adaptarse a las contorsiones de la decisión. No culpo al cerrador por dividir al bebé por la mitad. Este RFC era frívolo, pero ¿y qué? Cientos lo son. Por otro lado, esta colección de módulos está sobrecategorizada. La respuesta a todo a veces parece ser, vamos a tener otra categoría (de cualquier tipo, pero las que generan errores son obviamente las que levantan los pelos de punta a la gente). Así que ahora se quitarán valiosos recursos humanos para optimizar los módulos y racionalizar su diseño, y se harán para asegurar que el descontento de los desarrolladores (tut tut tut) por un tema que no sea un problema esté adecuadamente representado.El único entretenimiento con respecto al RFC y esta discusión es la broma de Jonesey sobre el "progreso".72.43.189.156 ( conversación ) 22:58, 6 de abril de 2021 (UTC)
Re: retroceso de AWB : Creo que las ~ 2.8 millones de |accessdate=páginas entonces fueron el factor decisivo, más que las ahora solo ~ 30k páginas (¡en |authorlink=comparación con ~ 330k hace 5 meses!) Con alias sin guiones hasta 5. No solo eso, sino el número de |accessdate=por página era muy prohibitivo. Hay muchos menos |authorlink=por página, especialmente ahora después de la estandarización de Monkbot y otros, que es mucho menos oneroso volver a agregar a WP: GENFIXES .
Una forma de sortear lentamente la |accessdate=carga de GENFIXES sería dividir con guiones 1 plantilla de cita al principio, en lugar de todas a la vez. Luego, cada pocas semanas, meses o lo que sea necesario para que la |accessdate=cuenta regresiva de esa plantilla sea insignificante, agregue otra plantilla de cita para separar la fecha de acceso y repita hasta que se incluyan todas las plantillas. Quizás esto pueda iniciarse después de que el |authorlink=recuento esté en el rango de ~ 1k.    ~  Tom.Reding ( talk ⋅ dgaf )   03:02, 7 de abril de 2021 (UTC)
Agregué algunas líneas de cambio de nombre de parámetros a los genfixes de AWB, pero un editor que no parece estar de acuerdo con el RFC me revirtió . No tengo interés en editar la guerra y no uso AWB, pero es posible que otros editores quieran participar allí. - Jonesey95 ( charla ) 03:51, 7 de abril de 2021 (UTC)

Estoy luchando por entender por qué este es un cierre de compromiso.

  1. Mientras que antes podíamos hacer cambios cosméticos en la división de palabras mientras hacíamos otros trabajos de bot, ahora solo se puede hacer manualmente. AWB es semiautomático.
  2. Cambiar manualmente millones de citas equivale a eso no sucederá.
  3. Cambiar los documentos es una hoja de parra. La gente suele seguir ejemplos o hábitos, a veces los documentos.

A mí me parecen dos grandes pasos hacia atrás (n. ° 1 y n. ° 2) y un paso muy pequeño hacia adelante (n. ° 3). Eliminaré la función cosmética de separación de palabras de mis bots. Sugeriría que antes de comenzar RfC # 2, recopile información sobre cuántos guiones frente a no guiados se agregan durante un período de un mes. Olvídese de la huella del legado, vea qué está haciendo la comunidad en este momento para determinar mejor qué se debe hacer en el futuro en función del consenso actual. También mitigará a cualquier minoría ruidosa que tiende a dominar VP. - Green C 04:46, 7 de abril de 2021 (UTC)

No estoy de acuerdo con el punto 1 anterior. El cierre decía: Monkbot 18 no debe ejecutarse únicamente para reemplazar los parámetros sin guiones que se desaconsejan. [...] Con tantas objeciones a la ejecución de la sección de "guiones cs1 | 2 nombres de parámetros" de Monkbot 18, es difícil decir que hay consenso para promulgarlo, excepto si se incluyó con cambios no cosméticos ...(Los puntos suspensivos eliminan algunas cosas que no tienen ningún sentido o que no son relevantes aquí). Para mí, esto se lee como "Si un bot está haciendo cambios cosméticos en los nombres de los parámetros y ningún otro cambio en la página, eso no está permitido. Si un bot (o un editor humano) está realizando un cambio sustancial en la página, está bien actualizar los nombres de los parámetros ". Ambas oraciones citadas afirman o implican que el reemplazo de parámetros junto con cambios sustanciales son ediciones de bot permitidas. - Jonesey95 ( charla ) 06:10, 7 de abril de 2021 (UTC)
Sí. Lo leo de la misma manera. Por lo tanto, actualizar los parámetros desaconsejados a otros totalmente compatibles mientras se realizan otras ediciones no cosméticas sigue siendo aceptable para humanos y bots. - Matthiaspaul ( charla ) 09:54, 7 de abril de 2021 (UTC)
Estoy de acuerdo.
@ MJL : vea las interpretaciones ambiguas de su cierre anterior con respecto al uso de la palabra " manualmente ". No creo que este RFC tenga el "poder" de restringir AWB / JWB / etc. que los usuarios no realicen guiones, siempre que también realicen ediciones importantes ( WP: AWBRULES # 4). AWB / JWB / etc. se conocen como herramientas "semiautomáticas", por lo que sugeriría cambiar " manualmente " a " manual o semiautomáticamente ".   ~ Tom.Reding ( talk ⋅ dgaf )   11:41, 7 de abril de 2021 (UTC) 
@ Tom.Reding : Sí, de forma manual o semiautomática siempre fue la intención. Eso está arreglado ahora. - MJL - Charla - ☖ 18:05, 7 de abril de 2021 (UTC) 

Historias rotas [ editar ]

No estaba siguiendo todo este debate tan de cerca, así que tal vez esto se cubrió, pero me decepciona ver que cualquier resultado que haya roto un montón de historiales de páginas, generando errores en las secciones de referencia. Consulte, por ejemplo, Special: Permalink / 843704571 # References . {{u | Sdkb }}  charla 21:51, 11 de abril de 2021 (UTC)

|deadurl=y |dead-url=quedaron obsoletos en la actualización del conjunto de módulos del 3 de septiembre de 2019. El soporte para estos parámetros se retiró en la actualización del conjunto de módulos del 11 de enero de 2020. Esas acciones no tienen nada que ver con el RFC recientemente cerrado.
- Trapense el monje ( charla ) 22:06, 11 de abril de 2021 (UTC)

RFC vuelto a cerrar [ editar ]

La RFC se ha vuelto a cerrar a favor de continuar apoyando los seis parámetros restantes sin guiones. Por favor, ajuste sus scripts y bots en consecuencia. Es de suponer que tendremos que realizar algunos ajustes en el código de la zona de pruebas. Ya modifiqué el Módulo: Cita / CS1 / Lista blanca / caja de arena y el Módulo: Cita / CS1 / Sugerencias / caja de arena . - Jonesey95 ( conversación ) 15:37, 15 de abril de 2021 (UTC)

Ayuda con una cita [ editar ]

Estaré enlazando las URL de guardado en aproximadamente 10,000 citas a la base de datos de películas del New York Times, y mientras esté allí también actualizando los metadatos, no estoy seguro de cómo proceder. Ejemplo:

{cite news |url=https://movies.nytimes.com/movie/11238/The-Court-Martial-of-Jackie-Robinson/overview |title=The Court Martial of Jackie Robinson (1990) |work=[[The New York Times]] |access-date=December 9, 2019 |archive-url=https://web.archive.org/web/20140103141030/http://www.nytimes.com/movies/movie/11238/The-Court-Martial-of-Jackie-Robinson/overview |archive-date=January 3, 2014 |url-status=dead}}

La página está alojada en el NYT, pero el contenido está protegido por derechos de autor de All Movie Guide como se ve en la parte inferior de la página. El NYT obtuvo la licencia del contenido de un tercero, y ahora que la licencia ha expirado, las páginas son enlaces muertos. El NYT no creó el contenido ni lo poseyó, sino que lo alojó y lo calificó. La pregunta es cuál es la mejor forma de citarlo. Algunas ideas:

  1. |work=The New York Times
  2. |work=All Movie Guide, |via=The New York Times
  3. |work=The New York Times, |via=All Movie Guide
  4. |work=The New York Times, |publisher=All Movie Guide
  5. |work=All Movie Guide, |publisher=The New York Times
  6. |work=The New York Times, |agency=All Movie Guide

Para complicar aún más, también hay un aviso de derechos de autor de Baseline StudioSystems en la parte inferior de la página, además de All Movie Guide. - Green C 05:24, 7 de abril de 2021 (UTC)

No me angustiaría por cuestiones de derechos de autor. Los derechos de autor de NYTMDb y sus enlaces al contenido pertenecen a NYT, y lo que se cita es un enlace. Suponiendo que se conservarán las citas originales, los lectores accederán al contenido que prueba el wikitexto a través del archivo. El contenido es por definición estático: ni la información de la película ni los créditos parecen estar sujetos a cambios. Yo agregaría |department=Moviesy . 24.103.251.114 ( conversación ) 12:30, 7 de abril de 2021 (UTC)|via=archive-name
En caso de que no esté claro, no me refiero a archivos iniciados por el editor. Lo anterior se aplica solo a los archivos oficiales / autorizados del NYT. Bajo el supuesto de que dichos archivos tienen derechos de autor adecuados de las partes interesadas. 24.103.251.114 ( conversación ) 12:41, 7 de abril de 2021 (UTC)

No se trata solo de avisos de derechos de autor, consulte, por ejemplo, [3] que está firmado "Hal Erickson, Rovi" (Rovi = All Movie Guide). El NYT no es la fuente subyacente u original, el Times lo autorizó por un tiempo y ya no lo hace. Ayudará a nuestros lectores a conocer las fuentes de este contenido a otras entidades, en caso de que los archivos no estén disponibles o no estén disponibles actualmente. - Green C 14:48, 7 de abril de 2021 (UTC)

Es recomendable que desee proporcionar un camino para la verificación, pero creo que esto va más allá de lo que normalmente se esperaría de una cita. Ciertamente excede los requisitos de la política e incluso las prácticas recomendadas. AFAIK, no mencionan una fuente de segundo nivel (fuente de una fuente). Estás en un territorio no planificado. Recomendaría una {{ nota de enlace }}. 98.0.246.242 ( conversación ) 19:17, 7 de abril de 2021 (UTC)

¿Qué tal algo completamente diferente? [ editar ]

Ayer modifiqué un montón de estructuras cs1 | 2 TemplateData. No utilizo ninguna herramienta que use TemplateData; Creo que TemplateData es una mala elección de diseño que intenta ser tanto documentación como control. Puede funcionar bien en cualquier función de control que se supone que debe hacer, pero en lo que respecta a la documentación, es un error (no puede admitir el marcado de wiki que pierde completamente la marca en un wiki).

Independientemente, la forma estructurada de TemplateData tiene algunos beneficios ya que está 'estructurada' (que la documentación 'oficial' ciertamente no lo es). Mientras hacía los ajustes que hice ayer, noté que casi todos los TemplateData identifican los parámetros cs1 | 2 que ya no son compatibles o no son compatibles con 'esa' plantilla. Debido a que cs1 | 2 mantiene una lista de parámetros que son compatibles con Module: Citation / CS1 / Whitelist , se me ocurrió que podía escribir una función lua para comparar lo que TemplateData piensa que son parámetros compatibles y lo que ~ / Whitelist sabe que son parámetros compatibles. . Así que lo hice:

{{#invoke:cs1 documentation support|template_data_validate|{{ROOTPAGENAME}}}}

se puede agregar a la página de documentos de una plantilla cs1 | 2 en §TemplateData. O se puede colocar en otro lugar, como esta página:

{{#invoke:cs1 documentation support|template_data_validate|cite web}}
Plantilla: Cite web / doc TemplateData tiene errores:
  • |editor2link= alias no válido de: |editor2-link=
  • |editor3link= alias no válido de: |editor3-link=
  • |editor4link= alias no válido de: |editor4-link=
  • |editor5link= alias no válido de: |editor5-link=
  • |editor6link= alias no válido de: |editor6-link=
  • |editor7link= alias no válido de: |editor7-link=
  • |editor8link= alias no válido de: |editor8-link=
  • |editor9link= alias no válido de: |editor9-link=
  • |editorlink2= alias no válido de: |editor2-link=
  • |editorlink3= alias no válido de: |editor3-link=
  • |editorlink4= alias no válido de: |editor4-link=
  • |editorlink5= alias no válido de: |editor5-link=
  • |editorlink6= alias no válido de: |editor6-link=
  • |editorlink7= alias no válido de: |editor7-link=
  • |editorlink8= alias no válido de: |editor8-link=
  • |editorlink9= alias no válido de: |editor9-link=

Sin duda, no es perfecto, pero quizás ayude a mantener TemplateData sincronizado con ~ / Whitelist y quizás, solo quizás, veremos menos errores acumulados en las categorías de error cs1 | 2. Se solicitan sugerencias de mejora.

- Trapense el monje ( charla ) 22:40, 8 de abril de 2021 (UTC)

El peor problema con TemplateData es que nadie llegó a hacerlo para que pudiéramos documentar los parámetros enumerados con cordura. Es abrumador trabajar en la lista cuando tienes que recorrer 30 parámetros todos para la misma idea (multiplicado por 15 plantillas). Izno ( charla ) 23:18, 8 de abril de 2021 (UTC)
Hay un error de fabricador para esto. T54582 - Salix alba ( charla ): 14:15, 11 de abril de 2021 (UTC)
De todos modos, herramienta genial. Podría ser interesante construir alguna herramienta más general para verificaciones de plantillas y / o módulos no i18n entre TemplateData y lo que se implementa. Izno ( charla ) 23:19, 8 de abril de 2021 (UTC)
A veces pienso en una variante de esto cuando estoy editando una plantilla que realiza una verificación de parámetros no admitidos. ¿Por qué mantener una lista de parámetros válidos mantenida por humanos cuando un módulo puede leer el wikitexto de la plantilla real para compararlo con el marco principal?
- Trapense el monje ( charla ) 11:09, 9 de abril de 2021 (UTC)
¿Alguien está manteniendo activamente TemplateData como un proyecto? Cualquier cosa que mejore la interacción con el módulo es algo bueno, siempre que el desarrollo cruzado no se descarrile porque TemplateData tiene su propia hoja de ruta. Existe la ventaja de una documentación algo estructurada, pero seguramente la documentación nativa también podría formatearse mediante programación. Para mí, este sería un proyecto más valioso que preocuparse por si los editores tendrán que lidiar con parámetros separados por guiones. 24.103.101.218 ( conversación ) 12:35, 9 de abril de 2021 (UTC)
Añadido a todo CS1 | 2 plantillas que tienen TemplateData ( , , , , No). Dejaré que aquellos que se preocupan por TemplateData corrijan los errores.{{cite AV media notes}}{{cite map}}{{cite serial}}{{cite speech}}{{cite techreport}}
- Trapense el monje ( charla ) 13:43, 9 de abril de 2021 (UTC)
Gracias por este rigor, trapense. Este tipo de mantenimiento de documentos basado en módulos es una de las primeras cosas que hice con {{ Control de autoridad }}, y me ha ahorrado mucho tiempo, esfuerzo y cordura.
Al intentar eliminar los |editorlink=parámetros, no pude decir por el documento y TemplateData contradictorio (y una pequeña inconsistencia en el documento) cuál es el parámetro canónico y cuál es el alias (supongo que podría ignorar el TD, pero más bien escúchalo de la fuente ). Módulo: Citation / CS1 / Whitelist sugiere sutilmente (en virtud de aparecer primero en la tabla) que |editor-link#=es la versión canónica y |editor#-link=es su alias. De manera similar, con |editor-first#=as cannon & |editor#-first=como su alias, y así sucesivamente con todos los parámetros numerados. Si es así, ¿esto también se aplica a todos los # = <1 | nulos> params como |author-link1=, |author1-link=, |author-link=, (es decir, de cañón, alias, alias, respectivamente) o hay un esquema diferente para estos?    ~  Tom.Reding (talk ⋅ dgaf )   14:44, 9 de abril de 2021 (UTC)
No creo que haya ninguna preferido oficialmente forma de nombre de parámetro cuando hay que elegir entre no enumerado y enumerado ( |author-link=y |author-link1=o |author-link=y |author1-link=). No creo que haya ninguna forma oficialmente preferida de nombre de parámetro cuando la elección está entre las formas enumeradas ( |author-link1=y |author1-link=. En todos los casos son totalmente equivalentes.
Entonces, supongo que se trata de preferencias. Para mí, esa preferencia es: |author-link=→ |author-link1=→ |author1-link=. Sería mejor si todos estos tipos de parámetros siguieran el mismo patrón parámetro a parámetro y plantilla a plantilla.
- Trapense el monje ( charla ) 16:32, 9 de abril de 2021 (UTC)
Encontré un error de codificación menor, pero no sé el lugar correcto en el código para solucionarlo. El mensaje de alias se representa como:
* <código de estilo = "color: herencia; fondo: herencia; borde: ninguno; relleno: herencia"> | ISBN13 = </code> alias no válido de: | isbn = </code>
Tenga en cuenta la </code>etiqueta extra o la <code>etiqueta que falta . - Jonesey95 ( conversación ) 13:42, 11 de abril de 2021 (UTC)
Arreglado eso.
- Trapense el monje ( charla ) 14:02, 11 de abril de 2021 (UTC)
|ISBN13=& |isbn13=se marcaron como errores en Template: Cite book / TemplateData , pero ambos se muestran como "verdaderos" en la lista blanca. Plantilla: Cite book / doc actualmente dice que |ISBN13=& |isbn13=son alias de |isbn=, lo que no se refleja en el TD. ¿Debería restablecerse ISBN13 / isbn13 en el DT o eliminarse de la plantilla de documento correspondiente?   ~  Tom.Reding ( talk ⋅ dgaf )   13:05, 11 de abril de 2021 (UTC)
Sí, son alias. Los parámetros ISBN13 e ISBN son sinónimos en Módulo: Cita / CS1 / Configuración . Izno ( charla ) 13:24, 11 de abril de 2021 (UTC)
De acuerdo con esta búsqueda de cirros , |isbn13=y |ISBN13=rara vez se utilizan. Las plantillas cs1 | 2 aceptan solo un |isbn=parámetro, así que ¿realmente necesitamos |isbn13=y |ISBN13=? Creo que no, así que estos deberían ser reemplazados silenciosamente por |isbn=y los otros dos en desuso.
- Trapense el monje ( charla ) 14:02, 11 de abril de 2021 (UTC)
|isbn13=y el |ISBN13=problema está solucionado.
- Trapense el monje ( charla ) 17:20, 11 de abril de 2021 (UTC)
|orig-date=aparece en Plantilla: Cite arXiv / doc pero está marcado como 'parámetro no válido' en Plantilla: Cite arXiv / doc # TemplateData .   ~  Tom.Reding ( talk ⋅ dgaf )   14:04, 13 de abril de 2021 (UTC)
Reparado. El árbitro final aquí es Module: Citation / CS1 / Whitelist . es una plantilla pre-impresión por lo que se ve obligado a utilizar sólo los parámetros que figuran en , , y .{{cite arxiv}}limited_basic_arguments{}limited_numbered_arguments{}preprint_arguments.arxiv{}
- Trapense el monje ( charla ) 14:25, 13 de abril de 2021 (UTC)
|orig-date=todavía se muestra para Template: Cite bioRxiv / doc # Date & Template: Cite ssrn # Date , y no estoy seguro de cómo corregirlos. Una edición nula no funcionó, pero |orig-date=ahora está correctamente oculta en Plantilla: Cite arXiv # Fecha .   ~  Tom.Reding ( talk ⋅ dgaf )   14:47, 13 de abril de 2021 (UTC)

name-list-format = todavía en el espacio del artículo [ editar ]

Matthiaspaul y otros editores a los que les gusta eliminar parámetros no admitidos: parece que en algún lugar alrededor de más de 300 usos de |name-list-format=en el espacio del artículo se pasaron por alto o se agregaron después de enero . - Jonesey95 ( charla ) 23:03, 10 de abril de 2021 (UTC)

Eso es interesante. Antes de deshabilitar el parámetro en ese entonces ( Help_talk: Citation_Style_1 / Archive_74 # Removal_of_no_longer_used_name-list-format = _in_sandbox ) verifiqué ( [4] ) que el parámetro ya no estaba en uso en el espacio principal (de lo contrario, no lo habría deshabilitado). Entonces, o debo haber cometido un error al ejecutar esa verificación o la búsqueda de Cirrus no fue precisa. Afortunadamente, el número de visitas es lo suficientemente bajo como para corregirlo manualmente.
- Matthiaspaul ( charla ) 09:43, 11 de abril de 2021 (UTC)
La búsqueda de Cirrus, al igual que los enlaces de categorías de alguna manera, no garantiza una actualización de su índice si no se ha realizado ninguna edición en una página recientemente. Esta cola larga es bastante rutinaria cuando se trabaja en esta área. La única forma de garantizarlos es sacar una instantánea de la base de datos y buscar allí. Izno ( charla ) 13:26, 11 de abril de 2021 (UTC)
(A veces también se debe a reversiones a versiones anteriores a las que buscó). Izno ( hablar ) 13:27, 11 de abril de 2021 (UTC)
Sin preocupaciones; la búsqueda no siempre devuelve el 100% de lo que está disponible y, como dice Izno, las reversiones y los retrasos extraños pueden hacer que las búsquedas pierdan cosas. También encontré media docena de usos en el espacio de la plantilla, pero creo que los he solucionado todos. - Jonesey95 ( charla ) 13:34, 11 de abril de 2021 (UTC)

nombres de autor basura [ editar ]

Hoy me encontré con una plantilla cs1 | 2 que tenía parámetros de nombre de autor como estos del aeropuerto Nikola Tesla de Belgrado :

|last=link|first=Get|last2=Facebook|last3=Twitter|last4=Pinterest|last5=Email|last6=Apps|first6=Other

Suspiro. Tal vez CS1 | 2 debe alarmar cuando los parámetros de nombre incluyen: Facebook, Twitter, Pinterest, Email, y, sin duda, otros.

En la actualidad no hay tantos:

Correo electrónico: ~ 130
Facebook: ~ 140
Google: ~ 260 (tiempo de espera agotado)
Instagram: ~ 20
LinkedIn: ~ 50
Pinterest: ~ 90
Tumblr: ~ 30
Gorjeo: ~ 400

Pero, por desgracia, si no hacemos nada, el número de estas plantillas de autor falso aumentará ...

- Trapense el monje ( charla ) 14:23, 11 de abril de 2021 (UTC)

Por desgracia. También podríamos intentar detectar tonterías de editor perezoso infligidas por VE como esta . - Jonesey95 ( charla ) 14:53, 11 de abril de 2021 (UTC)
Esos probablemente deberían ser un informe Phab independientemente. Izno ( charla ) 15:59, 11 de abril de 2021 (UTC)
Ve a por ello. Estoy inmensamente cansado de enviar errores de VE a phab y dejarlos sin resolver durante años. - Jonesey95 ( charla ) 16:10, 11 de abril de 2021 (UTC)
He modificado Module: Citation / CS1 / sandbox y ~ / Configuration / sandbox para que el módulo detecte los nombres falsos de autor / colaborador / editor / entrevistador / traductor enumerados anteriormente:
{{cite book/new |title=Title |last=Facebook}}
Facebook. Título . |last=tiene nombre genérico ( ayuda )
{{cite book/new |title=Title |last=Someone |first=Tumblr}}
Alguien, Tumblr. Título . |first=tiene nombre genérico ( ayuda )
{{cite book/new |title=Title |last=Someone |translator=Google}}
Alguien. Título . Traducido por Google. |translator=tiene nombre genérico ( ayuda )
La prueba solo prueba los 'nombres' cuando el 'apellido' no tiene un nombre falso. Esto se debe a que no es necesario tener una lista de mensajes de error esencialmente duplicados:
{{cite book/new |title=Title |last=Facebook |first=Twitter}}
Facebook Twitter. Título . |last=tiene nombre genérico ( ayuda )
La prueba deja de buscar nombres falsos una vez que se ha encontrado uno:
{{cite book/new |title=Title |last=link|first=Get|last2=Facebook|last3=Twitter|last4=Pinterest|last5=Email|last6=Apps|first6=Other}}
enlace, Obtener; Facebook; Gorjeo; Pinterest; Correo electrónico; Aplicaciones, Otro. Título . |last2=tiene nombre genérico ( ayuda )
Como parte de este ajuste, modifiqué el código que detecta títulos genéricos para que no tengamos que mantener dos funciones para hacer pruebas básicamente idénticas. Para demostrar que no he roto nada:
{{cite book/new |title=Are you a robot? |last=Someone |first=}}
Alguien. ¿Eres un robot? . Citar utiliza un título genérico ( ayuda )
- Trapense el monje ( charla ) 15:56, 12 de abril de 2021 (UTC)
¿Has visto en cuántos temas es experto el autor llamado "Superusuario"? Cuando los patrulé, hace algunos años, algunos eran genuinos, en el sentido de que el nombre del autor "Superusuario" era visible en la página citada, pero la mayoría de ellos simplemente se copiaron de los metadatos de sitios web que no se han publicado. configurado correctamente. - Juan de Lectura ( charla ) 16:24, 12 de abril de 2021 (UTC)
Adicional:
{{cite journal/new |last1=User |first1=Super |title=Penicillium species A |website=www.aspergilluspenicillium.org |url=https://www.aspergilluspenicillium.org/9-penicillium/53-aspergillus-species-a |language=en-gb}}
Usuario, Super. "Especie A de Penicillium" . www.aspergilluspenicillium.org . |last1=tiene nombre genérico ( ayuda )
- Trapense el monje ( charla ) 16:53, 12 de abril de 2021 (UTC)
Eso está bien, excepto que deberíamos permitir anular el cheque. Ya admitimos el marcado (( accept-this-as-writing )) para este conjunto de parámetros. El mensaje de error no debería aparecer si se utiliza (por ejemplo, en el caso de que "Superusuario" sea el nombre correcto (avatar) del autor como lo menciona John). - Matthiaspaul ( charla ) 19:45, 13 de abril de 2021 (UTC)

Usando volume = con cite book [ editar ]

El uso del parámetro volume = ahora arroja un error cuando se incluye texto. Muchos libros de varios volúmenes tienen títulos, por ejemplo:

  • Calambre, Stanley , ed. (1985). " Ceryle rudis Pied Kingfisher". Manual de las aves de Europa, Oriente Medio y Norte de África. Las aves del Paleártico occidental . Volumen IV: Charranes a pájaros carpinteros. Oxford: Prensa de la Universidad de Oxford. págs. 723–731. ISBN 978-0-19-857507-8. |volume= has extra text (help)

Ahora podría incluir la información del volumen en el título, pero creo que sería mejor volver al comportamiento anterior, donde no se marcó ningún error. - Aa77zz ( conversación ) 15:58, 11 de abril de 2021 (UTC)

Quite la palabra "volumen": Manual . IV: Charranes a pájaros carpinteros. Izno ( charla ) 16:01, 11 de abril de 2021 (UTC)
La verdadera solución aquí es que los libros deben mostrar 'Vol.' frente a sus volúmenes. Headbomb { t · c · p · b } 16:54, 11 de abril de 2021 (UTC)
De ahí mi trabajo en el RFC que habrás notado. ;) Izno ( charla ) 17:54, 11 de abril de 2021 (UTC)
¿Tiene sentido que en el ejemplo anterior "Volumen" esté marcado como "texto adicional", pero "Charranes a pájaros carpinteros" no? Estoy de acuerdo con Aa77zz: todo lo que se cambió debe volver a cambiarse. Srnec ( charla ) 19:30, 11 de abril de 2021 (UTC)
Posiblemente sea algo problemático que, para los libros, usemos el |volume=parámetro para dos cosas diferentes (para distinguir las partes de una obra única de varios volúmenes y para etiquetar libros en una serie de libros por su número en la serie). - David Eppstein ( charla ) 18:29, 11 de abril de 2021 (UTC)

¿Cuándo se hizo este cambio? Ahora tengo que mover los |volume=parámetros a los títulos o (como sugiere Headbomb) cambiar la V en Volumen a &#86;en todas las referencias de libros Hawkeye7 (discutir) 21:43, 11 de abril de 2021 (UTC)

Elimina la palabra volumen. Esa es la solución. Eso es todo lo que necesitas hacer. Izno ( charla ) 22:13, 11 de abril de 2021 (UTC)
No. Porque entonces está en negrita. Y eso no es correcto. ¿Por qué debería alguien tener que 'arreglar' lo que no está roto para hacerlo mal? Srnec ( conversación ) 23:49, 11 de abril de 2021 (UTC)
Es un error de poner el nombre de parámetro en el valor del parámetro: |volume=Volume IV, |pages=pp. 3–5, |editor=Edward Eddington (ed.), etc. Esto se debe a que este texto adicional es generalmente el tipo equivocado de la información: no es los metadatos para la publicación en sí, sino más bien un intento de controlar la forma en que se los metadatos se enmarcan en su presentación al usuario. Si está utilizando estas plantillas, debe renunciar a ese control, dejar que la plantilla se encargue de cómo decirle al lector que el volumen es "IV" o "IV: Charranes a pájaros carpinteros", y no tratar de poner una descripción de lo que tipo de metadatos en los propios metadatos. Creo que la plantilla siempre debería escribir "vol. X" en lugar de mostrarla simplemente como "X", y no usar negrita para los números de volumen, pero eso 'Una discusión separada de la forma correcta de decirle a la plantilla cuáles son sus metadatos. -David Eppstein ( charla ) 00:05, 12 de abril de 2021 (UTC)
Creo que este fue un mal cambio hecho sin discusión. Dado que no podemos revertirlo, la única opción que tenemos es abandonar el uso de la plantilla. Hawkeye7 (discutir) 00:43, 12 de abril de 2021 (UTC)
El cambio se discutió en el estilo de la plantilla #Obtuse y se anunció para su incorporación en la actualización de la suite #module del 10 al 11 de abril de 2021 (y posteriormente incorporada). Si lo que deseaba era saber por qué sucedió, primero debe preguntarlo.
De todos modos, creo que los puntos débiles serán resueltos por el RFC que estoy preparando en el #Draft RFC . Aparte de eso, DE es fundamentalmente correcto. Ese aspecto de CS1 / 2 no es diferente a cualquier otro estilo de cita. Izno ( charla ) 00:48, 12 de abril de 2021 (UTC)
Este cambio no se incluye en la # actualización del conjunto de módulos del 10 al 11 de abril de 2021 . Hawkeye7 (discutir) 05:58, 12 de abril de 2021 (UTC)
@ Hawkeye7 : se permiten formas plurales de patrones de texto adicionales para volúmenes, problemas y números; discusión . Lamento que no haya quedado más claro pero tampoco escribí la nota en cuestión. - Izno ( charla ) 14:17, 12 de abril de 2021 (UTC)
entonces está en negrita ¿Qué? Proporcioné una copia del volumen reescrito arriba sin la palabra volumen. ¿Ves audaz allí? No. (Entiendo que cuando la plantilla se pone en negrita, las cosas no son obvias para las personas que no siguen de cerca, pero este no es uno de esos casos. La mayoría de CS1 / 2 incluirán plantillas en negrita con: solo números, romanos, árabes o de otro tipo; y texto suficientemente corto, por lo general menos de 5 caracteres. Este caso no es ninguno.) Izno ( hablar ) 00:51, 12 de abril de 2021 (UTC)
No solo está en negrita:
  • Keegan, John (1969). "¿Frente ancho o frente estrecho?". En Hart, Basil Liddell (ed.). Historia de la Segunda Guerra Mundial . 8 . Londres: Purnell. págs. 3196–3197. OCLC  2466051 .
¿Qué se supone que debe hacer el lector con los ocho que están sentados solos como un pardo de campo? ¿Por qué está separado del número de página?
La Commonwealth Style Guide (p. 204) dice que las referencias deben tener el formato vol. 8, no. 1, pp. 376-377 Hawkeye7 (discutir) 01:11, 12 de abril de 2021 (UTC)
Entonces, una cita totalmente diferente a la anterior. Entiendo. Como se acaba de decir, sí, los números están en negrita.
Las guías externas de citas / estilos no son CS1 / 2. Si desea formatear un artículo de acuerdo con Commonwealth , esa es su prerrogativa, pero estas no son las plantillas para eso y nunca lo han sido. Siempre.
Una vez más, tendrá la oportunidad de cambiar el aspecto del renderizado. Revise el borrador de RFC vinculado en la sección anterior y deje un comentario en esa sección si cree que RFC le parece bien. - Izno ( conversación ) 01:48, 12 de abril de 2021 (UTC)
Eso no es correcto. Tenga en cuenta el comentario anterior del monje trapense en la sección "Estilo de plantilla obtuso": Porque fuera de Wikipedia, las revistas académicas y académicas comúnmente usan ese estilo .
No me importa el RfC; Quiero que se eliminen los mensajes de error. Hawkeye7 (discutir) 05:52, 12 de abril de 2021 (UTC)
Hawkeye7, luego elimine el texto adicional "Vol.", "Volumen", etc. del parámetro, y el mensaje de error desaparecerá.
Una de las ideas para usar plantillas de citas es desacoplar la información de la presentación, un principio de diseño fundamental, y mantener centralmente la presentación para que sea coherente y también para permitir cambios futuros en el estilo de la presentación sin tener que volver a trabajar todas las citas individualmente. Los editores que trabajan en un artículo no deberían (necesitar) preocuparse por la presentación de citas en absoluto, todo lo que necesitan hacer es proporcionar la información adecuada.
La razón por la que nuestras plantillas de citas para libros muestran los volúmenes en negrita y sin ningún texto adicional como "Vol." se debe a que la comunidad decidió que las citas de libros deberían verse así hace mucho tiempo. Entonces, esto no es un defecto de la plantilla, sino que está codificado deliberadamente de esta manera. Sin embargo, no todo el mundo está de acuerdo con esto y, por lo tanto, algunas personas abusan del |volume=parámetro tratando de anular la presentación. Sin embargo, esta no es una buena idea porque anulará la idea de permitir que la presentación se cambie de forma centralizada en el futuro (quizás incluso dependiendo del dispositivo de salida, diferentes idiomas o en un formato seleccionable por el usuario) y provocará que los metadatos no sean válidos. ser generado.
La forma correcta de lidiar con la situación es ignorar sus preferencias de presentación por el momento y proporcionar los datos en el formato adecuado para la plantilla (es decir, sin ningún "Vol.", Etc.). Opcionalmente, puede expresar su opinión aquí de que mostrar números de volumen en negrita para los libros podría no verse bien o incluso podría ser ambiguo para las personas que no están familiarizadas con esta convención, o incluso podría proponer una presentación diferente. Si suficientes personas piden una presentación que incluya un "Vol." prefijo, podemos cambiarlo de manera centralizada, pero solo si |volume=continúa conteniendo solo el volumen, no alguna decoración de texto adicional (de lo contrario, la presentación resultante se convertiría en "Vol. Vol. X"). ¿Ve el punto?
Espero que esto ayude a comprender mejor por qué algo como "Vol." no pertenece al |volume=parámetro. - Matthiaspaul ( charla ) 11:39, 12 de abril de 2021 (UTC)
Es cierto que las guías de estilos / citas [externas] no son CS1 / 2. Eso no significa que, hace mucho tiempo, los editores que creaban estas plantillas individualmente no modelaban los estilos de las plantillas individuales en las guías de estilo externas existentes o en la práctica común externa. Los editores que crearon probablemente eligieron que la plantilla representara el formulario ' V (I): P' porque ese estilo es comúnmente utilizado por revistas académicas y académicas.{{cite journal}}
cs1 | 2 es un estilo en sí mismo y no está en deuda con ninguna guía de estilo externa.
Los mensajes de error se pueden desactivar; ver Ayuda: Errores CS1 § Control de la visualización de mensajes de error
- Trapense el monje ( charla ) 12:02, 12 de abril de 2021 (UTC)
Así que apáguelos. No deberíamos necesitar un RFC cada vez que sea necesario revertir algo porque obviamente no hay consenso al respecto. Vea el sitio web obligatorio / clúster de trabajo. Estos deberían ser, en el mejor de los casos, mensajes de mantenimiento. Headbomb { t · c · p · b } 12:25, 12 de abril de 2021 (UTC)
Acordado. Hawkeye7 (discutir) 12:27, 12 de abril de 2021 (UTC)
Personalmente estuve de acuerdo con convertirlo en un mensaje de mantenimiento en el lanzamiento cuando se instituyó, pero lo dejé en el camino por otras razones, y la gente aún habría gritado en artículos individuales en su lugar. Ahora es trivial hacer que los elementos de mantenimiento sean errores en el módulo (sandboxes) (y viceversa); ¿Por qué nadie más lo cambió antes del lanzamiento? (Antes de intentar disculparse colectivamente, no, Lua no es magia negra.) - Izno ( charla ) 14:17, 12 de abril de 2021 (UTC)
¡He escrito programas en Lua! Sé exactamente qué código debe cambiarse. Pero no puedo editar el módulo; solo los administradores pueden y yo soy un ciudadano de segunda clase. Y el cambio del que estás hablando no se anunció por adelantado. Tampoco hay un caso de prueba para ello. Hawkeye7 (discutir) 20:49, 12 de abril de 2021 (UTC)
La documentación dice que no podemos editar la caja de arena, pero aparentemente podemos. Hawkeye7 (discutir) 21:28, 12 de abril de 2021 (UTC)
Sí, la caja de arena siempre está disponible para editar. (¿Supongo que interpretó los bloqueos al principio de la documentación como una referencia a toda la línea? Ciertamente, esa no era la intención, solo la primera columna de módulos en vivo). Izno ( hablar ) 22:22, 12 de abril de 2021 (UTC)
Para los registros, el cambio se discutió aquí: Help_talk: Citation_Style_1 # Obtuse_template_style
- Matthiaspaul ( charla ) 19:19, 13 de abril de 2021 (UTC)
De esto se trata . ¿Cuándo han sido normales los números de volumen en negrita para los libros? Ahora me dicen que "la comunidad decidió que las citas de libros deberían verse de esta manera hace mucho tiempo", pero siempre pensé que era solo un descuido tonto en el diseño de plantillas. También me dijeron que "necesito renunciar a ese control" y "dejar que la plantilla maneje cómo decirle al lector [cuál] es el volumen". Pero la plantilla no funciona tan bien, así que lo que realmente me dicen es que deje de usar la plantilla. La plantilla es lo que necesita arreglarse. Si formateara las citas de libros con sensatez, entonces "arreglar" el error no sería tan malo. Pero, ¿por qué alguien "arreglaría" el error solo para producir una cita de aspecto extraño? Srnec ( charla ) 12:35, 12 de abril de 2021 (UTC){{cite book}}
¿Cuándo han sido normales los números de volumen en negrita para los libros?
|volume=se agregó el 15 de marzo de 2008 con esta edición y se puso en negrita una semana más tarde en esta edición . Estos cambios aparentemente se realizaron como resultado de una serie de discusiones:{{cite book}}
  • Parámetro de volumen
  • Numero de volumen
  • implementar volumen
  • Parámetro_volumen, _ de nuevo
Así que sí, "la comunidad decidió que las citas de libros deberían verse así hace mucho tiempo" como una decisión deliberada, no solo como un descuido tonto en el diseño de la plantilla.
- Trapense el monje ( charla ) 13:18, 12 de abril de 2021 (UTC)
Tenga en cuenta el comentario anterior del monje trapense en la sección "Estilo de plantilla obtuso": Observar que hay otro estilo que X no significa nada sobre el estilo Y de CS1 / 2. De nuevo.
No me importa el RfC Entonces claramente no estás aquí para colaborar y solo te importa que se cumplan tus preferencias. Hacerlo mejor. Tómese el minuto que le pedí que revise el RFC, dígame si cree que está bien formado y podemos seguir adelante con una solicitud de cambio positiva real. - Izno ( charla ) 14:17, 12 de abril de 2021 (UTC)
No está revisando mis artículos y yo no estoy revisando su RfC. Si está buscando colaboración, tengo muchos artículos escritos en los que puede trabajar. Hawkeye7 (discutir) 20:49, 12 de abril de 2021 (UTC)
Oh muy bien entonces. Existe un conflicto fundamental entre la noción de Matthiaspaul de que el módulo trata con metadatos y la de Trappist de que impone un estilo de la casa. Esta última es la forma en que funciona; no tenemos la capacidad de pasar información de estilo de la plantilla al módulo; está codificado en el módulo. Ahora, varias disciplinas están acostumbradas a tener diferentes estilos para adaptarse a sus diferentes necesidades. El RfC intenta crear una "pantalla general" que refuerza una presentación común. Es muy probable que esto no le convenga a nadie, y el Srnec probablemente estará de acuerdo con mi conclusión de que si tiene éxito, nos presionará más para que abandonemos el uso de la plantilla. Hawkeye7 (discutir) 21:28, 12 de abril de 2021 (UTC)
No veo cómo esos dos conceptos están en conflicto en absoluto. Se ocupa de los metadatos y aplica el estilo de la casa en esos metadatos. Los usuarios arbitrarios que intentan evitar ese estilo de casa son la razón por la que ahora hay advertencias rojas por las que estás aquí preocupado. :)
El RFC proviene de la presunción de que CS1 es un estilo (+ - CS2), no cualquier dominio u otro libro de estilo, porque así es como siempre ha funcionado; porque es más fácil de enseñar, aprender y reconocer; y porque no queremos codificar 300 estilos en un módulo. Si quieres que sea de estilo flexible en todas las cosas, ese es un RFC diferente. Incluso podría ser su propio módulo. Definitivamente sé que el estilo de cita de un libro de estilo diferente es un módulo diferente, aunque he estado considerando qué funciones podrían hacerse comunes para que cada estilo pueda tener verificación de fecha, etc.
Si tiene un artículo en el que cree que puedo ayudar de alguna manera (no puedo ofrecer mucho), hágamelo saber. :) Izno ( charla ) 22:16, 12 de abril de 2021 (UTC)

Se debe fomentar la variedad de estilos de citas. Para nadie en particular: Por supuesto, trabaje en un módulo CS3: hay espacio para estilos de citas adicionales que son más simples, más consistentes o mejor diseñados, porque comenzarían con una pizarra limpia. Como se observó anteriormente, los módulos actuales tratan mucho más que una presentación. El hilo reciente anterior sobre "autores basura" es un ejemplo. Se trata de la comprobación de errores en los datos, no del formato. Esta puede ser una función de citación avanzada, pero ciertamente no está relacionada con el estilo. Aparte de eso, los editores tienen derecho a esperar que las actualizaciones sean compatibles tanto como sea posible, sin interrupciones visibles en el espacio principal. Los desarrolladores tienen derecho a hacer con los componentes internos del código lo que consideren adecuado.Incluyendo parámetros de reetiquetado para la coherencia (en igualdad de condiciones) sin ser examinados constantemente. Después de todo, esta es una herramienta opcional.98.0.246.242 ( conversación ) 00:23, 13 de abril de 2021 (UTC)

La caja de arena ahora debería mostrar el error como oculto: Título . Volumen. |volume= has extra text (help)Tenga en cuenta que este error oculto por el módulo probablemente no continuará en un futuro indefinido. Izno ( charla ) 14:39, 12 de abril de 2021 (UTC)
  • Calambre, Stanley , ed. (1985). " Ceryle rudis Pied Kingfisher". Manual de las aves de Europa, Oriente Medio y Norte de África. Las aves del Paleártico occidental . Volumen IV: Charranes a pájaros carpinteros. Oxford: Prensa de la Universidad de Oxford. págs. 723–731. ISBN 978-0-19-857507-8. |volume= has extra text (help)
¿Cuándo podemos esperar ver este cambio en la producción? Hawkeye7 (discutir) 20:49, 12 de abril de 2021 (UTC)
Podría ser esta semana, podrían ser tres meses. (Solo digo 3 meses porque esa es la frecuencia de actualización general). He visto que 3 personas quieren que se oculte y otra 1 en la discusión de implementación que tendía a ocultarlo para comenzar, por lo que parece una inercia para implementar antes que más tarde. - Izno ( charla ) 22:20, 12 de abril de 2021 (UTC)
El problema básico es que nunca ha formateado los números de volumen de forma normal. Los trata como lo hace y eso no tiene ningún sentido. ¿No podemos simplemente arreglarlo para que genere el texto apropiado como lo hace? Srnec ( charla ) 00:14, 13 de abril de 2021 (UTC){{cite book}}{{cite journal}}|edition=
Implementé este cambio, así como una solución para el siguiente hilo iniciado por PresN . Es posible que continúe la discusión sobre el cambio a continuación en ese hilo. Izno ( charla ) 01:30, 14 de abril de 2021 (UTC)

Perdón por intervenir, pero ¿significa esto que no hay ningún beneficio práctico para resolver estos nuevos errores en este momento? (Solo tengo 7, pero prefiero no meterme con las citas si es innecesario). Estheim ( charla ) 17:36, 13 de abril de 2021 (UTC)

Si se acepta el parche de Izno (que yo también apoyaría), el mensaje cambiará de un mensaje de error a un mensaje de mantenimiento. Es decir, será visible solo para aquellos interesados ​​en él. Sin embargo, el hecho es que el texto adicional como "Vol.", "Volumen" o similar no pertenece al |volume=parámetro y tendrá que eliminarse de cualquier manera. El "Charranes a los pájaros carpinteros" en el ejemplo original no es "texto adicional" según esta definición, sino el subtítulo de este volumen en particular. Entonces, algo como "IV: Charranes a pájaros carpinteros" está bien en el |volume=parámetro, pero "Vol. IV: Charranes a pájaros carpinteros" no. - Matthiaspaul ( charla ) 19:19, 13 de abril de 2021 (UTC)
No hay ningún beneficio práctico para resolver estos nuevos errores en este momento. El módulo puede manejar los matadatos. La presentación aún no se ha acordado. Hawkeye7 (discutir) 20:20, 13 de abril de 2021 (UTC)
(Editar conflicto: responder a su comentario original antes de cambiarlo) Hasta cierto punto, podría al menos en teoría, pero no en la implementación actual. Las plantillas de citas no solo son leídas por el código de la plantilla en sí, sino también por una gran variedad de bots y otros clientes, por lo que tratar de "arreglarlo sobre la marcha" solo resolvería parte del problema. Para una legibilidad adecuada de la máquina en todos los ámbitos y para una reutilización confiable de los datos, los parámetros solo deben contener información válida también a nivel de código fuente.
Idealmente, la verificación de entrada adecuada se habría implementado desde el principio, de modo que ningún dato no válido podría haberse guardado sin causar un mensaje de error que alertara al editor contribuyente para que lo corrigiera, pero esto no era posible antes del cambio a Lua (y todavía hoy sólo es posible hasta cierto punto por razones de rendimiento y debido a la naturaleza de "texto libre" de la mayoría de los datos de citas). Con el avance de la tecnología y la maduración de las plantillas, nuestras plantillas de citas harán que esto se cumpla gradualmente, mientras se corrigen las citas antiguas que contienen datos no válidos.
Nuevamente, si a la gente no le gusta la presentación actual de las citas, el proceso adecuado es venir aquí y discutir las posibles mejoras, no tratar de solucionar problemas reales o percibidos insertando datos no válidos. Eventualmente será contraproducente.
Y también, de nuevo, el estilo actual de presentación de volúmenes para libros es el resultado de tales discusiones comunitarias en el pasado, no un artefacto aleatorio. Sin embargo, el consenso puede cambiar, pero solo cambiará si la gente hace propuestas para una mejor presentación y puede llegar a un acuerdo sobre una de ellas (la parte más difícil ...). Aunque estoy acostumbrado a esta notación simbólica para las publicaciones periódicas científicas, también creo que los números en negrita pero por lo demás desnudos se ven un poco extraños en las citas de libros y no todos los entenderán. Entonces, puedo entender muy bien por qué la gente se siente tentada a agregar "Vol." al |volume=parámetro (y probablemente lo hice ocasionalmente yo mismo en el pasado), pero sigue siendo una mala práctica y debería corregirse.
- Matthiaspaul ( charla ) 22:17, 13 de abril de 2021 (UTC)
Para mí, el número de volumen en negrita de un libro es tan incorrecto como cualquier dato no válido, por lo que no hay opción para corregir nada. No importa lo que hagas, está mal. Srnec ( charla ) 00:29, 14 de abril de 2021 (UTC)
Veo su punto, pero su preferencia personal (o la mía) no es relevante aquí; la plantilla presenta los volúmenes de la forma en que la comunidad decidió hace mucho tiempo. Y solo una entrada de parámetro produce este estilo. Además, solo este estilo produce metadatos correctos y es fácilmente legible por máquina por otros clientes. Y solo este estilo se puede cambiar de forma centralizada (es decir, sin demasiados gastos generales) si la preferencia de la comunidad cambia a un estilo diferente en el futuro. Por tanto, es evidente que sólo hay una forma "correcta" de hacerlo. - Matthiaspaul ( charla ) 00:48, 14 de abril de 2021 (UTC)
No creo que haya habido una decisión comunitaria en absoluto. Más bien, un editor lo agregó ya que se solicitó y no se pensó en la forma que tomaría. Digo esto basándome en mi lectura de los enlaces proporcionados por Trappist arriba. Quizás hubo una discusión sobre la forma en otro lugar. De todos modos, los editores que realmente usan la plantilla encontraron una torpeza. Srnec ( charla ) 01:19, 14 de abril de 2021 (UTC)
Estoy completamente de acuerdo. Esto ha estado mal desde que comencé a usar la plantilla hace muchos años. Como muchos otros, comencé a agregar "Volumen 1: bla, bla, bla" en un esfuerzo por evitar el número en negrita que resultó de otra manera. Dudo que esto fuera realmente una "decisión comunitaria"; si lo fue, debe haber sido una comunidad muy pequeña y selecta. MeegsC ( charla ) 07:34, 15 de abril de 2021 (UTC)

Lo que realmente me gustaría ver es que, en lugar de que el módulo acepte un |CitationClass=journalparámetro, adopte un formato, por ejemplo. |format=%first, %last (%date) %title, %series, %volume. %location: %publisher. Esto facilitaría cambios como los sugeridos por Izno. Hawkeye7 (discutir) 21:20, 13 de abril de 2021 (UTC)

Esto es esencialmente lo que el módulo ya hace bajo el capó, excepto que es más complicado porque en realidad es complicado. :) En otras palabras, el cambio es fácil, solo requiere consenso (de ahí el RFC planeado). Porque últimamente hemos estado haciendo un gran trabajo para lograr consenso. Izno ( charla ) 23:54, 13 de abril de 2021 (UTC)

¿Deberíamos usar la plantilla {{cite encyclopedia}} para diccionarios con definiciones cortas también? [ editar ]

Hago la pregunta porque, dado que el título (la entrada en el diccionario) es obligatorio, cuando un artículo debe citar diferentes entradas en un diccionario, el mismo diccionario se citará tantas veces como entradas. No me gusta la lógica. Tiene mucho sentido con una enciclopedia típica con artículos largos con un autor diferente para cada entrada, pero no tanto en el caso de un diccionario con definiciones anónimas cortas. Si usamos la plantilla de la enciclopedia, cómo las referencias abreviadas deben diferenciar las diferentes citas del mismo diccionario. No me encontré con esa situación, pero me gusta usar un enfoque que sea robusto y, por lo tanto, funcionaría en esos casos. Dominic Mayers ( charla ) 13:03, 13 de abril de 2021 (UTC)

Emplearía {{ harvs }} o mejor, {{ harvc }} (o una combinación) con anclajes personalizados. Creo que hubo una discusión reciente sobre similares, deberías revisar esta página / arhives. 50.74.165.202 ( conversación ) 14:29, 13 de abril de 2021 (UTC)
Por supuesto, debería haberlo hecho. Encontré esto , pero no es convincente que no haya una solución mejor. Continuaré la búsqueda en los archivos. Dominic Mayers ( charla ) 14:39, 13 de abril de 2021 (UTC)
Creo que 50.74.165.202 se refería a la sección #Referencias enumeradas por el editor del libro, pero la bibliografía enumera por autor del capítulo anterior donde se discute {{harvc}} . - Michael Bednarek ( charla ) 14:45, 13 de abril de 2021 (UTC)
No es obvio cómo se aplica. Puede que lo haya pasado por alto, pero no veo cómo se puede crear la referencia abreviada para un título dado y cómo se vinculará a la entrada correspondiente de {{ cite encyclopedia }}. La situación es que tenemos dos o más entradas de {{ cite encyclopedia }} que solo se diferencian por el título. Entonces, el autor al final, el editor al final o lo que sea, excepto el título, es inútil. Sospecho que puedo crear un ancla artificial en cada entrada de {{ cite encyclopedia }}, pero esperaba algo más conveniente. Dominic Mayers ( charla ) 15:01, 13 de abril de 2021 (UTC)
Pensándolo bien, ¿qué pasa |loc=? Como: "texto del artículo que utiliza un término muy poco común, [1] y otro término poco común [2].

Referencias

  1. ^ Fowler 1926 , "Término 1".
  2. ^ Fowler 1926 , "Término 2".

Fuentes

  • Fowler, HW (1926). Uso en inglés moderno .
HTH. - Michael Bednarek ( charla ) 15:33, 13 de abril de 2021 (UTC)

Claro, pero la pregunta era "¿deberíamos usar la plantilla {{ cite encyclopedia }} ...?" Ha respondido indirectamente "No", porque utilizó {{ cite book }}. Dominic Mayers ( charla ) 15:44, 13 de abril de 2021 (UTC)

Creo que se usó solo como ejemplo. La plantilla adecuada sería la de las colecciones editadas ( {{cite encyclopedia}} ). Las publicaciones de Michael Bednarek explican mejor a qué me refiero. Se puede utilizar cualquiera de los métodos o ambos, dependiendo de cómo desee presentar la referencia (entrada única o entrada compuesta de una lista principal con sublistas). Además, no creo que haya anclas "artificiales". Puedes crear el tuyo propio, según corresponda a la ocasión. 50.74.165.202 ( conversación ) 15:53, 13 de abril de 2021 (UTC)
Pero en {{ cite encyclopedia }}, el título es obligatorio, por lo que no puede usarlo como Bednarek usó {{ cite book }}. Este es el punto principal de mi pregunta. (Y sí, "artificial" podría no ser el término apropiado. Me refiero a un ancla que tienes que crear tú mismo en lugar de reutilizar información que ya está disponible como el autor). Dominic Mayers ( charla ) 16:00, 13 de abril de 2021 (UTC)
"texto del artículo que utiliza un término muy poco común, [1] y otro término poco común [2].
{{cite dictionary |title=Wordsmith's Big Dictionary of Small Words |date=2021 |ref={{sfnref|''Wordsmith''|2021}}}}→ Diccionario grande de palabras pequeñas de Wordsmith . 2021.

Referencias

  1. ^ Wordsmith 2021 , "palabra pequeña 1".
  2. ^ Wordsmith 2021 , "palabra pequeña 2".
- Trapense el monje ( charla ) 16:15, 13 de abril de 2021 (UTC)
Bueno, pensé en poner el nombre de la enciclopedia en el título, pero no consideré la posibilidad de que la enciclopedia de parámetros fuera opcional, así que descarté esto como una solución. En mi defensa, ni un solo ejemplo en la documentación de Template: Cite_encyclopedia ilustra que podamos poner el nombre de la enciclopedia en el título. Todos usan la enciclopedia de parámetros. Dominic Mayers ( charla ) 17:04, 13 de abril de 2021 (UTC)
La razón por la que la documentación no proporciona ejemplos de ese uso es porque, básicamente, se desaconseja ese uso. O porque nadie lo ha escrito así. (Me inclinaría más a creer lo primero que lo segundo. El módulo hace algunas cosas asquerosas debido a cómo |title=se puede usar en {{ cite encyclopedia }}.) Izno ( hablar ) 23:59, 13 de abril de 2021 (UTC)

¿La mejor forma de citar el quinto volumen de algo? [ editar ]

Después del cambio reciente a los mensajes de error de volumen, aparece un error en algunas listas en las que estoy citando el volumen "V" de un conjunto de libros (específicamente :) |volume=V: Carnivores, Pangolins, Equids and Rhinoceroses. La "V:" dispara el "no ponga 'volumen' en la verificación del parámetro 'volumen', y también lo haría" V ". ¿Alguien tiene una recomendación sobre cómo indicar que es el volumen" V "sin recibir la advertencia? No puedo pensar en uno, así que lo cambié por el "5" ligeramente incorrecto, pero pensé en preguntar. - Pres N 23:59, 13 de abril de 2021 (UTC)

Libro . V: Carnívoros, Pangolines, Équidos y Rinocerontes.para el contexto. Estoy de acuerdo en que esto no debería ser un error y que una de las expresiones regulares debería cambiar. Quizás eso se pueda implementar con el otro cambio que hice anteriormente. Izno ( charla ) 00:03, 14 de abril de 2021 (UTC)
El patrón en la configuración es . @ Trapense el monje : ¿Por qué lo agregaste deliberadamente? ¿O implementó lo que quería implementar incorrectamente? ... (El problema tiene un problema similar:. ) Izno ( hablar ) 00:12, 14 de abril de 2021 (UTC)'^v[%.:= ]', -- Roman numeral without separator (space char is sep char here)'^i[%.:= ]', -- Roman numeral without separator (space char is sep char here)
Mi pensamiento fue que 'V' o 'I' seguido de un carácter de espacio introduce el volumen o el 'valor' de la emisión. MediaWiki elimina los espacios en blanco finales antes de entregar los parámetros con nombre y sus valores a la plantilla y así al módulo. Por lo tanto, el espacio en blanco que sigue a 'V' o 'I' es indicativo de 'V 25'.
Iba a sugerir el marcado de aceptar esto como está escrito, |volume=((V: Carnivores, Pangolins, Equids and Rhinoceroses))pero eso no funciona (mal):
{{cite book/new |volume=((V: Carnivores, Pangolines, Equids and Rhinos)) |title=Book}}
Libro . V: Carnívoros, Pangolines, Équidos y Rinocerontes.
Pero, esto hace:
{{cite book/new |volume=((V: Carnivores Pangolines Equids and Rhinos)) |title=Book}}
Libro . V: Carnívoros Pangolines Équidos y Rinocerontes.
Algo sobre la coma. Tengo que pensar en esto ...
- Trapense el monje ( charla ) 00:27, 14 de abril de 2021 (UTC)
Este no debe ser un caso aceptado como escrito. Debería ser compatible. Simplemente eliminaré el patrón si esa es la alternativa. Izno ( charla ) 01:00, 14 de abril de 2021 (UTC)
No estoy convencido de que simplemente eliminar el patrón sea una buena idea. Si puede demostrar que los editores nunca escriben 'V', 'V:', 'V =' o 'V' de la misma manera que escriben 'Volumen:', etc., entonces quizás el patrón pueda desaparecer.
- Trapense el monje ( charla ) 01:20, 14 de abril de 2021 (UTC)
No, creo que la carga de la prueba está en demostrar que aceptar tal como está escrito es necesario. Ya sabemos que el número romano V es un caso que debemos tener en cuenta. Si no puede producir un patrón que lo admita, entonces el patrón debe eliminarse. Periodo y final de la historia. Izno ( charla ) 01:26, 14 de abril de 2021 (UTC)
Ahora implementado, dado que no hubo oposición anterior para configurar el error como oculto, no quería tocar el módulo en vivo dos veces, y debido a que aparentemente siguió adelante e hizo un cambio como se muestra a continuación en el módulo en vivo para un error separado. Izno ( charla ) 01:31, 14 de abril de 2021 (UTC)
Reparado. utilities.has_accept_as_written()devuelve dos valores; una cadena de texto sin el marcado de aceptar esto como está escrito y un boolian. hyphen_to_dash()luego devolvió obedientemente ambos pero utilities.substitute()no le gustan los booleanos, así que se atragantó.
La distinción entre la versión con coma y la versión sin coma es la ruta que sigue el código hyphen_to_dash()(no había comas, por lo mw.text.split()que no).
Debido a que esta falla produce errores de script lua, he actualizado el módulo en vivo con esta solución.
- Trapense el monje ( charla ) 01:20, 14 de abril de 2021 (UTC)
Todo lo que reemplace la entrada del usuario debe documentarse en detalle. Actualmente, no hay ninguna indicación en la página de ayuda de que |vol=se reemplaza la entrada que no se ajusta al patrón de restricción. Creo que las discusiones recientes se habrían resuelto rápidamente si tales restricciones de parámetros se hubieran comunicado mejor. Si se considera apropiado documentar el código relevante para los desarrolladores (algo bueno), debería serlo más para los usuarios. 71.167.45.141 ( conversación ) 12:02, 14 de abril de 2021 (UTC)
Ciertamente, la documentación siempre se puede mejorar (considere crear una cuenta y ayudar también; no es que no queramos mejorar la documentación, es solo una cuestión de tiempo).
Si un usuario se encuentra con este problema, el mensaje de error / mantenimiento contendrá un enlace a la Ayuda: CS1_errors # extra_text_volume , donde se explica el problema y la solución deseada. Además, la sintaxis ((accept-this-as-is)) para silenciar el mensaje en caso de una entrada válida detectada de forma incorrecta se explica en varios lugares, incluido aquí: Ayuda: Citation_Style_1 # Accept-this-as-writing_markup .
- Matthiaspaul ( charla ) 14:37, 14 de abril de 2021 (UTC)
Documentaría lo que codifico y no codifico aquí. Pero esto es irrelevante. Es bueno que haya mensajes de mantenimiento, pero me refería al mantenimiento preventivo. Es obvio (y comprensible) que la gente se molesta cuando una cosa tonta los regaña, especialmente cuando no tienen forma de saberlo de antemano. Al menos con el documento adecuado, siempre puede pedirles que hagan rtfm. 50.74.165.202 ( conversación ) 15:21, 14 de abril de 2021 (UTC)

Desanimado [ editar ]

Revierte los 6 parámetros "desaconsejados" a "verdadero" en la lista blanca. El cierre de RfC en el que se basó este cambio se ha revertido. Fram ( charla ) 07:33, 15 de abril de 2021 (UTC)

Aunque la clasificación novedosa fue el resultado del cierre reemplazado, no se opone por sí misma al sucesor. Las personas que se toman el tiempo para crear estas herramientas opcionales deben tener cierta libertad para indicar sus preferencias por motivos puramente técnicos. En este caso, centrándose en la consistencia y uniformidad. Sugeriría que un editor nuevo / principiante también estaría mejor servido con la distinción. 66.65.114.61 ( conversación ) 14:47, 15 de abril de 2021 (UTC)
Corregido en la zona de pruebas: valor "verdadero" restablecido para los parámetros previamente "desalentados" según el recierre de RFC .
Comparación de episodios de citas
Wikitexto{{cite episode |archiveurl=https://web.archive.org/web/20141006071642/http://www.example.com |authorlink=John Smith |author=John Smith |airdate=15 April 2021 |url=http://www.example.com |origyear=2020 |archivedate=2014-10-06 |author2=Jane Doe |author2link=Jane Doe |series=Series |title=Title |accessdate=15 April 2021}}
VivirJohn Smith ; Jane Doe (15 de abril de 2021) [2020]. "Título" . Serie . Archivado desde el original el 6 de octubre de 2014 . Consultado el 15 de abril de 2021 . CS1 maint: discouraged parameter (link)
SalvaderaJohn Smith ; Jane Doe (15 de abril de 2021) [2020]. "Título" . Serie . Archivado desde el original el 6 de octubre de 2014 . Consultado el 15 de abril de 2021 .
El ejemplo anterior utiliza todos los parámetros que se "desaconsejaron" en el primer RFC. La versión de la caja de arena muestra que no hay mensaje de mantenimiento ni mensaje de error. - Jonesey95 ( conversación ) 15:31, 15 de abril de 2021 (UTC)
Gracias. Fram ( charla ) 16:30, 15 de abril de 2021 (UTC)