Usuario:-jem-/Propuestas/1A

De Wikipedia, la enciclopedia libre

Primer bloque de propuestas a realizar a través del programa de Rapid Grants de la Fundación Wikimedia. Información completa en la subpágina principal. Se solicita la participación de la comunidad según se indica en dicha subpágina.

Los apoyos, rechazos, respuestas o intervenciones cortas pueden realizarse en el apartado correspondiente de la misma propuesta. Las intervenciones largas y exposiciones de modificaciones o nuevos aspectos pueden realizarse abriendo un nuevo hilo en la página de discusión.

Ordenación de cronologías[editar]

(Nuevo módulo bot + herramienta web de apoyo)

Grant propuesto, 2019-03-15

Descripción

Reordenar automáticamente las listas y tablas en los que aparecen años o fechas como datos para que sigan el orden cronológico enciclopédico (de más antiguo a más reciente), según se consensuó en este debate en el Café en 2015.

Detalles
  • Esta tarea ya fue añadida al bot Grillitus, pero este realizó una única edición con el resumen «ordenando tablas», precisamente en el artículo que se puso de ejemplo en el Café, y no parece que fuera a contemplar las listas; en todo caso, su programador ya no está activo (aunque lo invoco por si puede aportar algo aquí) y su código no está publicado.
  • Se añadirá una herramienta web para que los usuarios pueden solicitar la corrección de páginas concretas y ver el resultado.
  • Se incluirá la recopilación de artículos y anexos a examinar por proponer para el módulo bot a partir de Wikidata (actores, escritores, premios... y otros tipos de artículos que se puedan sugerir).
  • Se respetará el orden de los listados de bibliografía, que normalmente es alfabético.
  • (Nuevo, a sugerencia de XanaG): Se excluirán y categorizarán para su revisión manual los casos en que aparezca más de una fecha por línea o fila.
Preguntas sobre aspectos por concretar (usar el número como referencia al responder)
  1. Al reordenar las páginas previa solicitud de los usuarios a través de la herramienta web, ¿es necesario/conveniente que en el resumen de edición de Jembot se mencione el nombre del usuario solicitante? Esto requeriría aceptar la identidad leída desde los datos activos de la sesión (técnicamente: sistema OAuth), lo que podría retraer o preocupar a algunos usuarios.
  2. ¿Es conveniente aprovechar para incluir el cambio a "wikitable sortable" de todas las tablas con la clase "wikitable" (no sortable) que sean procesadas? Creo que todo este tipo de tablas van a ser más útiles si son ordenables, pero quizás haya razones para no hacerlo automáticamente.
Apoyos, rechazos, respuestas o intervenciones cortas de la comunidad
  • A favor Mi apoyo por el momento, y me anoto como tarea pendiente responder a las preguntas cuando saque algo más de tiempo. ¡Gracias por la propuesta! --abián 20:34 12 feb 2019 (UTC)
  • A favor A favor por supuesto, en cuanto a las preguntas:
1. No creo necesario mencionar al peticionario para aplicar un consenso.
2. Me parece bien la propuesta para las tablas. También se puede aprovechar la ocasión y las listas largas de una sola columna partirlas en varias, con un máximo de diez o veinte filas, por ejemplo.--Tiberius1701 (discusión) 23:57 12 feb 2019 (UTC)
Tiberius1701, esto último que indicas me parece que requiere un debate aparte. Para usuarios de PC lo que dices tiene sentido, pero en dispositivos móviles, que normalmente se visualizan en vertical, una columna basta y sobra, y divisiones arbitrarias como las que hay por ejemplo al final de Vuelta a España me parece que son un despropósito. Obviamente, lo ideal sería una solución dinámica que dividiera en columnas según el ancho de la pantalla; en el Café he leído hace poco que se puede hacer algo así para las referencias, que son listas, con <references responsive="">, pero entiendo que una tabla es un reto mayor. En todo caso creo que esto requiere un consenso y quizás su propia propuesta técnica aparte (pero podemos seguirlo hablando aquí o en IRC). - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
-jem-, indudablemente me explico muy mal, ya lo sé. Lo que dices de la solución dinámica también me parece lo ideal, y es por donde yo quería ir. La propuesta precisamente viene de una conversación de hace un tiempo atrás en IRC sobre el uso de <references responsive=""> a cambio de {{listaref}} y una respuesta en mi discusión a una consulta sobre lo mismo (y en el Café), pero aplicable a las listas en general y aprovechando la reordenación. --Tiberius1701 (discusión) 01:15 18 feb 2019 (UTC)
Entendido, Tiberius1701, y tranquilo, que te has explicado bien. Estamos de acuerdo entonces y estaré pendiente del tema, pero no incluiré nada al respecto en esta propuesta; lo iremos viendo en el futuro. - José Emilio –jem– Tú dirás... 13:16 19 feb 2019 (UTC)
  • A favor A favor de la propuesta. Respecto a las preguntas:
  1. Por un lado entiendo que si el cambio a realizar es correcto en general no debería especial necesidad de mostrar quién lo solicitó. No obstante, tampoco veo mayor problema en hacer la identificación por OAuth, que ya hacen muchas herramientas de ayuda a la edición, o incluso que al tratarse de una edición aislada que no añade carga a los revisores no vería problema que la herramienta haga la edición a través de la misma cuenta del solicitante (tampoco sé si eso te dificultaría o facilitaría, fuera de ello tampoco creo que sea especialmente relevante).
  2. No se me ocurre ningún motivo por el que no añadirlo, parece que en una tabla con datos fácilmente ordenables como fechas el «sortable» es positivo.
Aprovecho la ocasión para agradecerte la entrega y las horas de trabajo que nos has dedicado ya y las que aún pretendes aumentar. Un saludo. —— ♠♠♠ Mr.Ajedrez  Comenta la jugada ♠♠♠ —— 17:31 13 feb 2019 (UTC)
  • A favor A favor Ontzak (Bilbo ta Bizkai guztia) 20:32 13 feb 2019 (UTC)
  • A favor A favor de las dos. Me parece interesante que el resumen incluya el nombre del solicitante o al menos el diff de la solicitud. El cambia a "sortable" me parece conveniente, aunque se tropezará con algunas enormes tablas de resultados deportivos o artísticos y puede que se atasque como Grillitus. Geom (discusión) 00:46 15 feb 2019 (UTC)
Geom, ¿me podrías dar más detalles sobre esos posibles problemas en tablas grandes y los atascos de Grillitus? Entiendo que estamos hablando del cambio de «wikitable» a «wikitable sortable», que se hace una única vez al comienzo de la tabla, y para eso no debería importar en absoluto el tamaño de la tabla, pero quizás se me escapa algo. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
  • A medias (ooooh, los consensos del café :-) La reordenación automática me da un poco de miedo. Si la fecha no aparece en la primera o la segunda columna, puede que no se trate de un dato tan importante como el criterio de orden elegido por el autor. Además, a veces aparece más de una fecha en la tabla y no sé cómo de puede decidir automáticamente cuál es la más relevante. Quizá sería mejor categorizar páginas donde aparencen tablas o listas así en vez de "corregirlas". En cambio, a lo de covertir wikitables a sortables no le veo pegas de momento.--Xana (discusión) 13:24 16 feb 2019 (UTC)
XanaG, he revisado unos cuantos casos y no se me ocurre ningún motivo para que haya listas o tablas no cronológicas, sea cual sea la posición del año, salvo la bibliografía, que ya he indicado que excluiré explícitamente. ¿Se te ocurre algún ejemplo de lo contrario? Desde luego, me interesaría mucho saberlo para replantearme las cosas. En cuanto a la doble fecha, me parece adecuado lo que señalas y añado ya el excluir estos casos, que salvo mejor idea serían categorizados para su revisión manual. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
Sobre la identificación/OAuth: Viendo que puede ser interesante pero no hay unanimidad, estoy pensando en no implementarlo por ahora, y más adelante añadirlo para todas mis herramientas, pero solo como opción voluntaria. Mientras tanto, añadiré alguna verificación más sencilla donde sea necesaria. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
Hola, un ejemplo con tablas "complicadas" es Anexo:Fuentes de luz sincrotrón; ahí hay columnas con una fecha, pero se trata de un dato algo secundario (en algunos casos ni siquiera está presente). Aunque por supuesto que es interesante que los lectores puedan ordenar la tabla por la fecha, si lo desean, no me parece que sea mejor hacerlo así que por orden alfabético. Es diferente cuando la fecha aparece en la primera o segundo columna, esa posición sí que suegiere que se trata de un criterio más importante. --Xana (discusión) 15:01 18 feb 2019 (UTC)
Entendido, XanaG. Pues como no veo ninguna forma de diferenciar casos automáticamente (pienso que a veces se querrá ordenar con la fecha en la 3.ª columna, y a veces no, estando en la 2.ª), creo que la única opción viable es impedir las ediciones totalmente automáticas y trabajar solo en aquellos artículos que los usuarios soliciten en la web, mostrando además las listas o tablas detectadas y cómo quedarían tras la ejecución, para que puedan optar por no hacer nada ante la menor duda. Lo anoto así y lo reflejo también aquí. ¿Te parece bien? - José Emilio –jem– Tú dirás... 13:16 19 feb 2019 (UTC)
Sí, me parece bien, también se podría crear una categoría oculta para tablas que no sigan un orden cronológico para poder revisarlas todas.--Xana (discusión) 13:05 21 feb 2019 (UTC)
XanaG, ¿cómo funcionaría esa categoría exactamente? Porque generalmente se categoriza aquello que se sabe que tiene algún tipo de error a corregir, y no lo que simplemente podría tenerlo, porque una vez revisado alguien podría volver a pensar que no se ha revisado y volver a categorizarlo... me parece que o bien se usa otra categoría adicional para marcar los casos ya revisados y aceptados, o bien se lleva el registro de lo revisado y aceptado desde la propia herramienta web, sin usar categorías. ¿Cómo lo ves? - José Emilio –jem– Tú dirás... 23:26 22 feb 2019 (UTC)
¿Y si el bot añade una etiqueta (o quizá un comentario) a la tabla por la que ha pasado, para no volverla arevisar se corrija o no? Si no es complicarse la vida demasiado, claro. --Xana (discusión) 16:27 23 feb 2019 (UTC)
No es complicarse, XanaG; las etiquetas no tengo claro si se podrían insertar de forma personalizada mediante bot y serían difíciles de comprobar porque van asociadas a una revisión y no a todo el artículo, pero un comentario en el wikitexto es una buena opción, aunque existe el riesgo de que alguien despistado o malintencionado lo borre... siempre se podría controlar ese borrado con un filtro. Bien, de momento y si no surge otra idea mejor, me anoto la opción del comentario. - José Emilio –jem– Tú dirás... 17:34 24 feb 2019 (UTC)

Importación de tablas[editar]

(Mejora de módulo bot + herramienta web de apoyo)

Descripción

Ampliar la funcionalidad, flexibilidad y usos de la importación de tablas desde páginas web externas a artículos o anexos, incluyendo la gestión desde una herramienta web de la configuración para cada sitio externo de origen y de la solicitud de nuevas importaciones.

Detalles
Preguntas sobre aspectos por concretar (usar el número como referencia al responder)
  1. ¿Qué usuarios deberían tener acceso a la herramienta web y cómo se debería regular dicho acceso?
  2. ¿Puede ser conveniente definir unas reglas comunes para todas las clasificaciones deportivas, como el tamaño de la letra, los códigos de los colores y los casos en que usarlos, la ubicación de columnas frecuentes, el uso de negritas en la columna de puntos, el formato y ubicación de las leyendas...?
  3. ¿Es conveniente respetar absolutamente las grafías utilizadas en las fuentes, incluyendo incorrecciones gramaticales, o deben definirse unas reglas de conversión?
  4. ¿Puede ser interesante añadir la generación de columnas calculadas automáticamente en función de otras? Daría más homogeneidad y completaría la información, pero puede considerarse una cierta forma de fuente primaria.
Apoyos, rechazos, respuestas o intervenciones cortas de la comunidad
  • A favor Mi apoyo por el momento, y me anoto como tarea pendiente responder a las preguntas cuando saque algo más de tiempo. ¡Gracias por la propuesta! --abián 20:34 12 feb 2019 (UTC)
  • A favor A favor sobre todo en artículos y anexos con pocas ediciones y cambios frecuentes, me parece una solución buena.
2. Creo que sí es conveniente definir reglas comunes, da aspecto homogéneo y facilita comparar unas tablas con otras, por ejemplo, aunque siempre hay excepciones que también se pueden definir.
3. En principio no, si no hay motivo justificado para ello.
4. No veo problema, no creo que se pueda considerar que «5» es fuente primaria en «2+3=5», y si es un cálculo un poco complejo, se puede añadir una nota explicativa. --Tiberius1701 (discusión) 01:10 13 feb 2019 (UTC)
  • A favor A favor. Fantástica solución para este tipo de tablas. Incluso para tablas que no cambien tan frecuentemente pero estén en artículos «con poco seguimiento» puede resultar muy útil para no quedar desactualizados. Respecto a las preguntas:
  1. Pienso que no sería adecuado que cualquier usuario pueda fijar el formato. Tal vez una solución sea simplemente dejar a tu criterio elegir a ciertos usuarios que te resulten «de confianza» para configurar la tabla en última instancia y que atiendan las solicitudes en algún sitio centralizado (bien dentro de la herramienta o bien en una página en Wikipedia, lo que sea más cómodo). De nuevo no tengo ni idea de cómo se gestiona el OAuth pero si puedes contrastarlo con una lista manual puede ser una solución sencilla.
  2. Sí que es positivo tener una cierta homogeneidad a la hora de configurar las tablas. Puede ser algo que se fije como reglas generales cuya ruptura tenga que tener una cierta argumentación o simplemente como consenso entre los usuarios autorizados en la herramienta.
  3. Probablemente sea mejor tener unas reglas de conversión fijadas manualmente para adaptar cada caso.
  4. No veo problema en realizar cálculos sencillos para añadir información a la tabla (por poner un ejemplo tonto, si la tabla da los goles a favor y los goles en contra puede ser positivo añadir la diferencia de goles), difícilmente consideraría alguna de estas operaciones una fuente primaria.
Un saludo. —— ♠♠♠ Mr.Ajedrez  Comenta la jugada ♠♠♠ —— 17:44 13 feb 2019 (UTC)
  • A favor A favor Ontzak (Bilbo ta Bizkai guztia) 20:33 13 feb 2019 (UTC)
  • A favor A favor y con la sugerencia de extenderlo al campo financiero. Muchos valores se quedan desactualizados porque necesitarían leer tipos de cambios/cotizaciones recientes. --FAR, (Libro de reclamaciones) 22:57 13 feb 2019 (UTC)
FAR, no sé si estás al tanto de que tengo sendos módulos bot que ya actualizan la información de los índice bursátiles y de los tipos de cambio de las divisas, los cuales se leen desde las fichas de las monedas, ¿quizás estás pensando en cotizaciones de empresas concretas, para sus artículos...? En todo caso, si además puedes aportar alguna fuente que se pueda usar, tanto mejor. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
  • A favor A favor pero pienso que ese tipo de tablas deberían actualizarse en una plantilla o subpágina de artículo, para así no congestionar el historial de ediciones. ~ℳɑrio - (¿Hablemos?) 02:01 17 feb 2019 (UTC)
MarioFinale, mi impresión es que el uso de ese tipo de plantillas o subpáginas no cuenta con consenso, y recuerdo algún problema con algunos anexos de medalleros que usaban ese sistema; en todo caso sería plantearlo en el Café (aunque en mi caso sería para bastante más adelante). Y a priori no me parece que se esté congestionando mucho el historial en los casos que ya están activos, primero porque son artículos apenas editados por humanos, y luego porque muchas veces el bot solo tiene que actualizar los fines de semana, y como mucho sería cada tres horas según la programación actual, aunque podría ser cada más. De todas formas podemos seguirlo comentando, o si quieres en IRC. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
Sobre la identificación/OAuth: Viendo que puede ser interesante pero no hay unanimidad, estoy pensando en no implementarlo por ahora, y más adelante añadirlo para todas mis herramientas, pero solo como opción voluntaria. Mientras tanto, añadiré alguna verificación más sencilla donde sea necesaria. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
  • A favor A favor por supuesto. Muy necesario desde hace mucho tiempo tener las clasificaciones actualizadas y sin tener que estar editando constantemente la tabla. 1) No creo que tengan que tener acceso muchos usuarios. Creo que debería ser criterio tuyo el otorgar la posibilidad a algún usuario que tenga conocimientos en la temática en cuestión y que si se discute un cambio y se acuerda que se modifique el formato, esos pocos usuarios que tengan acceso, lo hagan. 2) Veo necesario que todas las clasificaciones tengan el mismo formato. Hay un montón de deportes con tablas creadas hace años y que nadie ha unificado porque sería un trabajo enorme, pero por lo menos crear todas a partir de ahora con el mismo formato sería genial. Creo que para esto tipo de decisiones sería acertado crear un Wikiproyecto: Deporte, donde se podrían englobar todos los wikiproyectos de deporte que han quedado abandonados y ahí crear un grupo de trabajo para tomar este tipo de decisiones. 3) Deberían definirse una reglas de conversión para no recoger problemas de otras páginas, donde frecuentemente se les escapan errores. 4) No considero que fuese fuente primaria, y sería más homogéneo. vanbasten_23 (discusión) 20:47 7 may 2019 (UTC)
  • A favor A favor, ayudaría mucho al mantenimiento de algunas listas dinámicas en otras áreas además de los deportes. ZebaX2010 [PRESS START] 03:23 8 may 2019 (UTC)
  • A favor A favor Rastrojo Quémame 10:58 18 may 2019 (UTC)

Control por listas[editar]

(Herramienta web con edición asistida)

Esta propuesta queda por ahora en espera por falta de apoyos. Se aceptan más comentarios útiles de cara a un futuro replanteamiento de la idea.

Descripción

Realizar un seguimiento desde una herramienta web de la forma en que están recogidos en Wikipedia los elementos de una lista, y corregir los problemas de accesibilidad detectados desde la propia herramienta, de forma asistida.

Detalles
  • Especialmente pensado para listas de siglas o símbolos; por ejemplo: elementos químicos, unidades de medida, códigos de países, idiomas y divisas, universidades...
  • Posibles resultados que se podrían encontrar sobre cada elemento de la lista (E): el título E no existe en absoluto; el título E lleva al artículo deseado; el título E habla de otro tema, pero el artículo deseado está accesible mediante desambiguación; mismo caso pero sin estar accesible; el título E lo ocupa una desambiguación, pero el artículo deseado aparece en ella; mismo caso pero sin aparecer; mismos casos pero a través de una redirección previa.
  • Los usuarios podrán introducir sus propias listas, con su título y varios patrones de texto que permitan determinar si se habla o no del elemento de la lista (los patrones se buscarían en las entradillas y en las desambiguaciones).
  • Se guardará y mostrará la fecha y hora de la última revisión de cada lista.
Ejemplo
  • Lista introducida: Símbolos de elementos químicos (Au, Fe, P, Lr, Rf, Lv...), normalmente mediante copiado y pegado; patrones de texto introducidos: «químico/a/os/as» (para detectar por ejemplo las frases «es un elemento químico...», «en Química, elemento...», «símbolo químico...»
  • Información que se mostrará (tomada de su situación real en estos momentos)
    • Au - Encontrado en desambiguación <marca de correcto> [por aparecer «símbolo químico»]
    • Fe - Encontrado en desambiguación <marca de correcto> [por aparecer «símbolo químico»]
    • P - Encontrado en desambiguación <marca de correcto> [por aparecer «en química, el símbolo»]
    • Lr - Encontrada redirección correcta <marca de correcto> [por aparecer «químicos» en la entradilla del destino]
    • Rf - No encontrado <marca de error> <enlace para corregirlo proponiendo varias opciones; en este caso se probará con «RF» y así se podrá llegar a proponer crear una redirección a «Radiofrecuencia» o lo mismo para «Rutherfordio», que lógicamente será lo adecuado, y se creará automáticamente la redirección solicitada>
    • Lv - No encontrado <marca de error> <enlace para corregirlo; en este caso se tendrá que preguntar al usuario a qué artículo deberá redirigirse (Livermorio), porque «LV» tampoco existe, y se creará automáticamente la redirección solicitada>
... etc.
Preguntas sobre aspectos por concretar (usar el número como referencia al responder)
  1. ¿Es necesario/conveniente identificar al usuario que introduzca una lista? Esto requeriría aceptar la identidad leída desde los datos activos de la sesión (técnicamente: sistema OAuth), lo que podría retraer o preocupar a algunos usuarios; por otro lado, con esa seguridad adicional se podrían añadir opciones de modificación de las listas.
  2. ¿Los patrones día/mes o mes/día debería reconocerse para redirigir al día del año correspondiente, como sucede en 1/2, y por lo tanto podrían ser incluidos como listas?
  3. ¿Es deseable la actualización automática de los informes de situación sobre cada lista?
Apoyos, rechazos, respuestas o intervenciones cortas de la comunidad
  • No entiendo muy bien esta propuesta, quizá por ser más abstracta o más ambiciosa que las demás. ¿Se podrían describir algunos ejemplos de aplicación sobre artículos concretos? Gracias en cualquier caso. --abián 20:34 12 feb 2019 (UTC)
  • Creo que veo por dónde va la propuesta pero estoy en la misma situación que Abián, no acabo de entender la herramienta concreta. Un saludo. —— ♠♠♠ Mr.Ajedrez  Comenta la jugada ♠♠♠ —— 17:47 13 feb 2019 (UTC)
Sobre la identificación/OAuth: Viendo que puede ser interesante pero no hay unanimidad, estoy pensando en no implementarlo por ahora, y más adelante añadirlo para todas mis herramientas, pero solo como opción voluntaria. Mientras tanto, añadiré alguna verificación más sencilla donde sea necesaria. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
  • comentario Comentario No lo entiendo, José Emilio, la he leído varias veces y no sé de qué va jajjajaj, perdón. ¿Podrías explicármelo con peras y manzanas, como si yo tuviera 5 años?. Laura Fiorucci (discusión) 03:53 24 feb 2019 (UTC)
Laura Fiorucci, no te preocupes :), está claro que no eres la única y que debo trabajar más la parte explicativa en futuras propuestas (ha sido un buen aprendizaje). Tendré que repensar o reformular esta idea para el futuro, y entonces será el momento de explicarla «con peras y manzanas», o con las frutas que sea menester. Gracias en todo caso por el interés. - José Emilio –jem– Tú dirás... 17:34 24 feb 2019 (UTC)
  • A favor A favor Si realmente entendí el sentido de la propuesta, estoy muy a favor.
    • 1: Lo veo conveniente, por ejemplo, si en un futuro puedan implementarse sugerencias personalizadas.
    • 2: Sí, ¿por qué no?
    • 3: No entiendo por dónde va esta pregunta :c
    • comentario Comentario Así como se planea obtener información sobre cada elemento de la lista buscando en la entradilla y en las desambiguaciones, ¿podría también extenderse a datos más complejos, por ejemplo, una lista de nombres? Un ejemplo, si yo introduzco una lista de músicos, creo que sería buena idea intentar obtener también información desde las declaraciones en Wikidata. Así, podría enlazar al artículo de un artista con cierto nombre, y no a otra persona (un deportista, por ejemplo) que comparta el mismo nombre. O, podría sugerirme no enlazar a ningún artículo, de no encontrarse alguno que satisfaga la condición. Espero haber sido claro. --Tinker Bell ★ ♥ 05:08 6 mar 2019 (UTC)
Tinker Bell: Creo que sí has sido claro, y todo lo que dices ya está incluido en lo previsto para la herramienta: igual que se identifica que un título lleva o no a un elemento químico por palabras relacionadas con la química, se puede identificar que un título lleva o no a un músico por palabras relacionadas con la música, y eso sirve igualmente para hacer o no sugerencias. La única posible objeción con listas de personas sería que en general no serían cerradas (salvo si por ejemplo se toman, digamos, los 100 mejores en algo según cierta publicación, o todos los que han recibido cierto premio), lo cual tampoco es que sea un gran problema, pero a efectos estadísticos y para evitar duplicaciones me parece útil. En todo caso, por ahora esta idea seguirá en espera, por no tener apoyos, aunque seguiré reflexionando sobre ella. - José Emilio –jem– Tú dirás... 14:33 15 mar 2019 (UTC)

Control de precisiones[editar]

(Herramienta web con edición asistida)

Descripción

Mostrar en una herramienta web el uso de precisiones entre paréntesis en los títulos de las páginas de contenido y categorías, permitiendo corregir de forma asistida los casos en que no se use la precisión preferida o en que la precisión sea innecesaria.

Detalles
  • Las sustituciones por razones de preferencia (por ejemplo, de «(grupo)» a «(banda)») se almacenarán y sugerirán para posteriores usos.
  • Se agruparán las precisiones numéricas según sean años simples, rangos de años separados con guiones, rangos de años separados con barras, u otros casos.
  • Se incluirá la posibilidad de corregir los enlaces entrantes al viejo título con posterior borrado o marcado de la redirección residual.
  • Se incluirá y almacenará la posibilidad de trasladar a títulos con otro tipo de precisión sin paréntesis (por ejemplo, de «X (año)» a «X de año», y otros casos similares que puedan sugerirse).
Preguntas sobre aspectos por concretar (usar el número como referencia al responder)
  1. ¿Qué usuarios deberían tener acceso a la herramienta web y cómo se debería regular dicho acceso?
  2. ¿Con qué frecuencia se debería actualizar la lista y estadísticas de los títulos?
  3. ¿Se debería consensuar previamente una lista de precisiones preferidas para reflejarla en la convención de títulos?
Apoyos, rechazos, respuestas o intervenciones cortas de la comunidad
  • A favor Mi apoyo por el momento, y me anoto como tarea pendiente responder a las preguntas cuando saque algo más de tiempo. ¡Gracias por la propuesta! --abián 20:34 12 feb 2019 (UTC)
  • A favor A favor. Pienso que con que sea autoconfirmado es suficiente, siempre y cuando se pueda bloquear en caso de mal uso mediante una subpágina del usuario protegida por un admin. Sería bueno el acceso usando una cuenta Wikimedia mediane OAuth. ~ℳɑrio - (¿Hablemos?) 14:37 13 feb 2019 (UTC)
  • A favor A favor. Respecto a las preguntas:
  1. Creo que el tiempo que lleve comprobar que todo esté correcto antes de realizar el traslado puede ser suficiente para no necesitar operar el flag de bot, en cuyo caso se podría hacer la edición asistida directamente desde la cuenta del usuario que lo solicite y bastaría con limitar a autoconfirmados, en caso de mal uso se podría tratar directamente al solicitante y bloquearlo si es necesario.
  2. Ni idea. Difícilmente sin una estimación de la cantidad de artículos afectados y su ritmo de creación se pueda llegar a fijar una frecuencia óptima.
  3. En mi opinión es indispensable que si vamos a cambiar masivamente precisiones en títulos a formas «preferidas» esas formas tengan un consenso comunitario previo.
Un saludo. —— ♠♠♠ Mr.Ajedrez  Comenta la jugada ♠♠♠ —— 17:55 13 feb 2019 (UTC)
2. Creo que debe obedecer a razones técnicas, que a mí se me escapan.
3. Debe existir consenso, me parece importante.--Tiberius1701 (discusión) 00:12 15 feb 2019 (UTC)
Sobre la identificación/OAuth: Viendo que puede ser interesante pero no hay unanimidad, estoy pensando en no implementarlo por ahora, y más adelante añadirlo para todas mis herramientas, pero solo como opción voluntaria. Mientras tanto, añadiré alguna verificación más sencilla donde sea necesaria. - José Emilio –jem– Tú dirás... 20:48 17 feb 2019 (UTC)
  • A favor A favor Laura Fiorucci (discusión) 03:52 24 feb 2019 (UTC)
  • A favor A favor --Tinker Bell ★ ♥ 05:08 6 mar 2019 (UTC)
    • 1: Creo que limitar a los usuarios autoconfirmados está muy bien.
    • 3: Creo que sí. Si no, cualquiera usaría el título que mejor le pareciese.
  • A favor A favor —Vercelas (quæstiones?) 20:37 16 mar 2019 (UTC)
Obtenido de «https://es.wikipedia.org/w/index.php?title=Usuario:-jem-/Propuestas/1A&oldid=118469885»