Wikipedia:Café/Portal/Archivo/Propuestas/2018/03

Enlaces a proyectos hermanos desde artículos

Hace tiempo que leo la wikipedia en inglés, veo que la forma de mostrar las categorías en los artículos es fantástica y su conmonscat bastante mejor que el nuestro, al igual que sucede en las wikipedias en francés y catalán, con lo que me gustaría saber vuestra opinión. MONUMENTA Discusión 00:22 22 feb 2018 (UTC)

En realidad, en esas versiones inglesa, catalana o francesa tienen dos plantillas para cada versión: una “en línea” —una línea de texto con el enlace— (Commons-inline / Commons category-inline) y otra “en recuadro” —un recuadro al margen derecho de la página— (Commons / Commons category). En Wikidata están enlazadas nuestras plantillas {{Commons}} / {{Commonscat}} con las versiones “en recuadro”, cuando en realidad son equiparables a las versiones “en línea”. En mi opinión, un enlace erróneo, posiblemente causado porque solo tenemos esa única versión. -- Leoncastro (discusión) 04:59 23 feb 2018 (UTC)

Muchas gracias por la información Leoncastro, ¿adaptar la plantillo tipo en recuadro a nuestra Wikipedia es muy difícil?. Si no, propondría cambiar la plantilla de nuestro Commoscat de la línea al recuadro.MONUMENTA Discusión 20:39 23 feb 2018 (UTC)

La adaptación es un simple cambio estético. Pero yo, por ejemplo, estoy en contra de una transformación de la plantilla desde la línea al recuadro; en todo caso duplicarla como en las otras wikis, y disponer de ambas versiones. -- Leoncastro (discusión) 20:44 23 feb 2018 (UTC)

Modificación plantillas de proyectos hermanos

===Modificación plantilla Commonscat=== Me gustaría proponeros el cambio de la plantilla actual del commonscat a la que utilizan las wikipedias en inglés o francés, para que esta quede mejor y más visible. Me gustaría proponeros el cambio de las plantillas actuales de los enlaces a proyectos hermanos, cómo las que se utilizan en las wikipedias en inglés o francés, para que estos queden mejor y más visibles.

Os pongo los ejemplos del Commonscat actual y el nuevo.

• Wikimedia Commons alberga una categoría multimedia sobre Café/Portal/Archivo/Propuestas/2018/03. enlace actual

, situada a la izquierda, en vez de a la derecha. cómo en las otras wikipedias

MONUMENTA Discusión 22:20 23 feb 2018 (UTC)

•  A favor --Леон Поланко говорит вам и слушает вас 21:37 23 feb 2018 (UTC)

•  Muy en contra no tiene sentido cambiar esta plantilla mientras no se plantee un modelo "global", que involucre al resto de proyectos (wikisource, wikiviajes, wikiquote,...) y, además, use Wikidata. strakhov (discusión) 21:38 23 feb 2018 (UTC) esta era la propuesta inicial de MONUMENTA, que después se cambia sobre la marcha y los demás quedamos para la posterioridad como incapaces que no saben leer
•  En contra, por lo explicado previamente. -- Leoncastro (discusión) 21:58 23 feb 2018 (UTC)
•  En contra también a la nueva propuesta, hasta que no se explique cómo se pretende organizar, que no es nada sencillo pues enlaces interproyecto hay de muchos tipos y no siempre uno-uno (wikisource). Por otro lado, una columna de dos o tres cajas de estas queda horrible estéticamente si no tiene texto (u otros enlaces externos) a su izquierda o derecha, así que quizás lo suyo sería diseñar una caja horizontal que los recogiera todos, pero entonces podría haber problemas en la versión móvil. strakhov (discusión) 23:02 23 feb 2018 (UTC)

Sí para artículos con más de un enlace si habría que adaptar la plantilla de la wikipedia en inglés, quedando cómo https://en.wikipedia.org/wiki/Spain#External_links MONUMENTA Discusión 23:46 23 feb 2018 (UTC)

•  En contra. Por lo dicho arriba, además de que una caja es mucho más intrusiva que una simple línea en la sección enlaces externos. Anna (Cookie) 23:39 23 feb 2018 (UTC)

Ya pero serviría para diferenciar los enlaces entre proyectos de la Fundación Wikimedia y los de otros sitios.MONUMENTA Discusión 23:52 23 feb 2018 (UTC)

Es decir, una columna que queda estéticamente fea en la versión de Escritorio (por el espacio blanco vacío que genera a su izquierda) si no cuenta a su izquierda con una columna paralela de 9 enlaces externos (con subsecciones además), cantidad de enlaces externos que en la mayor parte de artículos no está justificada. strakhov (discusión) 23:53 23 feb 2018 (UTC)

Lo de que lo situaba a la izquierda sí que lo pus desde el principio. MONUMENTA Discusión 00:35 24 feb 2018 (UTC)

Ya, también dije más arriba que "queda horrible estéticamente si no tiene texto (u otros enlaces externos) a su izquierda o derecha". Para mí una caja como esa alineada a la izquierda, sin nada a su costado ocupando el espacio sobrante, también queda fea. Llámalo horror vacui. Saludos. strakhov (discusión) 21:16 24 feb 2018 (UTC)

Me refiero a que estén a la izquierda, con los enlaces de sitios ajenos a Wikimedia debajo, no a en su flanco contrario. Todos los enlaces en el mismo lado, izquierda. MONUMENTA Discusión 21:23 24 feb 2018 (UTC)

No, si ya. Creo que no me estás entendiendo. El espacio vacío e inservible que dejaría la caja a su derecha lo veo negativo. Saludos. strakhov (discusión) 21:34 24 feb 2018 (UTC)

Pasa algo parecido, aunque no tanto en cualquier otro artículo con el sistema actual. Por ejemplo. Melilla#Enlaces externos.MONUMENTA Discusión 21:43 24 feb 2018 (UTC)

No creo que la impresión visual sea igual de mala. Además, empeoraría cuando hubiera una caja y además, a continuación, una ristra de enlaces externos "normales". Siempre pensé que de cambiarse la manera de mostrar estos enlaces debería plantearse algo horizontal (como esto, pero algo menos voluminoso. El problema es que las cosas horizontales se llevan mal (por alguna razón técnica concreta que desconozco) con la versión móvil de Wikipedia (no sé si se podrá diseñar una plantilla que en escritorio sea horizontal y en móvil vertical). De hecho, puestos a plantear horizontalidad y ahorrando costes, se podría utilizar {{Control de autoridades}} para enseñar estos links, en una fila superior independiente, y con iconos (al fin y al cabo es lo que se hace con Wikidata desde hace unas semanas). Pero, además de que por el momento esta barra no se ve en la versión móvil, veo problemas con cómo liga esto con la existencia de otros enlaces ext. "no de proyecto" (no me hace gracia la idea de que estos figuren antes). strakhov (discusión) 22:23 24 feb 2018 (UTC)

Sobre el problema de la “horizontalidad”, se debe a que la gran mayoría del diseño de Wikipedia se basa en tablas, y no en cuadros flexibles. Hagan un ejercicio de prueba: olvídense por un momento de su pantalla maximizada, y reduzcan el tamaño de la ventana a un rectángulo vertical similar al tamaño de un teléfono. Visiten entonces la página de la Portada (con un diseño basado en tablas) y también esta página (con un diseño basado en columnas). Modifiquen entonces el tamaño de su ventana (especialmente el ancho) y comparen la pequeña diferencia. Lo llaman diseño adaptable (responsive design). ¡Qué modernidad! PD: existe desde 2001. -- Leoncastro (discusión) 23:38 24 feb 2018 (UTC)

Multiplíquese el espacio vacío por otros recuadros para Wikcionario, Wikinoticias o lo que sea. Veamos...

(léase Wikcionario) (léase Wikinoticias o lo que sea) Enlace 1 Enlace 2 Enlace 3 Enlace 4 Enlace 5 Enlace 6 Enlace 7 Enlace 8 Enlace 9

Espacio en blanco innecesario. Equivalencia en líneas: 2 Equivalencia en líneas: 3 Equivalencia en líneas: 4 Equivalencia en líneas: 5 Equivalencia en líneas: 6 (comentario) Equivalencia en líneas: 7 Equivalencia en líneas: 8 Equivalencia en líneas: 9 (comentario) Enlace 1 Enlace 2 Enlace 3 Enlace 4 Enlace 5 Enlace 6 Enlace 7 Enlace 8 Enlace 9

Creo que se aprecia a simple vista que el espacio en blanco se ha duplicado con solo tres recuadros. Y eso es porque la relación del recuadro es 1:3. Una línea actual serán tres líneas según la propuesta.  No me convence. Saludos. -- Leoncastro (discusión) 22:01 24 feb 2018 (UTC)

Contaríamos con un megarecuadro para cuando es más de un proyecto, [1]. Aunque seguiría ocupando cada enlace de proyecto con dos líneas. MONUMENTA Discusión 22:32 24 feb 2018 (UTC)

 Muy en contra. 🙝 Miguu ¡Parlamenta! 05:59 25 feb 2018 (UTC)

Todas estas plantillas de enlaces entre proyectos deben tender a desaparecer porque ya se enlazan a través de Wikidata. Los enlaces aparecen en el menú, concretamente en la sección «Otros proyectos». Respecto a la propuesta, en contra de implementarla. En todo caso, sería preferible incorporar estos enlaces en el control de autoridades como Strakhov ha propuesto más arriba.

Un saludo. --Romulanus (discusión) 14:24 25 feb 2018 (UTC)

En vista de la poca aceptación de las plantillas con forma de cuadro, me sumo a la propuesta de Strakhov, de que se hagan por Wikidata y que no forme parte del Control de autoridades por estar al final del artículo, usando una plantilla basada en esta de la Wikipedia inglesa, {{Sister project links|b=no|voy=Spain}}, cómo se ve en [2]., que aunque ocupe dos líneas de texto, queda bastante mejor MONUMENTA Discusión 15:12 25 feb 2018 (UTC)

Perdona, Strakhov otra vez, acabo de decir los mismo que tu dijiste antes. MONUMENTA Discusión 15:19 25 feb 2018 (UTC)

Opciones

Comentario no sé, MONUMENTA, yo creo que no dije eso, pero bueno. Recapitulemos. Opciones hay:

• 1] Seguir como estamos, con plantillas "individuales" de colocación manual. Lo suyo, sería, al menos, modificarlas todas para que importen el enlace de Wikidata cuando están vacías.
• 2] Usar Wikidata mediante una plantilla del tipo {{Enlaces de proyecto}}, con el mismo display que el actual, una lista de puntos. ¿Positivo? Eficacia a la hora de almacenar datos y que nadie se quejaría por cómo se ve ...porque se vería igual que ahora. ¿Negativo? Para implementarla habría que ejecutar un masivo y medianamente complejo 'boteo', para 2a) añadir la plantilla en el lugar correcto (al principio de enlaces externos) 2b) eliminar plantillas redundantes 2c) mantener plantillas no redundantes (con frecuencia, pero no solo, las de wikisource y wiktionary).
• 3] Usar Wikidata mediante la plantilla {{Control de autoridades}}, generando una barra horizontal encima de la actual donde se muestren, horizontalmente, los proyectos Wikimedia. ¿Problemas? El diseño adaptable de la plantilla de autoridades no es nada adaptable, por lo que los lectores de móvil se quedarían sin ver nada salvo ue se pueda rediseñar la plantilla para que use columnas en lugar de tablas. Por otro lado, el problema de que los enlaces externos de terceros quedarían por encima de los wikimédicos. También habría que borrar plantillas redundantes.
• 4] Usar Wikidata en una plantilla en forma de caja vertical como la que propones. Problemas y ventajas similares a la opción 2], solo que, en mi opinión, quedaría ho-rro-ro-sa en el 75% de los casos ('espacio vacío inútil') en su costado + mala compatibilidad visual con otros enlaces externos.
• 5] Crear una plantilla {{Enlaces de proyecto}} en forma de caja vertical, sin usar Wikidata. Misma horrorosidad que la opción 4], solo que además, no mejoraríamos nada en 'eficiencia'.
• 6] Borrar todas estas plantillas, mandando por defecto al lector a buscar Commons, Wikisource, etc a la columna de la izquierda. No me termina de convencer y, en cualquier caso, de hacerse, deberíamos 6a) juntarlos todos (por ejemplo el de Wikidata sale marginado en "Herramientas": nunca lo entendí, estando los "Otros Proyectos" perdidos a mitad de barra (IMHO deberían estar todos juntos inmediatamente por encima de las interwikis) y 6b añadir iconos (ya lo hacen otras wikis).

¿Ok? strakhov (discusión) 19:27 25 feb 2018 (UTC)

Yo me posiciono por la opción 1: las plantillas {{Commons}} y {{Commonscat}} ya están adaptadas para importar el enlace desde Wikidata, y para adaptar el resto de plantillas tendría que conocer dónde y cómo se almacenan esos enlaces. Las opciones 3 y 6 tienen el inconveniente agregado de que no todas las apariencias tienen la barra lateral o muestran el control de autoridades (véase el artículo de Melilla usando Minerva o Timeless). Sobre la opción 2, señalar que no existen enlaces externos “rojos”, por lo que esa plantilla requerirá de parámetros que permitan mostrar/ocultar cada uno de los enlaces, por lo que no veo ventaja sobre usar plantillas individuales. Y para las demás opciones (4 y 5) muestro mi rechazo por el resultado vertical y el hueco blanco que se generaría. -- Leoncastro (discusión) 20:15 25 feb 2018 (UTC)

Con respecto a la opción 2] parto de la idea de que los enlaces a un determinado proyecto se mostrarían solo cuando el enlace está almacenado en Wikidata. Es decir, la macroplantilla {{Enlaces de proyecto}}, si en Wikidata solo hay Commons, solo debería mostrar el enlace de Commons y el icono correspondiente (no wikiviajes, wikiquote, etc). Es lo que pasa ahora mismo, a grandes rasgos, con {{Control de autoridades}}: cuando no hay enlace a Wikidata no se muestra nada (no "enlace rojo", no "enlace azul inoperativo"). Cuando no hay identificador en la BNE, no se muestra nada (no "enlace rojo", no "enlace azul inoperativo"). La ventaja sobre 1] es obvia: introduciendo una vez una plantilla cuando creas el artículo las tienes todas, y no tienes que percatarte por ciencia infusa de que alguien de otro proyecto creó por fin una categoría de Commons con fotos del tipo para incluir aquí, a mano, 'el commonscat'. En cuanto a 1], los enlaces están ahí: a la derecha.

En resumen 1] es una propuesta de mínimos y 2] si se cambia más profundamente el modelo ...sería hacia donde —para mí— deberíamos ir en un principio (mientras no se arregle la capacidad de mostrar cosas de otras opciones 3] y 6]). strakhov (discusión) 21:18 25 feb 2018 (UTC)

Sinceramente, la 2ª opción me parece la más bonita y elegante, aunque, sinceramente, dada la poca gente que llega a la parte final, pasando el muro de las referencias, y visita alguno de los enlaces externos, muchísimos menos con los móviles, apostaría por que la barra lateral contase con iconos, para que se distinguiesen mejor los proyectos. MONUMENTA Discusión 22:53 25 feb 2018 (UTC)

Tanto la opción 1 (sincronizar {{wikiviajes}} y {{wikiquote}} con wikidata) como la mitad de la 6 (la parte de reorganizar la columna izquierda y ponerle iconos, no la de borrar plantillas) son dos cosas que se pueden hacer sin necesidad de cambiar gran cosa.

Por otro lado, si se pudiera llevar un seguimiento de artículos con enlace a tal proyecto en Wikidata pero sin la plantilla correspondiente aquí... estaría bien sistematizarlo, para que un bot se encargara de añadir las plantillas faltantes en enlaces externos... Detectarlas con SPARQL + petscan creo que debería ser 'razonablemente asequible'. Salvo por posibles time outs. strakhov (discusión) 23:18 25 feb 2018 (UTC)

¡Ah!, ahora entiendo la opción 2, que entonces pasa por tener todos los enlaces importados desde Wikidata, sin necesidad de parámetros. Bueno, eso requiere previamente sincronizar los enlaces. Y para eso a mí no me sirve de gran ayuda verlos «ahí a la derecha», pues yo necesito conocer técnicamente cómo extraerlos de Wikibase. Mis escasos conocimientos se limitan a extraer propiedades. Quizás otro usuario pueda hacerlo, yo de momento lo desconozco. -- Leoncastro (discusión) 23:37 25 feb 2018 (UTC)

Ya me imaginaba que mi "los enlaces están ahí: a la derecha" no iba a ser de mucha ayuda. :) Aquí hay una plantilla (Wikidata person) que vuelca en Commons enlaces a wikisource y wikiquote (a través de un icono) cuando le especificas el item de wikidata. Así que, en un ligero parafraseo de X-Files diría que: The Truth is, probably, Out Here (o al menos en uno de sus módulos embebidos). strakhov (discusión) 00:46 26 feb 2018 (UTC)

Más concretamente aquí. strakhov (discusión) 00:56 26 feb 2018 (UTC)

Módulos de Lua... llamemos a algún experto: ¿Juan Mayordomo? -- Leoncastro (discusión) 01:12 26 feb 2018 (UTC)

• Comentario Mientras esperamos a Godot (o a un "un editor con un conocimiento razonable de módulos Lua"), tengo otra idea relacionada con esto. Introducir en WP:EE una mención a que los enlaces externos que no sean de Wikimedia no deben usar nunca ni negritas ni iconos. Una manera fácil, sencilla y para toda la familia de lograr que "los nuestros" destaquen más sin necesidad de meterlos en cajas. A título personal salvaría a OpenStreeMap ({{Relación OSM}}, por su afinidad con nuestro proyecto), pero obviamente es mi opinión... y si hay que quitárselo a todos pues se quita. Un ejemplo son, aparte de iconos para redes sociales (alguno he visto), la afición de añadir un icono con el escudo de armas del municipio en los enlaces a la web del Ayuntamiento del susodicho (un clásico en el que yo mismo seguramente haya caído). strakhov (discusión) 21:18 26 feb 2018 (UTC)

Sinceramente, quería que los enlaces externos, de los proyectos, fuesen más agradables, no más destacables, y tampoco creo que a los que no somos wikipedistas les interesen las mucho ver las imágenes en Commos, si tiene una selección en el artículo, y mucho menos los demás proyectos, que están bastante abandonados. Van a por la información, la primera que encuentran, todo lo demás no les importa.....

MONUMENTA Discusión 15:39 27 feb 2018 (UTC)

Sinceramente, MONUMENTA, discutir contigo en este hilo para mí roza ya lo surrealista, así que me vas a permitir que me baje del barco. Aplicando tu lógica para qué seguir escribiendo artículos más allá de la introducción si la mayor parte de los lectores no lee más que las tres primeras líneas. Los enlaces a otros proyectos están para que se usen, no para decorar. Para que quien quiera ver más fotos del tema sé dé cuenta de que la opción está ahí. Quien quiera una guía de viajes se entere de que cliqueando ahí va a tener una. Me da igual si son muchos o pocos. strakhov (discusión) 16:07 27 feb 2018 (UTC)

@Leoncastro: Lo siento, no acabo de ver que la plantilla de Wikidata person vuelque en Commons enlaces a wikisource y wikiquote. Yo para eso pediría un bot. Además tengo demasiadas cosas pendientes que me gustaría ir acabando. Saludos, Juan Mayordomo (discusión) 18:45 27 feb 2018 (UTC) ̈

• Yo sí lo veo. Se muestran dentro de los iconos de proyecto en el display de la plantilla. En el código de "Module:Creator" también parece figurar estoː

	-- === Step 4: name, wikisource, wikiquote, alternative_names and authority control
	-- =================================================================================	
	-- get name field
	data.name = Wikidata2._getLabel(entity, lang, "wikipedia") -- create name based on wikidata label

	-- prepare fallback list of languages
	local langList = mw.language.getFallbacksFor(lang)
	table.insert(langList, 1, lang)
	
	-- get wikisource and wikiquote link
	local projects = {s='wikisource', q='wikiquote'}
	for code, project in pairs(projects) do
		local sitelinks = Wikidata2._sitelinks(entity, project)
		if sitelinks then
			lng, _ = next(sitelinks)    -- get language of the first sitelink
			table.insert(langList, lng) -- and add it to the list	so there is at least one lang with sitelink on the list
			for _, language in ipairs(langList) do 
				sitelink = sitelinks[language]
				if sitelink then 
					data[project] = string.format('%s:%s:%s', code, language, sitelink)
					break 
				end
			end
		end
	end

Saludos. strakhov (discusión) 16:41 28 feb 2018 (UTC)

┌─────────────────────────────┘
Curiosamente me acabo de encontrar con la plantilla sisterlinks, que es una redirección a {{Info}}, la cual mediante parámetros genera una lista de enlaces creados por {{En otro proyecto}}. Esto viene siendo similar a la propuesta 2, aunque sin extraer los datos de Wikidata. -- Leoncastro (discusión) 02:47 28 feb 2018 (UTC)

Sigo siendo partidario de la opción de enviarlos al menú (opción 6). Estoy de acuerdo, además, con las propuestas de poner el de Wikidata (aunque me parece que suele ir suelta en otros proyectos) con el resto y añadir iconos. Lo mismo se hizo en su momento con los enlaces interlingüísticos, que no dejan de ser otros proyectos paralelos similares. Respecto a que no se ven en otras versiones, en la Minerva tampoco se ven los enlaces interlingüísticos (corregidme si me equivoco) ni otras opciones del menú, por lo que más parece una versión minimalista. No veo el problema. Un saludo. --Romulanus (discusión) 12:46 28 feb 2018 (UTC)

Yo, dejando de lado otras consideraciones, sí veo un problema: los enlaces en el menú no son capaces de informar (al menos en estos momentos, pues se limitan a incluir el nombre del proyecto) de que "Commons" contiene material multimedia, wikisource obras de la persona (a veces) o wikiquote citas célebres. Las plantillas "commonscat", "commons", "wikiquote", o "wikisource" (o potenciales aglomerados) sí. De hecho las 'individuales' además ofrecen cierta "versatilidad/personalización" adicional, a través de diversos parámetros. strakhov (discusión) 16:41 28 feb 2018 (UTC)

Sí, ya me había fijado en que no aparece una leyenda cuando se pasa el ratón por encima, cosa que sí sucede en el resto de opciones del menú, incluso en los enlaces interlingüísticos. Supongo que si se ha hecho en esos casos, se podrá hacer en estos. --Romulanus (discusión) 10:04 2 mar 2018 (UTC)

Bot

Sería útil un bot creador de artículos, como el de la wikipedia en cebuano. Que nos ayude a superar los 3 millones de artículos y cuando termine su labor se le podría dar a wikipedias con bajos artículos. 181.176.59.92 (discusión) 01:58 27 feb 2018 (UTC)

Eso se discutió largo y tendido hace más de 8 años, se acordó que preferimos calidad antes que cantidad (aunque se podría discutir de nuevo, si eso se acuerda). Ah, y otra cosa, los bots no "se dan", no son robots físicos, sino programas informáticos, son usuarios controlados con permisos para ediciones en masa en wikis específicas. 🙝 Miguu ¡Parlamenta! 05:54 27 feb 2018 (UTC)

En todo caso, tocaría hablar con el operador del bot en ceb:WP y preguntarle si quiere adaptar el bot para crear artículos aquí, pero presiento que la mayoría de la comunidad saldrá a poner el grito en el cielo mucho antes que eso... --Saludos. Ganímedes 12:32 27 feb 2018 (UTC)

Y no solo la nuestra (comunidad). En wikidata están hasta lo mismísimos @/·$%s de estos artículos y los Q's que generan (repetidos, mal geolocalizados, nombres incorrectos, etc). Los artículos de bot creados a partir de GeoNames & Cía por ese señor son considerados simple y llanamente basura en la mayor parte de los proyectos Wikimedia. De hecho, veo que varias veces se ha sopesado pedir el baneo del controlador del bot en ceb.wiki, además de impedir que se enlacen a Wikidata artículos que solo existan en sv.wiki o ceb.wiki. strakhov (discusión) 14:45 27 feb 2018 (UTC)

Súper útil: un bot creando artículos que los wikipedistas borran y otro bot borrando los artículos que los wikipedistas crean.... Mar del Sur (discusión) 18:59 27 feb 2018 (UTC)

XD --Saludos. Ganímedes 00:58 28 feb 2018 (UTC)

Si no se ha resuelto el asunto de PatruBOT (¿alguien sabe por cierto como anda este asunto?) y muchos se quejan de reversiones válidas hechas por el bot ¿qué desastre podría causar un bot creador de páginas? El bot es responsabilidad, requiere programación, el operador carga la responsabilidad si el bot comete errores, y como lo está diciendo el nombre, bot=robot. El bot no actúa conscientemente, no tiene pensamiento propio, hace lo que su creador ha programado que haga, los wikipedistas son seres humanos con pensamiento propio y algunos poseen los conocimientos para crear artículos. Es mejor la creación de un artículo por un usuario (anónimo o registrado) que por un bot programado. Por ende, la idea no me convence. --Леон Поланко говорит вам и слушает вас 19:52 1 mar 2018 (UTC)

Galerías en caja de edición

Según nuetra política de imágenes y la página de ayuda al respecto se deben evitar el uso de las galerías en general. Un usuario nuevo al que retiré una galería, Jorge Giglio, me ha comentado con razón que entonces resulta muy confuso para un usuario nuevo que sea tan fácil añadirlas. Es fácil porque aparece muy a la vista en la caja de edición para añadir sintaxis wiki junto a la redirecciones, archivos, enlaces internos y demás. Si nuestras políticas recomiendan expresamente que no se use, ¿no deberíamos eliminar de la caja de edición <gallery></gallery>? --Morza (sono qui) 12:32 2 mar 2018 (UTC)

Se recomienda, no se prohibe. La caja de edición y sus opciones son útiles no sólo en artículos, sino también en otro espacios. 🙝 Miguu ¡Parlamenta! 17:51 2 mar 2018 (UTC)

Biografia formato para politicos argentinos

Pienso que un formato adecuado para biografías, o perfiles de politicos argentinos (la razon de esta distinción es que todos tienen numerosas causas judiciales). Seria

•Breve Introducción •Biografía •Vida Profesional •Vida Política •Miscelaneas (donde entraría causas judiciales, controversias y cualquier otros aspectos)

De esta forma quedaría un texto expositivo/explicativo correctamente estructurado donde el lector va a encontrar una estructura coherente y poder leer el aspecto que le interese. Sino una persona se pierde en tanta información sin organizar. Por otro lado ayudaría a la estandarizacion de perfiles/biografías

Y debería aplicarse a todos los políticos

Cuales serian los pasos a seguir? Debería hacerse una votación?

|Foxtrot|$\infty {\frac {x^{n}}{n!}}$ 15:27 2 mar 2018 (UTC)

Primero se debería hacer una discusión aquí, después una encuesta y al final una votación. En todo caso me muestro  Muy en contra de esto. 🙝 Miguu ¡Parlamenta! 17:49 2 mar 2018 (UTC)

---

Se puede saber: Por que estarías en contra?

Cuales son tus argumentos. Saludos |Foxtrot|$\infty {\frac {x^{n}}{n!}}$ 20:14 2 mar 2018 (UTC)

•  En contra por ser discriminatorio. Si se tiene que hacer que se haga para todos, no solo para argentinos. scorpen buzón 20:56 2 mar 2018 (UTC)

 Muy en contra ¿Por qué un formato especial para los políticos argentinos? Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 22:27 2 mar 2018 (UTC)

---

No es discriminacion. Lo proponia para los políticos argentinos, porque sus biografías son verdaderos prontuarios policiales, estan llenos de causas judiciales. Conviene organizar la info. Desconozco la realidad del resto de los países. Pero si se da la misma situación...tambien estaría bien que lo adopten. |Foxtrot|CTM 23:00 2 mar 2018 (UTC)

Aunque no sea la intención es discriminatorio. La petición debe hacerse para todos en general. scorpen buzón 23:21 2 mar 2018 (UTC)

Duda, para una persona de profesión político, ¿cual es la diferencia entre «Vida Profesional» y «Vida Política»? -- Leoncastro (discusión) 23:40 2 mar 2018 (UTC)

---

Simple, una persona no nace con un cargo público, accede a el. Todo lo que hizo antes de acceder o despues de ejercer, ira a vida profesional y todo lo que hace mientras ocupe un cargo, ira en vida política.

Por ejemplo, Fernandez fue abogada exitosa antes que política, Macri ingeniero, Manzur medico cirujano. Lousteau economista. Kicillof economista. A. Fernandez contador y abogado creo. Todos tuvieron vida, antes de la política |Foxtrot|CTM 00:42 3 mar 2018 (UTC)

Comprendo. ¿Y por qué no llevar un orden cronológico en la biografía? Otros tienen vida también después de ser políticos. Estructurar de ese modo hace que el editor no tenga la libertad para redactar en el orden que estime más apropiado. -- Leoncastro (discusión) 01:45 3 mar 2018 (UTC)

---

Simple, porque seria dificil encontrar la información. Pongamos por ejemplo a Domingo Sarmiento, quiero conocer su vida política. Voy al apartado Política y encuentro todos los sucesos. Quiero saber sus problemas judiciales, voy al apartado correspondiente. No tengo que leer 100 veces de principio a fin....para filtrar y extraer los aspectos que me interesan. Quizas comenzó en política a los 15 dejo hasta los 26 ....desapareció...volvio a los 42. Entonces tengo que leer toda su vida? No tiene sentido.

Hay que organizar siguiendo una estructura lógica.

No haciendo una hoja de ruta

|Foxtrot|CTM 04:28 3 mar 2018 (UTC)

No necesariamente debe normalizarse siempre una estructura forzada. Para eso existen las secciones; para que el editor pueda ordenar y separar las partes según estime conveniente. Así, un editor puede crear en la biografía unas secciones como por ejemplo:

1965-1976 Afiliación comunista
Con quince años se afilió a las bases del partido (...) en los disturbios de 1969 fue acusado y detenido por vandalismo callejero (...)
1976-1992 Estrella del rock
Tras finalizar su carrera en Bellas Artes, inició su gira musical con sus amigos formando la banda (...) acusado de posesión y consumo de drogas, tuvo que cancelar su gira de 1982 (...)
1992-actualidad Ministro de Cultura
Tras ganar las elecciones de 1992, presentándose en cuarta posición en las listas electorales de (...) en 2010 fue acusado y posteriormente condenado por la concesión ilícita de (...)

¿Es necesario leerse toda su biografía? No, para eso está dividida en secciones y puedes ir a la etapa que te interese. ¿Significa eso que no existe orden? El orden existe siguiendo una estructura cronológica. ¿Está ordenada según tu propuesta? Tampoco: ¿por qué agrupar las causas judiciales de su juventud con las controversias de su edad adulta?, ¿por qué agrupar su vida política inicial con la final? Que no tenga sentido para tí, no significa que no lo tenga para otras personas.

Por lo tanto estoy  muy en contra de la propuesta, que limita la libertad de redacción del editor. -- Leoncastro (discusión) 05:18 3 mar 2018 (UTC)

 Muy en contra, exactamente por el mismo argumento que cita Leoncastro: porque limita la libertad de redacción del editor, que por ahora —de acuerdo a las características de cada biografía— puede elegir el orden en que se presenta la información. Establecer reglas fijas obligaría a tratar de igual manera a un político con sesenta causas judiciales abiertas que a uno que una vez haya recibido una crítica, por ejemplo. Además, ¿cómo llamaríamos a la sección que proponés? Porque "miscelánea" me parece una opción muy pobre. --Marcelo (Mensajes aquí) 16:44 3 mar 2018 (UTC)

Mucho sesgo. Mas que suficiente con lo que diga el manual de estilo o en caso de ser persona viva, la biografía de personas vivas. --Леон Поланко говорит вам и слушает вас 05:33 7 mar 2018 (UTC)

Encuesta sobre nuevos permisos de bloqueo y semiprotección

He actualizado la encuesta sobre si crear estos nuevos permisos. Sigue en preparación. Podéis verla aquí. --Tximitx (discusión) 12:40 28 feb 2018 (UTC)

Si en los próximos días nadie objeta nada de la encuesta, se abrirá el periodo de votación. --Tximitx (discusión) 18:35 4 mar 2018 (UTC)

Por sugerencia de otro usuario, he cambiado el nombre de la encuesta a encuesta sobre los permisos de bloqueo y semiprotección, para no confundirla con otros permisos que se están proponiendo. --Tximitx (discusión) 09:11 5 mar 2018 (UTC)

Hoy se ha abierto la encuesta. --Tximitx (discusión) 00:53 8 mar 2018 (UTC)

Archivado de Wikipedia:Consultas

Hola comunidad. Con Gonzalo P.M.G. queremos proponer un cambio a la forma en que se hacen las consultas en esa página y sobre cómo se archivan dichas consultas. El sistema actualmente se basa en que las consultas se hacen en subpáginas (por ejemplo, las consultas de esta semana se almacenan en Wikipedia:Consultas/semana 10 2018). Al hacerse en subpáginas, no se notifica el cambio en nuestras listas de seguimiento y hay que estar revisando manualmente la página principal para ver si hay nuevas consultas sin responder. La propuesta es la siguiente: que las consultas se hagan en la página principal (Wikipedia:Consultas) y que el archivado se haga a través de la plantilla {{Archivado automático}}, de forma que cuando un usuario haga una nueva consulta, ese cambio aparezca en las listas de seguimiento de los editores que siguen esta página. ¿qué opinan al respecto? Saludos --ZebaX2010 (discusión) 18:51 8 mar 2018 (UTC)

El modelo actual, por el cual se generan las consultas directamente en los archivos semanales, incluso contraviene su propia política, puesto que dice: «Las consultas, ya sean respondidas o no, pasarán a un archivo tres semanas después de la fecha en que se realizaron». Para corregirlo, se puede editar la página principal, eliminando las fórmulas que transcluyen los tres archivos semanales; pero también será necesario modificar en la subpágina de la cabecera, tanto el enlace para insertar nuevas consultas (en la casilla amarilla), como el texto que indica cómo responder directamente en los archivos (casilla verde). La plantilla para el archivado deberá contemplar el plazo de las tres semanas que se indica en la política |Días a mantener=21, y archivar incluso sin respuesta |Estrategia=FirmaMásRecienteEnLaSección, pero no existe todavía una configuración para indicar las semanas, por lo que existen dos posibilidades: 1) modificar también el destino del archivado, por ejemplo con subpáginas mensuales o anuales, o 2) solicitar en la plantilla para que se programen también las semanas como parámetro (algo que se trendrá que implementar también en los bots). Visto el pequeño tamaño de las subpáginas archivadas, y que una vez cambiado el modelo ya no serán páginas de trabajo y respuesta sino de archivo y consulta, yo me inclinaría por archivar mensualmente sin mayores complicaciones. -- Leoncastro (discusión) 20:11 8 mar 2018 (UTC)

Gracias por las sugerencias Leoncastro. Estoy de acuerdo en archivar mensualmente, dado que no son muchas consultas por semana. Si no hay objeciones, procedería a realizar el cambio lo antes posible. --ZebaX2010 (discusión) 01:29 9 mar 2018 (UTC)

@ZebaX2010, en ese caso el parámetro que falta para el archivado mensual podría ser |Destino=Wikipedia:Consultas/Archivo AAAA MM, para generar títulos como Wikipedia:Consultas/Archivo 2018 03, o |Destino=Wikipedia:Consultas/MMMM AAAA, para que sean como Wikipedia:Consultas/Marzo 2018. Saludos. -- Leoncastro (discusión) 02:10 9 mar 2018 (UTC)

@ZebaX2010: me parece bien lo expresado por Leoncastro. Gracias y saludos a ambos. --Fdo.: Gonzalo P.M.G. • 14:14 9 mar 2018 (UTC)

Iconos en enlaces externos

Actualmente a los enlaces externos en formato PDF se les cambia el ícono por defecto por uno que indica visualmente el formato del archivo. Ello se define localmente en Mediawiki:Common.css. Esto me parece especialmente útil, ya que dichos enlaces no dirigen a páginas web sino a archivos que, posiblemente, requieran que el usuario tenga instalado un software extra para acceder a él. Lo cobra especial relevancia para quienes consultan Wikipedia desde dispositivos móviles (que ya son más del 50% de las visitas totales), porque los navegadores web móviles usualmente no soportan este formato y se requiere alguna aplicación extra para leerlos. Además, al pulsar en el enlace externo se inicia automáticamente una descarga que, quizás, sea indeseada, lo que es especialmente importante si el archivo es de gran tamaño y la descarga no puede cancelarse.

Lo que propongo es identificar del mismo modo otros dos formatos básicos con características similares y que también se enlazan con bastante frecuencia: los .doc/.docx y los .xls/.xlsx. Personalmente me gustan Archivo:Microsoft Word 2013 logo mini.svg y Archivo:Office-excel.svg, ya que son sencillos y fáciles de identificar. Aunque puede escogerse cualquiera de esta categoría. También se puede aprovechar para reemplazar el GIF que estamos utilizando en este momento para PDF por alguno vectorial, como Archivo:Gnome-mime-application-pdf.svg (igual que los otros, sencillo y claro) o cualquier otro de esta categoría. --Metrónomo's truth of the day: «persevera y triunfarás» 02:18 4 ene 2018 (UTC)

Contrariamente a lo que se suele pensar, en estos casos de iconos especialmente pequeños, una imagen GIF es bastante más aceptable que una SVG si esta no está optimizada. A esa escala, la imagen GIF actual del fichero PDF (de 291 bytes), es más rentable que la alternativa SVG (de 34 KB), y el beneficio visual del cambio es prácticamente inapreciable. Además, quizás es buen momento para pensar en dejar de promocionar un software privativo y defender más el software libre, eliminando los símbolos que referencien a un programa determinado, haciéndolos más generales y más optimizados. Por ejemplo, este formato de texto procesado o este formato de hoja de cálculo, ambos casos en formato vectorial optimizado y de apenas unos cientos de bytes.

Por otro lado, existen más de 157 000 páginas con enlaces a .pdf, pero apenas 6000 y 7500 con enlaces a .doc/.docx y .xls/.xlsx. Estos últimos, comparados con los 37 000 enlaces a vídeos de Youtube, no parecen tantos enlaces. Y los videos suelen ser de mayor tamaño que los documentos. ¿También se marcarán los enlaces a videos? -- Leoncastro (discusión) 03:30 4 ene 2018 (UTC)

No se carga la imagen vectorial sino una versión rasterizada de la misma (PNG). Que en el caso que propuse para PDF sería esta, la cual tiene solo 532 bytes. La de DOC es de 545 bytes y la de XLS es de 510 bytes. Lo de optimizar archivos vectoriales es lo de menos, si fuera necesario yo puedo hacerlo. La imagen original ocupa tanto espacio porque se utilizó el que para mí es el peor programa para hacerlo (Adobe Illustrator). Mira Archivo:Ocean Steam Navigation Company flag - 1847.svg, lo reduje al 0,48% del tamaño original. La versión que propuse para .doc es solo una W azul en un marco y la de .xls es una X verde con marco, las elegí por su sencillez y porque quise utilizar lo que ya hay. Aunque el logo escogido a mí me da igual. La imagen que propuse para PDF es parte de un software libre y la de XLS es totalmente original, no se basa en ningún diseño, ni privativo ni libre. El título del archivo quizás pueda confundir, pero en la página de Commons se aclara a través de sus categorías.

Volviendo al tema central, los videos de Youtube siguen siendo páginas web, como todas las demás, no se descargan automáticamente en cuanto uno hace clic en el enlace. YouTube es un dominio, yo acá hablo de extensiones. --Metrónomo's truth of the day: «persevera y triunfarás» 05:01 4 ene 2018 (UTC)

Entiendo Metrónomo; sigo sin adaptarme al sistema de Commons para reformar la imagen según la resolución. Evidentemente el resultado de la conversión del SVG en PNG es bastante óptimo. Sobre el diseño, no me refería a que fuese una imagen o un diseño privativo, sino que identifica un software privativo. Teniendo en cuenta que actualmente esos formatos no se abren exclusivamente con Microsoft Office ni Adobe Acrobat, sino que existen otras alternativas como Apache OpenOffice, LibreOffice, Evince‎, o Sumatra PDF (entre muchos otros), no veo por qué “promocionar” las imágenes singulares o similares de los primeros. -- Leoncastro (discusión) 15:06 4 ene 2018 (UTC)

•  A favor de marcar ese tipo de archivos con iconos, y a favor también de los iconos propuestos la W en azul y la X en verde son dos iconos muy reconocidos por la mayoría de los usuarios y no da lugar a confusión como lo podrían hacer otras alternativas. Jcfidy (discusión) 06:07 4 ene 2018 (UTC)
•  A favor Juan Mayordomo (discusión) 20:22 4 ene 2018 (UTC)
•  A favor de todos los iconos propuestos. Anna (Cookie) 02:47 5 ene 2018 (UTC)
•  A favor solo de los iconos propuestos por Leoncastro. strakhov (discusión) 14:14 5 ene 2018 (UTC)
•  A favor de marcar esos archivos con iconos y de las puntualizaciones de Leoncastro. Se trata de identificar documentos de texto, no «documentos de Microsoft Word». Sabbut (めーる) 14:21 5 ene 2018 (UTC)

Leoncastro: tus propuestas son buenas, sencillas, genéricas y comprensibles. ¿Los diseños son tuyos? Si es así, ¿por qué no los subes a Commons? Solo un detalle, según https://validator.w3.org los códigos son inválidos, pero básicamente por falta de declaraciones. Les hice unos cambios menores y ahora no hay problemas: doc.svg y xls.svg. --Metrónomo's truth of the day: «persevera y triunfarás» 16:30 5 ene 2018 (UTC)

@Metrónomo esos archivos concretos los he creado yo en modo texto con el Notepad++ (de ahí la falta de cabeceras), pero los diseños están copiados de los originales que Google usa en sus programas Google Drive o Quickoffice. Dada la simplicidad de las imágenes, basadas en material design, existen varias representaciones extremadamente similares en internet.

La idea es buscar o generar unos archivos fáciles de identificar y que no se asocien a otra cosa que no sea Wikipedia y el formato de archivo que representan. O que se asocien a alguno, pero que sea software libre y no privativo. Si se prefiere, tampoco tienen por qué ser esas imágenes en concreto, para que no se asocien a estos otros programas específicos. -- Leoncastro (discusión) 17:16 5 ene 2018 (UTC)

•  A favor de marcarlos, pero con los íconos que sugiere Leoncastro o similares, ojalá sin promoción gratuita para software comercial o que no sea libre ni open source. Mar del Sur (discusión) 21:06 12 ene 2018 (UTC)
•  A favor: para que no genere una posible confusión. --Леон Поланко говорит вам и слушает вас 21:25 23 feb 2018 (UTC)

Íconos propuestos

Parece haber consenso sobre marcar este tipo de archivos. Leoncastro, ¿creés que podrás subir a Commons los íconos que hiciste? O, en su defecto, algún diseño similar que siga esa línea. Me gustaría considerarlos como la primera opción para utilizar. --Metrónomo's truth of the day: «persevera y triunfarás» 18:28 16 ene 2018 (UTC)

Actualmente se están usando iconos para los enlaces externos genéricos y para el formato PDF . Esta imagen está creada por Mark James, dentro de su librería de iconos Mini; aunque tiene otros diseños, como la librería de iconos Silk, con diferentes imágenes para PDF , DOC o XLS . Todos estos diseños están optimizados para visualizarse en tamaño de 16 × 16 píxeles, que es la representación con la que se muestran en pantalla, que a diferencia de otros formatos, muestran una imágen más nítida pese al pequeño tamaño (véanse por ejemplo estos otros casos: ). Existen otras librerías similares, optimizadas o no, pero que conservan un diseño similar para los tres tipos de archivos. Algunos ejemplos:

Librería	PDF	DOC	XLS
Famfamfam Mini icons		—	—
Famfamfam Silk icons
Farm Fresh documents
Farm-Fresh extensions
Nuvola
Nuvola Gnome
Gnome X Office
Tango
Crystal Clear
Oxygen
Breeze
Mis versiones

Saludos. -- Leoncastro (discusión) 16:21 17 ene 2018 (UTC)

Y así es como se entra en la paradoja de la elección. ¿Alguna preferencia un poco más específica? Lo más cercano a mi propuesta inicial es la librería Silk. También se puede hacer un diseño simple, algo que sea como PDF, DOC y XLS. --Metrónomo's truth of the day: «persevera y triunfarás» 19:38 17 ene 2018 (UTC)

Bueno, en realidad no son propuestas sino más bien ejemplos de la falta de nitidez en la gran mayoría de librerías, y de cómo debería mantenerse un formato similar para los distintos formatos de archivo. Salvo Silk icons y Nuvola, todas las demás se ven borrosas; la primera además representa en sus imágenes a determinados programas específicos (Acrobat, MS Word y MS Excel), y la segunda igual con Acrobat, y su última imágen no es especialmente representativa en esa resolución. Queda por tanto mi propuesta, que es la última línea, con las imágenes para PDF , DOC y XLS . -- Leoncastro (discusión) 20:27 17 ene 2018 (UTC)

Creo que, de todos los iconos que hay en la tabla de arriba, los que propone Leoncastro son los más nitidos y neutrales. Como dice Mar del Sur arriba, si el icono puede no representar software privativo y no abierto, mejor ―sobre todo teniendo en cuenta los proyectos de los que somos partícipes y su filosofía―. Por mi parte, estoy de acuerdo en integrarlos como estandar para esos archivos. Gracias Metrónomo por sacar a colación el tema y Leoncastro por su propuesta. Saludos, Ivanhercaz (Discusión) 02:36 20 ene 2018 (UTC)

La elección de Leoncastro es la más aceptable, pero el ícono de documento pdf a mi me llegó primero a la mente la imagen de un documento pptx. No se si exista una variación para que parezca más un pdf... Cybermaid 17:58 20 ene 2018 (UTC)

El formato de presentaciones es otro, y aunque algunas versiones de Microsoft usan un tono rojo, mayoritariamente se asocia con el color naranja. En cambio el formato PDF se asocia comúnmente a un documento blanco (ligeramente plateado o sombreado) y con detalles en rojo. En la versión rasterizada de 16 × 16 píxels no existe mucho espacio para representar gran cosa, y es lo mejor que pude hacerlo, pero si visualizas la versión vectorial completa no queda duda del formato al que identifica. Precisamente por eso he colocado las imágenes pequeñas enlazando a las grandes (sígase el enlace de la imagen: ). -- Leoncastro (discusión) 18:30 20 ene 2018 (UTC)

Es verdad, mi vista me falla, me he confundido porque dentro del ícono rojo hay una especie de gráficas, como las usadas en presentaciones. Cybermaid 18:51 20 ene 2018 (UTC)

┌─────────────────────────────┘
Yo no soy muy partidario de usar colores para diferenciar diferentes tipos de archivo, ya que esos colores normalmente vienen definidos por asociación con software comercial, con lo estamos promocionando ese software comercial aunque sea solo de manera subconsciente. Por ejemplo, ¿por que el icono de pdf tiene que ir en rojo y no en morado como lo he visto en algunos sitios? ¿Acaso debemos utilizar el rojo porque la mayoría lo asocia con el software de acrobat (software privativo)? ¿Con esa opción no estamos promocionando ese software privativo aunque sea inconscientemente? Además, tampoco todo el mundo tiene que conocer de que tipo de archivo se trata solo por el color, si no se incluye la extensión en el icono. Ni tampoco me parece muy vistoso llenar el apartado de referencias con colorines. Yo sería más partidario de usar iconos lo más neutros posibles, todos iguales, con un único color, y en el que apareciera la extensión del archivo sin ningún logo. Por ejemplo, estos iconos que son gratuitos y de licencia libre compatible, podrían servir. La propuesta de Metrónomo de simples cuadraditos con la extensión dentro también me parece adecuada, pero siempre que se usen todos los iconos con un único color (todos en blanco y negro, o todos monocromáticos del mismo color). Lo que interesa es identificar la extensión del archivo, y no el software que debe utilizar cada uno, que dependerá de los gustos de cada uno. --Tximitx (discusión) 08:44 21 ene 2018 (UTC)

Desconozco como lo ve cada uno en su pantalla, pero yo la propuesta de Metrónomo no la tuve en consideración, pues solamente veo tres puntos de colores con un tamaño de apenas unos cuatro píxeles aproximadamente. Sobre lo que indica Tximitx de nombrar cada icono con su extensión me parecería una buena idea, salvo por la consideración de que la imagen real que se muestra es de 16 × 16 píxeles, por lo que tal y como he indicado anteriormente no queda lugar de maniobra para editar gran cosa. Finalmente, sobre los colores por formato no es una representación única de un solo software, pues actualmente existe una convención tácita en la gran mayoría de plataformas de oficina, en donde los colores se reparten del modo: azul, documentos con formato enriquecido; verde, tablas o información tabulada; naranja, presentaciones; y rojo, documentos portables (aunque un gran movimiento lo agrupa también como presentaciones en color naranja, pues no deja de ser un formato de representación final). Programas como Nitro PDF modificaron su diseño morado por uno anaranjado; Foxit Reader cambió su diseño azul por uno anaranjado, aunque conserva también iconos en tonos morado y azul para sus versiones de edición y para móvil; Sumatra PDF se mantiene fiel a su diseño amarillo, pero no tiene un icono determinado para los archivos, no obstante su nuevo diseño para móviles ya es naranja; PDFsam transformó su diseño verde en una combinación verde y naranja; o PDF.js (que es la base de Mozilla Firefox y Google Chrome), ha usado desde sus inicios el blanco con detalles naranjas. Por otro lado, Adobe Acrobat, Google, Windows Reader (¿esto es un rojo anaranjado?), Microsoft Office, OpenOffice, LibreOffice, Kingsoft Office, Polaris Office, OfficeSuite, Evince, PDFedit o SodaPDF son algunas plataformas que usan el rojo como color representativo para el formato PDF. El mismo análisis se puede hacer para el azul o el verde, sin la problemática del rojo-naranja, pues ya existe amplio consenso. Por lo tanto los colores ya no designan tanto un programa concreto, sino más bien un tipo de archivo.

De todos modos, entiendo que no se quieran llenar de colores los enlaces, por lo que comprendo que se quiera mostrar un formato único blanco, similar a este: ; reservado, por el sistema MediaWiki para el protocolo ftp, aunque actualmente sin uso en esta wiki. -- Leoncastro (discusión) 15:50 21 ene 2018 (UTC)

@Leoncastro: puede que la propuesta de Metrónomo no la veas bien por el navegador que uses o por utilizar una hoja de estilo personalizada, ya que no se trata de iconos, sino de texto formateado. Pongo los logos con el código corregido y en gris a ver si los ves mejor: PDF, DOC y XLS. Ahora lo mismo pero con tamaño igual al texto y el mismo color que el texto (en negro): PDF, DOC y XLS. Se puede poner el tamaño y el color que queramos, puesto que se trata simplemente de texto formateado. Sería crear un estilo para ese texto y luego tan solo es usar ese estilo con el texto (extensión del archivo) que queramos incluir. Además sería más accesible, puesto que cada uno podría tener su propia hoja de estilos y los lectores de texto lo identificarían como texto y no como iconos. --Tximitx (discusión) 18:41 21 ene 2018 (UTC)

@Tximitx:, en el caso de hacerlo así lo que se podría hacer es crear las plantillas {{archivo pdf}}, {{archivo doc}} y {{xml}} o  modificar las plantillas {{pdf}}. Jcfidy (discusión) 19:07 21 ene 2018 (UTC)

@Jcfidy: no es necesario usar ninguna plantilla, porque la propuesta es que el sistema identifique automáticamente los enlaces a archivos con formato propio, añadiendo automáticamente el identificador. Lo que digo es que en vez de hacerlo añadiendo un icono (imagen) puede hacerlo añadiendo texto preformateado a modo de icono idenficativo. En cualquier caso sería automático como se hace ahora al añadir el icono de archivo pdf. --Tximitx (discusión) 19:21 21 ene 2018 (UTC)

Por cierto, la opción de imagen en blanco y negro también existe, aunque normalmente se asocia a texto plano. -- Leoncastro (discusión) 19:57 21 ene 2018 (UTC)

Acabo de crear estas cuatro imágenes sencillas y con menos color. -- Leoncastro (discusión) 03:39 23 ene 2018 (UTC)

Yo pienso que a esta altura, la asignación de colores es ya un estándar ipso facto, lo que queda claro viendo la tabla que hizo Leoncastro. En íconos pequeños la identificación por colores resulta más sencilla. De todo lo que se presentó, lo que más me gustó fue lo último que mostró Leoncastro, incluyendo el gris para el texto plano. Pero, si se decidiera no utilizar colores, el texto formateado en gris de Tximitx me pareció bastante legible. Esa es mi segunda preferencia. --Metrónomo's truth of the day: «persevera y triunfarás» 04:14 23 ene 2018 (UTC)

Yo personalmente poner iconos de colorines no creo que sea la mejor opción, pero es solo una opinión y tampoco me opongo si se considera que es la mejor solución. No obstante, con independencia de que se usen colores o no, me parece que debería indicarse la extensión del archivo en el icono, ya que es la mejor forma de identificar los archivos. El que aparezca un icono rojo o uno azul no dice gran cosa hasta que no se descargue el archivo y se vea lo que es. Además, ¿como distinguir por ejemplo entre archivos DOC, ODT y RTF? Son todos de texto formateado, por lo que en principio todos irían de azul, pero según las preferencias de cada usuario necesitará un programa u otro, ya que no todos los editores leen todos los formatos. Lo ideal es que se identifique la extensión, al margen de que luego se usen colores o no. La propuesta de texto formateado con colorines que hizo Metrónomo también sirve, aunque en mi opinión los identificadores deberían ser de mayor tamaño. Pongo una muestra: PDF, DOC y XLS. Podrían ir incluso más grandes, ya que es simplemente indicar el tamaño del texto. --Tximitx (discusión) 10:14 23 ene 2018 (UTC)

Tximitx, no creo que sea buena idea identificar todas y cada una de las extensiones, pues no olvidemos que no son tres o cuatro, sino muchas, muchísimas más. Por ejemplo, el texto con formato no solamente son esas tres DOC, ODT y RTF, también sus variantes DOCX, DOCM, DOT, OTF y ODT, y sus “competidoras” HWP, LWP, OTT, PSW SDW, SXW, UOT, WPD, WPS, WRI, XPS, y un largo etcétera. Y eso sin tener en cuenta sus respectivas variantes, ni tampoco las extensiones y variantes para hojas de cálculo. Las extensiones .doc y .xls son solamente dos de todas las existentes, del mismo modo que Word y Excel son dos de entre todos los programas existentes. En mi opinión lo más correcto y más neutral creo que es identificar los formatos de archivo «texto con formato» y «hoja de cálculo» respectivamente. En mis ejemplos, el texto es representado por unas líneas, y las hojas de cálculo son representadas por unas tablas, del mismo modo que trato de simbolizar texto con imágenes incrustadas para el formato de «presentación» o «representación final» (donde encaja el formato PDF). -- Leoncastro (discusión) 15:37 23 ene 2018 (UTC)

Precisamente por la gran cantidad de formatos existentes es por lo que hay que identificar las extensiones. Los office antiguos leen el formato DOC, pero no el DOCX. Igualmente muchos lectores de móvil son compatibles con el formato DOC (Word) pero no con el formato ODT (Libre Office). No digamos ya con otros formatos menos utilizados. Si solo ponemos un icono azul, se asociará al formato DOC, que es el más habitual, pero si luego se trata de un archivo en otro formato puede que el usuario lo haya descargado en balde, ya que puede que no tenga un lector para ese formato. Que luego además se quieran utilizar colores para identificar los distintos tipos de archivo, puede ser razonable, pero sin la extensión o algún otro distintivo no se puede saber cual de los muchos formatos existentes es el que utiliza el archivo. No todo el mundo tiene lectores compatibles con todos los formatos. La idea no es solo identificar archivos descargables, sino también el formato del archivo, ya que no es lo mismo un DOC, que un ODT, que un RTF, o que un PDF, aunque todos incluyan texto e imágenes. --Tximitx (discusión) 19:33 23 ene 2018 (UTC)

Hay algo que no entiendo bien en tu último comentario Tximitx, y me gustaría que explicaras «La idea no es solo identificar archivos descargables, sino también el formato del archivo». Si entiendo bien, eso quiere decir que estás proponiendo no solo identificar PDF, DOC y XLS, sino también ODT, RTF, DOCX, DOCM, DOT, ODT, HWP, LWP, OTT, PSW, SWD, SWX, UOT, WPD, WPS, WRI, XPS, «y un largo etcétera [...] sin tener en cuenta sus respectivas variantes, ni tampoco las extensiones y variantes para hojas de cálculo».

No olvidemos tampoco que por ejemplo la extensión .doc es usada tanto por formatos de “Microsoft Word 6.0”, como para “Microsoft Word 95”, o para “Microsoft Word 97/2K/XP”, todos ellos formatos incompatibles con sus sucesores; o que el formato de extensión .pdf también ha evolucionado desde la versión 1.0 hasta la actual 1.7, y el usuario que tenga Adobre Acrobat 5.0 solamente podrá abrir versiones de archivo hasta la 1.4. -- Leoncastro (discusión) 17:38 25 ene 2018 (UTC)

Efectivamente, estoy pidiendo identificar también otros archivos además de los PDF, DOC y XLS. Se puede hacer una preselección si no se quiere identificar todos los formatos, pero no comparto que se identifique solo los DOC y XLS (además de los PDF, que ya se hace) porque puedan ser los más usados. Los formatos .DOC y .XLS son formatos propietarios, frente a los formatos OpenDocument que son de formato abierto. Tal vez no sea necesario identificar todos los formatos que has indicado (si se puede hacer, mejor, pero no es imprescindible). Lo que discrepo es que se señalen solo formatos propietarios porque sean los más utilizados, ya que en cierto modo se promovería el uso de usos formatos en detrimento de los formatos libres.

También indico que el usar solo unos iconos de colores sin identificar el formato no es de gran utilidad, ya que por ejemplo usar un icono azul para archivos de texto formateado, puede referirse a muchos formatos diferentes. Si alguien lo descarga pensando que es un archivo de Word y luego no lo es, puede que no tenga un lector compatible. Word es compatible con varios formatos, pero no todos usan el programa de microsoft como lector, ya que se trata de un programa de pago. En ese caso hay lectores gratuitos compatibles con el formato DOC, pero no con otros formatos. Lo ideal es que el usuario pueda identificar el archivo con su extensión antes de descargarlo, ya que así podrá saber de que formato se trata y decidir si lo descarga.

En cuanto a la existencia de distintas versiones para un mismo formato, todo el mundo sabe que si tiene un programa antiguo puede que no sea compatible con la última versión del formato, pero siempre podrá buscar un programa actualizado para ese formato, que entonces leerá todas las versiones. Por ejemplo, para archivos DOC, cualquiera puede buscar un lector gratuito y actualizado que le leerá todas las versiones de ese formato, antiguas y nuevas. Si el usuario prefiere mantener un lector antiguo, eso será una decisión suya, pero entonces ya sabrá (o lo verá enseguida) que no es compatible con las versiones más actuales del programa. Distinto es el caso de que el archivo no sea DOC; el usuario también puede buscarse un lector para ese formato, pero lo suyo es que el formato estuviera identificado antes de que se descargara el archivo, y no que primero tenga que descargarlo para luego darse cuenta de que no es un archivo DOC. Si quiere buscarse un nuevo lector para ese otro formato, estupendo, pero que no se le pida buscar ese otro lector después de descargar el archivo, sino que se le indique antes para que lo sepa y decida (igual no le interesa instalar otro lector). --Tximitx (discusión) 20:55 25 ene 2018 (UTC)

Bien, gracias por la explicación Tximitx, en ese caso no me opongo a la versión que has propuesto, siempre que cada extensión sea identificada individualmente. Aunque personalmente prefiero algo más sencillo y visual, comprendo tus argumentos. No veo problema en que coexistan diferentes identificadores, salvo decidir qué extensiones lo llevarán (algo que ocurre sea cual sea el diseño elegido). ¿Como hacemos entonces? ¿Lo llevamos a votación o se decide en este Café? ¿Quien aplica el cambio? Como parece que todos estábamos de acuerdo en incluir nuevos identificadores, al menos que este hilo termine en alguna de las opciones propuestas, ¿no?. -- Leoncastro (discusión) 21:13 25 ene 2018 (UTC)

Identificar todas las extensiones, si se hace con texto preformateado monocromático como propongo, creo no sería muy difícil. Bastaría con comprobar si el enlace termina con alguna extensión (.??? o .????) distinta de htm/html, y entonces copiar esa extensión dentro del texto con un estilo predefinido. Más complicado es lo de aplicar colores, porque entonces ya hay que elegir que color aplicar.

Si se quiere elegir a que extensiones aplicar, ya sea para aplicar iconos o para aplicar colores, yo elegiría primero que tipo de archivos identificar (PDF?, documentos_de_texto?, hojas_de_cálculo?, ...) y luego dentro de cada tipo, que extensiones podrían ser interesantes. Si hacemos una preselección, yo me limitaría a unos pocos en ambos casos, ya que incluir muchos podría ser complicado y generar conflicto. La decisión se puede tomar aquí si no hay oposición.

Como propuesta mínima yo incluiría los siguientes:

• Documentos impresos (rojo): PDF
• Documentos de texto (azul): DOC/DOCX, ODT y RTF
• Texto simple (gris): TXT
• Hojas de cálculo (verde): XLS/XLSX y ODS
• Diapositivas/Presentaciones (marrón): PPS/PPSX, PPT/PPTX y ODP

Creo que con eso se cubre los más interesantes y los formatos más utilizados. Se podría incluir alguno más, pero creo que los propuestos cubren prácticamente todos los casos habituales. Las imágenes irían en Commons, así que en principio no sería necesario incluirlas. Habría que decidir si se identifican con texto o con iconos, y en caso de usar texto, si se usan colores o no, y el tamaño. Si hay un consenso mayoritario y no hay oposición, sería simplemente pedirlo remitiendo a este hilo en el Café, pero no sé donde hay que pedirlo. --Tximitx (discusión) 22:26 25 ene 2018 (UTC)

Agregaría .csv en hojas de cálculo. -- Leoncastro (discusión) 01:01 26 ene 2018 (UTC)

Concretando propuestas

---

Opción actual

Actualmente solo se refleja imagen para los formatos de archivo .pdf:

---

Opción basada en imágenes

Identificar visualmente con tres o cuatro imágenes los formatos básicos.

• Para las extensiones de texto con formato (.doc, .docx, .odt, .rtf), todas por igual:
• Para las extensiones de hoja de cálculo (.xls, .xlsx, .ods, .csv), todas por igual:
• Para las extensiones de representación final (.pdf):
  • Si se desea pueden incluirse otras extensiones (.pps, .ppsx, .ppt, .pptx, .odp) bajo la misma imagen, o con otra imagen particular:

---

Opción basada en texto

Identificar todas las extensiones con un mismo diseño formado por un texto encuadrado, usando el mismo formato y color. El texto en cada caso corresponde a la extensión:
DOC, ODT, RTF, XLS, ODS, CSV, PDF, PPS, ODP

---

Opción basada en texto con color

Igual que la opción anterior, pero diferenciando en grupos de colores según sea texto con formato (azul), hoja de cálculo (verde) o presentación (rojo-marrón):
DOC, ODT, RTF, XLS, ODS, CSV, PDF, PPS, ODP

---

Si se considera agregar correcciones o más opciones, adelante. Con esto creo que podemos iniciar una especie de votación o búsqueda de consenso. -- Leoncastro (discusión) 01:01 26 ene 2018 (UTC)

 A favor. Me gusta la idea.  The  Shudder  | 17:30 27 ene 2018 (UTC)

@TheShudder, ¿alguna preferencia entre las opciones? Se trata de concretar cual es la opción que gusta más. -- Leoncastro (discusión) 01:13 28 ene 2018 (UTC)

Ah, pues sí . Prefiero la opción basada en imágenes. ¿Por qué? Pues no tengo una razón concreta. Simplemente me gusta más cómo se ve.  The  Shudder  | 20:21 28 ene 2018 (UTC)

 A favor de la opción basada en imágenes. --ZebaX2010 (discusión) 21:25 28 ene 2018 (UTC)

 A favor de la propuesta con imágenes Mar del Sur (discusión) 08:46 6 feb 2018 (UTC)

 A favor de empezar con las meras imágenes. Si con el tiempo se ve que no es suficiente, siempre puede "complicarse" el modelo introduciendo extensiones. strakhov (discusión) 08:55 6 feb 2018 (UTC)

 A favor del modelo con imágenes. Sabbut (めーる) 13:30 13 feb 2018 (UTC)

 A favor del modelo con imágenes, revisando la conversación, es la que más concreta. Kojie (Habla por esa boquita) 14:39 13 feb 2018 (UTC)

 A favor del modelo con imágenes. 🙝 Miguu ¡Parlamenta! 04:20 19 feb 2018 (UTC)

Comentario Hace poco surgió un tema similar en una encuesta sobre uso de imágenes en artículos sobre fútbol. Existe un problema al menos con el ícono de pdf que, a pesar de estar actualmente en Commons, podría no tratarse de una imagen libre. Puesto que el diseño (aquí con más detalle[3]) es una marca registrada en muchos países, incluyendo EEUU, y no estaría por debajo del umbral de originalidad (a pesar de que se afirma lo contrario en la descripción). Aunque la propuesta no trata específicamente sobre ello, se apoya en esa imagen como ejemplo, y creo que sería conveniente evaluar en primer término si debemos continuar utilizándola. Mapep (discusión) 18:19 15 feb 2018 (UTC)

El modelo nuevo propuesto (el que tiene todo el apoyo) reemplazaría la imagen actual por una diferente, que no tiene ninguna relación con la anterior: Archivo:16x16-icon-w-pdf.png. --Metrónomo's truth of the day: «persevera y triunfarás» 21:42 15 feb 2018 (UTC)

 A favor del modelo texto con color. El color facilita, pero el texto ayuda a quienes aún no están familiarizados con la vinculación color-formato.-- Miguel Alan Córdova Silva | ¿Digamelón? 08:52 10 mar 2018 (UTC)

Dos módulos de Lua

Hola. Acabo de volver a Wikipedia después de una buena temporada. He estado mirando esto de los módulos, y para probar he escrito/adaptado dos que no sé si pueden ser de utilidad.

El primero es un bucle similar a en:Module:ForLoop pero con alguna opción más:

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/MiBucleFor|main|lineSep|sep|expr|vals}}

toma la lista contenida en vals, la divide en líneas separadas por el separador lineSep, cada línea a su vez la divide en argumentos separados por el separador sep, y para cada una de las líneas muestra la expresión expr (código wiki), sustituyendo $1, $2, etc. por los sucesivos argumentos.

Admite además los siguientes parámetros con nombre:

• limit, que es el número máximo de líneas que se mostrarán (por defecto, sin límite).
• paramPrefix, que es el símbolo que precede a los números que se sustituyen en la expresión (por defecto, $).
• call, que es el nombre de una plantilla, para aplicarla en lugar de expr.
• expr, que es que es una alternativa al parámetro posicional expr.
• page, que es el título de una página, cuyo contenido se usará en lugar de vals.

Por ejemplo, la lista anterior se puede construir como:

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/MiBucleFor|main|
|;|* '''$1''', que es $2.
|limit;el número máximo de líneas que se mostrarán (por defecto, sin límite)
paramPrefix;el símbolo que precede a los números que se sustituyen en la expresión (por defecto, $)
call;el nombre de una plantilla, para aplicarla en lugar de '''expr'''
expr;que es una alternativa al parámetro posicional '''expr'''
page;el título de una página, cuyo contenido se usará en lugar de '''vals'''}}

De momento lo estoy usando en Usuario:Qwertyytrewqqwerty/Desambiguaciones con títulos incorrectos. Lo digo aquí por comprobar si hay algo similar en eswiki (en enwiki parece que se usa mucho) y si puede emplearse en general.

El segundo segundo es un conjunto de herramientas basadas en las de en:Module:Redirect:

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/RedirectTools|isRedirect|Página}}

devuelve yes si Página es una redirección, y no devuelve nada si no lo es.

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/RedirectTools|isRedirectTo|Página1|Página2}}

devuelve yes si Página1 es una redirección a Página2, y no devuelve nada si no lo es.

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/RedirectTools|isRedirectHere|Página}}

devuelve yes si Página es una redirección a la página actual, y no devuelve nada si no lo es.

{{#invoke:Zona de pruebas/Qwertyytrewqqwerty/RedirectTools|getRedirectTarget|Página}}

devuelve el título de la página a la que apunta Página, si es una redirección, y nada si no lo es.

Mi idea es usarlo en Plantilla:Redirige aquí para comprobar si es verdad lo que dice la plantilla, y cuando no lo sea incluir la página en una categoría de mantenimiento. Esto es algo parecido a lo que hacen en enwiki en en:Template:Redirect.

¿Qué pensáis de estos módulos? ¿Hay alguno equivalente en eswiki que yo no haya encontrado? ¿Se pueden usar? ¿Alguna idea más que lo que he dicho? Saludos, Qwertyytrewqqwerty (discusión) 13:30 3 mar 2018 (UTC).

Pensaba que lo había puesto en Técnica... Pero bueno, aquí valdrá también. Qwertyytrewqqwerty (discusión) 19:50 3 mar 2018 (UTC).

Y ahora es cuando me doy cuenta de que ya existían Módulo:Redirección y Módulo:ForLoop, con interwikis y todo. ¿Dónde miré yo? Qwerty | ytrewq | qwerty 19:51 9 mar 2018 (UTC)

Derecho suppressredirect

Hola. Puesto que el autor de esta encuesta no está de acuerdo en añadir la cuestión allí, la traigo al Café.

El derecho de suppressredirect, que en este wiki tienen los biblios y los bots, sirve para trasladar páginas sin tener que dejar redirecciones. En enwiki tienen un grupo de usuarios con este permiso, los page movers. Comparado con los que se consideran en las encuestas sobre permisos que están actualmente en preparación, creo que suppressredirect generaría menos polémica. Quizá no reduciría mucho el trabajo de los biblios, pero un poco sí ayudaría, y yo no veo motivos para no darlo.

La utilidad de este derecho consiste en quitarles a los biblios parte del trabajo de borrar redirecciones innecesarias de las que quedan después de los traslados. Si los biblios no tienen que hacer eso, entiendo que tendrán más tiempo para dedicarse a otras cosas de biblios. También puede ayudar a hacer traslados encadenados sin tener que esperar por los biblios. Por ejemplo, si "Lo que sea" es una desambiguación, pero creemos que "Lo que sea (actor)" debe ser el artículo principal, tenemos que trasladar "Lo que sea" a "Lo que sea (desambiguación)" y luego "Lo que sea (actor)" a "Lo que sea". Es verdad que es una utilidad limitada, pero tenerlo sería mejor que no tenerlo (salvo por la cuestión de la burocracia añadida a la hora de conceder el derecho, pero eso se puede solucionar asociándolo a alguno de los grupos de usuarios que ya existen, como el de verificadores). Saludos, Qwertyytrewqqwerty (discusión) 14:56 4 mar 2018 (UTC).

•  A favor ya que aparentemente es una herramienta que no requiere toma de decisiones trascendentales, y también porque es favorable que la carga de tareas se reparta entre los que quieren trabajar. scorpen buzón 15:19 4 mar 2018 (UTC)
•  Muy en contra en crear un nuevo grupo solo para eso. Si queréis añadirlo a la lista de permisos que los usuarios autoconfirmados o verificadores/reversores se puede discutir, pero un nuevo grupo solo para esta nimedad ni hablar. —MarcoAurelio 16:12 4 mar 2018 (UTC)
  • De acuerdo con que no merece la pena crear un grupo para eso. Mi idea era añadirlo a uno de los existentes, o de los que se puedan crear próximamente. Aunque dárselo a los autoconfirmados, al mismo tiempo que el permiso de trasladar, igual es demasiado. Qwertyytrewqqwerty (discusión) 16:18 4 mar 2018 (UTC).
    • Podemos dárselo a los verificadores si queremos restringirlo un poco. Gracias por aclarar que no se trataba de crear un nuevo grupo sólo para esto. Un saludo, —MarcoAurelio 17:09 4 mar 2018 (UTC)

Pero... cuando los bibliotecarios lo usan, ¿pueden elegir si se va a dejar redirección o no pueden? Porque en algunos casos, sí es útil una redirección al trasladar, no siempre es sobrante. Si alguien me lo aclara, lo agradezco. --Fdo.: Gonzalo P.M.G. • 17:46 4 mar 2018 (UTC)

@Gonzalo P.M.G.: Sí, tienen una opción «Dejar una redirección» para decidir sí o no dejar redirección. --Wiki-1776 (discusión) 17:49 4 mar 2018 (UTC)

En principio yo estaría de acuerdo en agregarlo a las habilidades de los verificadores e incluso quizás también a los autoverificados, pero sin crear ningún grupo nuevo. Teniendo en cuenta que para otorgar esos permisos, es necesario evaluar el conocimiento de las políticas de estilo, es comprensible que si un verificador ve una página nueva con un título erróneo pueda realizar el traslado sin necesidad de generar una redirección innecesaria. Por otro lado, estoy de acuerdo en no integrar esta propuesta en la encuesta en desarrollo, dado que esta es la continuación de otra anterior y se centra en concretar más algunos puntos que quedaron sin definir. Además, dados los diferentes resultados de otras propuestas anteriores similares pero que agrupaban permisos (aceptada en 2013, pero rechazada en 2015), sugiero iniciar una nueva encuesta sencilla y más concreta para consultar la opinión actual de la comunidad. -- Leoncastro (discusión) 17:54 4 mar 2018 (UTC)

 A favor de un nuevo grupo de usuarios. 🙝 Miguu ¡Parlamenta! 18:19 4 mar 2018 (UTC)

Estoy preparando la encuesta. Qwertyytrewqqwerty (discusión) 18:22 4 mar 2018 (UTC).

La encuesta está redactada, y en preparación: Wikipedia:Encuestas/2018/Sobre el derecho suppressredirect. Qwertyytrewqqwerty (discusión) 19:06 4 mar 2018 (UTC).

•  Muy en contra Seguimos proponiendo permisos sin saber cómo funcionan ni si es viable técnicamente. Para trasladar sin redirección es menester poder borrar. Más fácil postularse a bibliotecario, o encontrar un método para que quienes tienen los botones los usen de una vez. --Saludos. Ganímedes 21:12 4 mar 2018 (UTC)

Ganímedes, parece ser que viable técnicamente es, puesto que ya se usa en en:wiki. scorpen buzón 21:16 4 mar 2018 (UTC)

Perdona si se me ha pasado algo por alto, Ganímedes, pero sigo creyendo que es viable técnicamente. En enwiki hay un grupo con este derecho y sin el de borrar, y aquí mismo los bots tienen ese derecho pero no el de borrar. En mw:Help:Moving_a_page#Moving_a_page_without_creating_a_redirect no dice nada de que sea un requisito poder borrar. No he leído esa parte del código fuente, pero no creo que sea necesario poder borrar. Otra cosa es si crees que es demasiado parecido a borrar como para dárselo a los usuarios de a pie. Qwertyytrewqqwerty (discusión) 21:21 4 mar 2018 (UTC).

Ahora sí lo he leído:

if ( !$handler->supportsRedirects() ) {
    $createRedirect = false;
} elseif ( $user->isAllowed( 'suppressredirect' ) ) {
    $createRedirect = $this->leaveRedirect;
} else {
    $createRedirect = true;
}

Y también:

if ( $createRedirect ) {
    if ( $this->oldTitle->getNamespace() == NS_CATEGORY
        && !wfMessage( 'category-move-redirect-override' )->inContentLanguage()->isDisabled()
    ) {
        $redirectContent = new WikitextContent(
            wfMessage( 'category-move-redirect-override' )
                ->params( $nt->getPrefixedText() )->inContentLanguage()->plain() );
    } else {
        $contentHandler = ContentHandler::getForTitle( $this->oldTitle );
        $redirectContent = $contentHandler->makeRedirectContent( $nt,
            wfMessage( 'move-redirect-text' )->inContentLanguage()->plain() );
    }
    // NOTE: If this page's content model does not support redirects, $redirectContent will be null.
}

Así que, si tienes suppressredirect, te deja elegir si se crea la redirección o no. En ningún caso se borra nada, ni se comprueba si puedes borrar o no. Saludos, Qwertyytrewqqwerty (discusión) 21:34 4 mar 2018 (UTC).

@Ganímedes, por si todo este código no te ayuda a ver nada en claro, te invito a leer mi comentario «A tener en cuenta» en la discusión de la encuesta, que me parece mucho más curioso y revelador. No se trata de viabilidad, actualmente ya es posible de un modo curioso. -- Leoncastro (discusión) 22:04 4 mar 2018 (UTC)

Gracias Leon, ya había leído tu comentario y no me interesa el código dado que soy un lego en la materia, pero sí conozco el artilugio desde mis épocas de bibliotecaria (y entonces ya los bots podían hacerlo, sin que esto le llamase la atención a nadie). Tengo la sensación (me disculpo si no es así) que hay una necesidad casi compulsiva por lograr que se repartan nuevos permisos. Como sea. El que sea. No importa si se puede o no, o si se hace en x o en y en forma experimental, o con tales o cuales condiciones. Tengo la sensación de que hasta que no se logre que se divida un permiso, seguirá esta danza de propuestas. Si estoy equivocada, me disculpo nuevamente. --Saludos. Ganímedes 22:13 4 mar 2018 (UTC)

Yo, que he propuesto esto, personalmente no estoy a favor de que se vaya repartiendo por ahí el permiso de bloquear. Probablemente tampoco el de borrar páginas. El de semiproteger, quizás. Pero pienso que este derecho que se discute aquí, a diferencia de otros, no forma parte de lo que hace a los biblios biblios.

Y mi idea con esta encuesta es que el derecho en cuestión se añada a un grupo ya existente, quizá el de verificadores (en el que yo no estoy ahora mismo). He considerado en la encuesta la posibilidad de crear un nuevo grupo, pero solamente por contemplar todas las posibilidades. No se trata de que se creen más grupos para coleccionarlos como si fueran cromos. Qwertyytrewqqwerty (discusión) 22:26 4 mar 2018 (UTC).

Puede que tu no lo veas así, pero no faltará quien sí lo haga. Basta ver que hay usuarios que nominan una y otra vez artículos que ni siquiera cumplen los requerimientos y en los que no han aportado ni una letra porque quieren "la estrellita". En todo caso no se trata de ningún "derecho". Un permiso, a lo sumo. --Saludos. Ganímedes 22:55 4 mar 2018 (UTC)

Quizá otros estén a favor de ir coleccionando permisos porque sí, pero no creo que eso sea motivo para no considerar las propuestas de añadir derechos. Este en concreto yo creo que es útil. Y lo llamo derecho porque es un user right. Permiso también valdría, pero la idea era distinguir entre el derecho y el grupo de usuarios que lo ostentan. Saludos, Qwertyytrewqqwerty (discusión) 23:05 4 mar 2018 (UTC).

(CdE) Yo lo veo muy válido. Tan válido como negarse a importar Quick Delete de Commons porque facilita la tarea del patrullero fomentando el plantillismo. En todo caso, no veo que sea un aporte fundamental al mantenimiento. ¿Por qué lo sería? --Saludos. Ganímedes 23:22 4 mar 2018 (UTC)

No es un aporte fundamental al mantenimiento. Pero, ponderando entre lo que ayuda (los bibliotecarios tienen un poquito menos de trabajo, algunos usuarios experimentados pueden llevar a cabo traslados complejos por sí mismos) y lo que perjudica (burocracia añadida si es un grupo independiente, riesgo de que alguien se dedique a hacer traslados vandálicos sin dejar redirección), creo que netamente merece la pena. Qwertyytrewqqwerty (discusión) 23:28 4 mar 2018 (UTC).

(otro CdE) Pues adelante con una nueva encuesta y después votación (que no es nada de burocracia, vamos). Hasta la próxima propuesta de fisión. --Saludos. Ganímedes 23:32 4 mar 2018 (UTC)

• Yo sé usarlo, lo tengo de manera global (aquí), pero prefiero que éste sea añadido al grupo local de reversores. Es muy fácil. No creo que sea buena idea que haya un nuevo grupo para ese permiso. Los usuarios con experiencia en reversión de vandalismo podrían también revertir traslados vandálicos pero como reversor (por ejemplo). --Stïnger （会話） 23:20 4 mar 2018 (UTC).

Yo creo que si se activa para los reversores deberían tenerlo los verificadores, que es el grupo más restringido después del de los bibliotecarios. --Metrónomo's truth of the day: «persevera y triunfarás» 01:37 5 mar 2018 (UTC)

Realmente el destino final del permiso me es indiferente, pero creo que es necesario descargar de trabajo a los bibliotecarios. Realmente es un permiso poco ambicioso (simplemente, te da la posibilidad de eliminar redirecciones que se realizan cuando se traslada una página, no da la capacidad de borrar cualquier redirección), por lo que sea un añadido a un grupo de usuarios asentados (ya sea reversores o verificadores) simplemente descargará de trabajo a los bibliotecarios. Kojie (Habla por esa boquita) 10:46 5 mar 2018 (UTC)

•  Muy en contra. Primero creo que se le está dando demasiada importancia a este permiso, y segundo creo que no se conocen muy bien las (perjudiciales) consecuencias de un uso incorrecto. En la Wikipedia en inglés, con casi 7000 verificadores (frente a los 232 de aquí) y casi 45 millones de páginas (frente a los poco más de 6 millones de aquí), solo hay 209 usuarios con este permiso (los verificadores no tienen este permiso). Si hacemos una estadística proporcional, este permiso apenas habría que dárselo aquí a 7 personas. De hecho, yo no encuentro ninguna necesidad de habilitar este permiso porque tampoco encuentro que los bibliotecarios estén saturados. Una cosa es que pueda haber bibliotecarios insuficientes y se necesitan habilitar permisos especiales para las cosas que requieran atención rápida, como combatir el vandalismo, pero otra muy distinta es habilitar permisos a otros usuarios para cuestiones menores pero que pueden suponer un problema si esos permisos se usan inadecuadamente.

Realizar traslados de página sin dejar redirección es una medida que debe hacerse cuidadosamente y de manera excepcional, ya que eso supone que las decenas de enlaces internos de otros artículos que apuntan a esa página, de repente dejarán de tener ese enlace o se le habrá cambiado por otra página distinta. No se puede realizar un traslado sin dejar redirección tan alegremente por mucho que ese traslado esté justificado. Mucho menos hacerlo con la excusa de que así se puede sustituir una página por otra, ya que eso supone cambiar la página que enlazan todos los enlaces de otros artículos y que pueden ser decenas, sin que además otros usuarios se hayan enterado. Trasladar una página sin dejar redirección supone que se deben revisar todas las páginas que enlazan a esa para estar seguros de que los enlaces quedan corregidos. De hecho, en la Wikipedia en inglés hay unos criterios claros y limitados sobre cuando utilizar este permiso. Eso queda muy lejos de la propuesta que se hace aquí de dar el permiso masivamente para usos que ni se contemplan en la Wikipedia en ingles y que además cada uno lo use a su criterio. Al final, con la (mala) excusa de liberar de trabajo a los biliotecarios, vamos a terminar matando moscas a cañonazos. --Tximitx (discusión) 12:11 5 mar 2018 (UTC)

Hola. Si por mí fuera, la encuesta sobre suppressredirect habría formado parte de otra. No es que yo quisiera darle más importancia de la que tiene. En la Wikipedia en inglés tienen cero bloqueadores/semiprotectores/etc. ¿Significa eso que debemos rechazar de plano la idea de tenerlos aquí? Para nada. Lo que hagan otras Wikipedias es algo que debe tenerse en cuenta, pero ni hay que copiar sus políticas ciegamente ni hay que dejar de probar políticas porque allí no las tengan. Si hay bibliotecarios insuficientes, eso es una cuestión distinta. Lo que busco con esta propuesta es ahorrarles una parte de su trabajo. la realidad es que a día de hoy no es posible arreglar el vandalismo de traslados (entre otros problemas) sin la intervención de un bibliotecario. ¿No es mucho lo que se les ahorra? Quizá no. Pero es algo.

El segundo párrafo sí que no lo entiendo. Se trata de dar el permiso a quienes conozcan suficientemente las políticas, que digo yo que acertarán a utilizarlo solamente cuando sea necesario, no "tan alegremente". ¿Cometerán errores alguna vez? Claro. Pero los biblios también, que la mayoría todavía son humanos. Mi idea es dar el permiso "masivamente" a los reversores o a los verificadores o a los autoverificados. ¿Me estás diciendo que quienes forman parte de esos grupos van a romper enlaces a lo tonto, sin fijarse? Si son tan torpes, ¿cómo pretendes tú darles los permisos de bloquear y semiproteger? ¿Esos no los usarán mal? ¿O pretendes que se use un criterio totalmente distinto al que se usa para asignar ahora mismo los grupos de reversor, verificador y autoverificado?

Los usos que tendría el permiso según mi propuesta creo que están claros:

1. No crear redirecciones al trasladar, cuando tales redirecciones estarían incursas en algún motivo de borrado rápido. (Esto es lo que pone en la página que enlazas, solo que además da algunos ejemplos que no pretenden ser un numerus clausus)
2. Quitar de en medio páginas que están incursas en algún motivo de borrado rápido, exclusivamente cuando estorben para otros traslados. (Esta segunda es más discutible, por eso la pongo aparte)

Y ya. Por último, si no te vale el motivo de liberar de trabajo a los biblios, tengo otro: el de permitir que los usuarios que han demostrado conocer las normas y estar dispuestos a cumplirlas puedan llevar a cabo traslados complejos cuando sea necesario, en lugar de dar injustificadamente un monopolio a los bibliotecarios sobre una parte de la gestión de una enciclopedia que se supone que todos pueden editar. Saludos, Qwertyytrewqqwerty (discusión) 12:59 5 mar 2018 (UTC).

Sobre incluir este permiso en otra encuesta, ya se han indicado los motivos del rechazo. En cualquier caso eso es indiferente para la propuesta. Tan valido es incluirlo en otra encuesta como proponerlo en una nueva, sin que eso tenga nada que ver con la propuesta. Lo que indico de que se le está dando desadiada importancia es porque en la Wikipedia en inglés, con muchisimos más usuarios y páginas que aquí, es un permiso minoritario, lo que quiere decir que no está claro que sea de excesiva utilidad o interés. Por lo demás yo no rechazo que se puedan proponer nuevos permisos, pero eso no quiere decir que se tenga que estar de acuerdo con esas propuestas. Los permisos de bloqueadores y semiprotectores son permisos propuestos por la comunidad (y no por mi) que por ahora cuentan con apoyo, y por eso se ha creado una encuesta. En este nuevo permiso de suppressredirect se ha preguntado aquí opiniones, lo que quiere decir que podré manifiestar mi opinión en contra (y no he sido el único). Si aún así se quiere realizar una encuesta, me parece bien, pero si se piden opiniones será para dar la opinión de cada uno y hacer una valoración, y no para convencer a nadie de si debe estar a favor o en contra. Si se quiere hacer la encuesta, me parece bien, pero por ahora yo en este hilo he contado tres a favor y tres muy en contra. Si se ignoran las opiniones en contra los antecedentes indican que la propuesta no contará con los apoyos necesarios, pero como tu veas. ¡Adelante con la encuesta!

Lo de ahorrarle trabajo a los bibliotecarios, ya he indicado que yo no veo que los bibliotecarios estén saturados, es decir, que yo no encuentro que haya que liberarles de trabajo, ni que este nuevo permiso vaya a mejorar la situación, pero es mi opinión.

En cuanto al segundo punto, no se trata solo de conocer las políticas, sino de hacer un buen uso de los permisos. Los reverseros y verificadores han sido aprobados para hacer un uso de esos permisos, pero no han sido validados para este nuevo permiso. Eso no quiere decir que si se les concediera este permiso vayan a hacer un mal uso del mismo, pero tampoco se puede estimar que lo vayan a saber utilizar correctamente. Por ejemplo, el permiso para bloquear a usuarios vándalos se propuso darlo a todos los reversores como en la Wikipedia en portugués, donde están haciendo un buen uso del mismo, pero aquí se ha estimado que deben darse por separado porque debe valorarse por separado el uso de los permisos. Con este nuevo permiso algunos también podemos estimar que darlo a todos los verificadores es darlo maxivamente sin justificación. Que esos usuarios tengan experiencia, no quiere decir que debamos considerar que vayan a hacer un buen uso del nuevo permiso y concederselo sin más. Los permisos para bloquear vándalos o semiproteger páginas se han propuesto para grupos de usuarios nuevos, que serán valorados para utilizar esos permisos específicamente. Eso es muy distinto a ampliar los permisos a un grupo de usuarios ya existente. Algunos podrán estar a favor, pero otros podemos estar en contra. Eso no quiere decir que estimemos que se va ha hacer un mal uso del permiso, sino simplemente que no lo consideramos adecuado y estimamos que no deben concederse de manera general a ningún grupo de usuarios existente actualmente.

Por último rechazo el argumento de que los bibliotecarios tengan el monopolio de algunas funciones. Los bibliotecarios (administradores en otras Wikipedias) administran algunas funciones en exclusiva porque se consideran que son críticas para concederlas de manera general, como el poder trasladar páginas sin dejar redirección (pudiendo dejar decenas de enlaces internos rotos). Eso no quiere decir que alguno de estos permisos no se puedan conceder a otras personas, pero tampoco que debamos estar de acuerdo. En cualquier caso no existe ningún monopolio porque los bibliotecarios no son ningún grupo homogeneo que actúen de manera coordinada. --Tximitx (discusión) 14:28 5 mar 2018 (UTC)

Por supuesto que no tienes que estar de acuerdo y que puedes dar tu opinión. Y, a su vez, yo puedo dar mi opinión sobre tu opinión, y así sucesivamente. En eso consiste un debate, ¿no? Tú ves tres a favor y tres muy en contra. En esta discusión yo veo seis a favor de la propuesta en alguna de sus modalidades (a mí mismo, a Scorpen, a Miguu, a Leoncastro, a Stinger y a Kojie) y dos "muy en contra" (Ganímedes y tú). No cuento el "muy en contra" de MarcoAurelio porque se manifestó en contra solamente de la creación de un grupo nuevo. El 75% de los "votos", que sería más que suficiente si esto fuera una votación (es verdad que el tamaño muestral es pequeñito). Puedes estar en completo desacuerdo con mi idea, pero no me digas que no hay suficientes avales como para consultar a la comunidad por medio de una encuesta. Saludos, Qwertyytrewqqwerty (discusión) 14:58 5 mar 2018 (UTC).

No necesitas avales para hacer una encuesta (aunque presiento que lo harás de todas formas así que ya qué) --Saludos. Ganímedes 15:10 5 mar 2018 (UTC)

No, pero no la haría si todo el mundo estuviera en contra. Era una respuesta a «la propuesta no contará con los apoyos necesarios». Saludos, Qwertyytrewqqwerty (discusión) 15:18 5 mar 2018 (UTC).

Yo no he dicho que no haya avales para realizar la encuesta. De hecho, no los necesitas. Lo que he indicado es que se está minusvalorando las opiniones en contra del permiso, o eso es lo que a mi me parece. Tal vez las opiniones en contra sean minoritarias (la encuesta lo dirá), pero cuando se pide opinión en el Café, es para obtener la opinión de la comunidad, buena y mala, sobre la propuesta, para hacer una valoración. Si lo que quieres no es hacer una valoración, sino convencer de las bondades del permiso, entoces no hagas una encuesta, sino que propón directamente una votación formal para aprobar el permiso directamente. Yo he dado los motivos de mi rechazo a la propuesta. Si tú consideras, que puede obtener suficiente apoyo o que debes seguir con la encuesta, adelante, pero no pretendas convencerme revatiendo mis argumentos. A quien tienes que convencer es a quienes participen en la encuesta, y por experiencia te diré que las propuestas improvisadas y poco definidas no suelen contar con el apoyo necesario para aprobarse. No obstante, lo dicho, puedes seguir con la propuesta si la consideras adecuada, que lo que valdrá es lo que salga en la encuesta y no lo que yo opine. --Tximitx (discusión) 15:48 5 mar 2018 (UTC)

Perdona, no quería que te lo tomaras a mal. Mi idea era contrastar nuestros puntos de vista para que quien lea esto, si alguien lo lee, se forme su opinión. No es que esperara convencerte a ti, y no quería minusvalorar otras opiniones. Gracias por tus comentarios. Qwertyytrewqqwerty (discusión) 15:56 5 mar 2018 (UTC).

Disculpa Qwertyytrewqqwerty, pero yo solamente me he mostrado de acuerdo, en principio, con una propuesta en concreto, por lo que si esa no es la mayoritaria en la encuesta, seguramente yo vote en contra en una futura votación formal. Y aunque salga favorable, dependerá también de la redacción final de la votación y las condiciones de la política que se defina al respecto. Eso es lo que significa «en principio», es decir, que demomento estoy a favor de realizar la encuesta.

Por un lado me resulta curioso que yo sí puedo hacerlo —a través de mi bot—, mientras que por ejemplo Ganímedes —con los mismos permisos— no puede. Por otro lado, cualquiera puede escribir un {{destruir|R3}} y dejar que decida el bibliotecario que lo atienda.-- Leoncastro (discusión) 16:20 5 mar 2018 (UTC)

Sí, entendí lo que querías decir. Solamente pretendía defender la necesidad de la encuesta (por eso dije "a favor de la propuesta en alguna de sus modalidades"). Perdona si di a entender que estábamos de acuerdo en todo los seis que dije. Qwertyytrewqqwerty (discusión) 16:29 5 mar 2018 (UTC).

"pretendía defender la necesidad de la encuesta" - Necesidad, como necesidad, no hay. Pero nadie puede impedirte que la lances de todos modos. Ni permiso necesitas para eso. --Saludos. Ganímedes 13:05 7 mar 2018 (UTC)

Perdón, utilidad más que necesidad. Es verdad que no es de vida o muerte ni nada. Saludos, Qwertyytrewqqwerty (discusión) 13:23 7 mar 2018 (UTC).

Puesto que no parece haber más comentarios, la encuesta quedará abierta el sábado, 10 de marzo de 2018 a las 00:00 (UTC). Saludos, Qwertyytrewqqwerty (discusión) 10:30 9 mar 2018 (UTC).

Queda abierta la encuesta. Qwerty | ytrewq | qwerty 00:02 10 mar 2018 (UTC).

@Qwertyytrewqqwerty, sería buena idea anunciarlo también en la cartelera y el Café de noticias. -- Leoncastro (discusión) 01:40 10 mar 2018 (UTC)

Qwertyytrewqqwerty y Leoncastro, si no os importa, ya lo he anunciado en la cartelera y el Café de noticias, aprovechando las búsqueda que he hecho de él, este es el enlace wikipedia:Encuestas/2018/Sobre el derecho suppressredirect. MONUMENTA Discusión 02:08 10 mar 2018 (UTC)

Rehabilitación de Plantilla:Esbozo

Buenas a todos. Sugiero la rehabilitación de la plantilla debido a que hay algunos esbozos por la Wikipedia, y (creo que) no se señalan ni se categorizan de ninguna forma. E incluso si lo hacen, un lector ocasional probablemente no se percate de que está leyendo un esbozo. Otro motivo es que traduciré este artículo, y quiero indicar que se trata de un esbozo (justo como se indica en la Wikipedia inglesa). Ahora, si la plantilla se llegara a rehabilitar, sugiero que se modifique debido a que el texto actual no es muy apropiado (al memos en mi opinión). Un saludo.  The  Shudder  | 00:36 3 mar 2018 (UTC)

•  En contra por todos estos argumentos. -- Leoncastro (discusión) 01:53 3 mar 2018 (UTC)
•  En contra. 🙝 Miguu ¡Parlamenta! 21:57 3 mar 2018 (UTC)

Además de los motivos expuestos en las consultas de borrado, la plantilla de esbozo daba un trabajo enorme de mantenimiento y categorización que ya entonces era inabarcable. Puedo dar fe de ello porque mis primeros meses en Wikipedia lo pasé categorizando esbozos hasta que me di cuenta que no servía para nada ni ayudaba a ampliarlos. Creo que cualquier lector ocasional si lee un artículo de 4 líneas sabe que es corto comparado con uno de 8000, no hace falta ponerle una plantilla. De todas formas la labor de identificar artículos con poca información y que se pueden ampliar con facilidad puede hacerse a nivel de plantillas de wikiproyectos y en la página de discusión del artículo. Un saludo, --Morza (sono qui) 12:09 4 mar 2018 (UTC)

Casi no trabajo con esbozos, pero me parece que hay otra plantilla u otro procedimiento a seguir con artículos que tienen la situación de ser esbozos, desde que la plantilla cayo en desuso. Pero no se a ciencia cierta, que plantilla usan actualmente. --Леон Поланко говорит вам и слушает вас 05:35 7 mar 2018 (UTC)

• Comentario yo creo que el asunto interesante es que con la plantilla de infraesbozo se establece un periodo en donde si el artículo no es ampliado, será eliminado y esto para mi es un gran error. Hay artículos que efectivamente son reducidos, pero que aún así aportan valor y al categorizarlos como infraesbozos (pese a ser esbozos) puede acabar destruidos. -- Viajaste · ¿Hablamos? 02:02 10 mar 2018 (UTC)
•  Muy en contra Los artículos breves son totalmente válidos, muchas veces crucialmente importantes y no necesitan marca alguna. Por otra parte, lo que señala Viajaste es un error lamentablemente frecuente de patrulleros inexpertos que cualquiera puede y debe revertir. Si además acabaran borrados (que no me consta) sería un error gravísimo del biblitecario que borra, porque es quien tiene la responsabilidad de revisar lo que los autodenominados «patrulleros» le marcan para borrar. Si no fuese así, bastaría un bot que borrara todo lo que lleva plantillas en lugar de bibliotecarios y no necesitaríamos ponernos tiquismiquis con los candidatos en las elecciones porque el poder de decisión sobre lo que aquí tiene cabida o se borra recaería en cualquier chico entusiasta que a las dos semanas de participación ya tiene instalado el dibujito del policía en su página y reparte plantillas a piacere. Mar del Sur (discusión) 09:53 10 mar 2018 (UTC)
• Comentario Perdón por ser inexperto @Mar del Sur. Gracias por aclararme el asunto. -- Viajaste · ¿Hablamos? 13:31 10 mar 2018 (UTC)

Venga, Viajaste, si lo dices sin ironía: no tienes que disculparte por ser inexperto ¡faltaba más! Todos lo fuimos y lo seguimos siendo en muchos campos de trabajo de este proyecto. Si hay ironía en tu comentario, pues... ¡me disculpo yo! De veras no he querido utilizar la expresión «inexperto» de ningún modo desagradable, aunque sí he dejado traslucir mi opinión: jamás he compartido esto de ponerse "a patrullar" y a poner plantillas a destajo cuando uno tiene todavía muy poca experiencia general en editar aquí. Pienso que todos podríamos ayudar a orientar a esos editores novatos hacia otras tareas antes de esto de poner plantillas... sencillamente porque las ponen mal. Mar del Sur (discusión) 14:04 10 mar 2018 (UTC)

No lo decía con ironía, siento que aquí en Wikipedia cuando peco de inexperto, pues parece que algunos usuarios tratan el tema de manera muy ruda o sin explicar lo que pasa, así que gracias por argumentarme el asunto :) -- Viajaste · ¿Hablamos? 15:01 10 mar 2018 (UTC)

A tu entera disposición en mi discu, Viajaste, para cualquier duda con este u otros temas. Mar del Sur (discusión) 01:20 13 mar 2018 (UTC)

Nueva propuesta

Y si se le agregara a la portada las secciónes: un día como hoy, imagen destacada y sabias que ya que actualmente esta muy pobre. Atolon1945 (discusión) 03:34 13 mar 2018 (UTC)

Dos de las propuestas ya están agregadas en la portada; «Un día como hoy» se llama Efemérides, mientras que «imagen destacada» se llama Recurso del día. Por su parte, «sabías qué» se ha propuesto en varias ocasiones, pero no se en que ha quedado. Saludos. --Pzycho10 (discusión) 03:45 13 mar 2018 (UTC)

Hola, Pzycho10 y Atolon1945. Dos usuarios estamos trabajando para revivir SQ. Hay mucho trabajo, porque hay que revisar los SQ viejos, buscar fuentes, reescribir y traducir... Son bienvenidos si quieren colaborar. No estamos coordinando aquí: Usuario:Marcosm21/Sabías que. --Saludos. Ganímedes 12:32 13 mar 2018 (UTC)

Modificar el color de la bienvenida

Para gustos, los colores pero... el color no es solamente una cuestión de gustos. Incluso hay ramas de la psicología dedicadas especialmente al estudio de las emociones que despiertan los colores y las asociaciones que evocan. Me parece que el color que tenemos no es una buena opción. El amarillo es un color muy contradictorio que si bien despierta algunas emociones alegres (sol, verano, calidez), también es el color que, en encuestas, las personas asocian a muchos sentimientos negativos (de celos, envidia, engaño, falta de rectitud). Es también el color de las advertencias (por ejemplo, los letreros de peligro son amarillo y negro; junto al naranja, el amarillo es el color más usado para símbolos de veneno y sustancias tóxicas). En el semáforo indica precaución. Además, el amarillo que tenemos en la página de bienvenida tiene un tono con tintes de marrón, sobre todo en el fondo tiende más al más sepia que el amarillo del encabezado. Y marrón es un color que casi no despierta asociaciones positivas. Se suele asociar a lo complejo, a lo antiguo, seco, marchito y sin vida. Las mejores alternativas que tenemos son los tonos verdes y azules. Gris azulado, como todas nuestras páginas, podría ser, pero destacaría poco en la bienvenida. Propongo verde (como ya tenemos en algunas páginas de ayuda). Hice una prueba con un verde en una subpágina, pero por cierto, se puede jugar con las tonalidades. Verde, en el semáforo, indica ¡adelante, pase! (muy compatible con una bienvenida. Verde es el color de lo joven, de la esperanza, de lo que está en desarrollo, se asocia a frescura y a lo natural. El verde claro (con más amarillo que azul) es menos frío (porque recoge la calidez del amarillo). Tal vez alguien más avezado que yo en el manejo de los códigos de los colores web pueda jugar más con los tonos. Por de pronto dejo mi propuesta hasta aquí : Cambiar el color marchito de nuestra bienvenida y agradezco vuestras opiniones para que entre todos encontremos algo más adecuado, no necesariamente el verde que yo propongo. Mar del Sur (discusión) 11:34 15 mar 2018 (UTC)

Lo cierto es que la plantilla existe en varios colores amarillo anaranjado, azul, puede que en más... En verde no me parece ni mejor, ni peor a esas dos. Saludos. Bernard - Et voilà! 11:47 15 mar 2018 (UTC)

Gracias Bernard por tu opinión de la que, según entiendo, a ti el color te da más o menos lo mismo. Por supuesto, yo estoy hablando de modificar el color que aparece por defecto cuando hoy alguien simplemente escribe {{sust:Bienvenida}} Claro que todos sabemos que cualquiera puede editarlo y ponerle el color que más le guste (como en el caso de la plantilla azul que enlazas) y claro que existen un par de variantes más como {{Bienvenida grupo}}, {{Bienvenida condensada}} y {{Bienvenida ampliada}}. La plantilla principal de bienvenida ({{Bienvenida}}, que es la que yo quisiera modificar) ya ha tenido también algún cambio de color anteriormente y hay páginas (dependiendo si se ha copiado su código, se ha editado o si se ha usado con "subst:") que conservan el color antiguo. Mar del Sur (discusión) 12:20 15 mar 2018 (UTC)

PD: Me corrijo: Bernard, la bienvenida azul que enlazas no se editó, como pensé, sino que se hizo con Twinkle que hace muchos años ya no funciona en este proyecto. Mar del Sur (discusión) 12:39 15 mar 2018 (UTC)

Eso es. Era más que nada para mostrar variaciones existentes. Puede que algún script maneje otras, no lo sé, tampoco soy mucho de usar este tipo de automatizaciones para poner avisos y demás. Saludos. Bernard - Et voilà! 13:00 15 mar 2018 (UTC)

A mi no me molesta, mientras no pierda uno la vista intentando diferenciar el texto del fondo.[4][5] La versión azulada de Twinkle corresponde a la plantilla {{Bienvenida Twinkle}}, aunque también hay otras no mencionadas como {{Bienvenida antigua}}, {{Bienvenida con galletas}}, {{Bienvenida con Ikebana}}, y más aún si consideramos las relacionadas a los wikiproyectos.[6] -- Leoncastro (discusión) 13:41 15 mar 2018 (UTC)

A mí me gustó el color propuesto por Mar del Sur, por lo menos a mí me dio una sensación de paz. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 14:56 15 mar 2018 (UTC)

┌─────────────────────────────┘
A mí me parece un poco «chillante» el tono de verde, no sé como decirlo correctamente, fue un tanto molesto para mis ojos. Tal vez con algún matiz. En lo personal a mí me agrada el color que se usa ahora, me parece cálido.--Rosymonterrey (discusión) 15:04 15 mar 2018 (UTC)

Sé que hay muchas plantillas diferentes. Yo estoy hablando de la plantilla estándar por defecto, la más enlazada {{Bienvenida}}. También sé que habrá muchos gustos, también diferentes, por eso he tratado de aportar argumentos.... Mar del Sur (discusión) 15:08 15 mar 2018 (UTC)

Totalmente de acuerdo contigo Mar del Sur, el color verde estaría más que bien para una plantilla de bienvenida, sin descartar las tonalidades azules suaves que también serían adecuadas. Véase el artículo psicología del color para un mejor entendimiento. Gracias por la propuesta. ¡Saludos!. -- J☮AN | ¿Conversamos? 15:34 15 mar 2018 (UTC)

@Mar del Sur, con tu permiso me dio por «jugar más con los tonos», modificando ligeramente los colores: el resultado puede verse en esta versión.

@Rosymonterrey, ruego nos comentes si con esta nueva versión sigues viendo los colores «chillantes». -- Leoncastro (discusión) 16:15 15 mar 2018 (UTC)

Parece ligeramente más suave el fondo y molesta menos.--Rosymonterrey (discusión) 16:22 15 mar 2018 (UTC)

A mí ese verde no me gusta, lo tenemos en los emoticonos del móvil indicando enfermedad. Pero si no lo tengo que ver todos los días en mi página, me conformo. Lourdes, mensajes aquí 16:43 15 mar 2018 (UTC)

Como indiqué, no soy muy buena en ajustar colores web, así que muchas gracias, Leoncastro, por las pruebas. Yo también pienso, al igual que Rosy, que hay que buscar el tono menos «chillón», pero de verde o de azul, porque, según los entendidos, son los colores que despiertan mayoritariamente asociaciones más adecuadas a nuestros propósitos. Porque si fuese por gustos, pues... mi (no)color favorito es el negro, pero parece que no nos sirve mucho :-). Mar del Sur (discusión) 17:28 15 mar 2018 (UTC)

Pues además del tono verde, también pruebo en tono azul. A ver qué tal.-- Leoncastro (discusión) 18:38 15 mar 2018 (UTC)

En ese caso, Leoncastro propondría un celeste cielo. Para mí es transparencia y pureza. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 19:11 15 mar 2018 (UTC)

Buenas a todos. Si se modifica el color de la bienvenida, a los que ya la tenemos en nuestras discusiones (o en un archivo de las mismas), también se nos cambiaría, ¿no? Aunque yo creo que sí, pregunto porque no soy nada docto en el tema de las plantillas. Por cierto, a mí me parece que como está ahora está bien, aunque aceptaré cualquier decisión que se tome. Saludos. --Fdo.: Gonzalo P.M.G. • 19:25 15 mar 2018 (UTC)

@Gonzalo P.M.G., depende de si se usó directamente la plantilla o si fue sustituida. Si se usó {{bienvenida}}, entonces el color y formato del mensaje cambiará cada vez que se edite la plantilla; sin embargo, si se usó {{sust:bienvenida}} (nótese el prefijo «sust:») entonces el mensaje fue reemplazado por el contenido de la plantilla en ese momento, y los posteriores cambios a la plantilla no le van a afectar. -- Leoncastro (discusión) 00:02 16 mar 2018 (UTC)

┌─────────────────────────────┘
Estoy  En contra de modificar los colores con los argumentos expuestos. Para empezar, la plantilla actual no usa colores o tonos amarillos, sino más bien naranja claro. Cierto que los tonos amarillos o naranjas se usan para advertencias, sustancias tóxicas (junto con el negro), etc., pero siempre que sean en tonos fuertes y no en tonos claros. La razón no es porque esos colores sean negativos, sino simplemente porque esos colores en tonos fuertes, llaman más la atención y la gente se fija más en ellos. Por ejemplo, el rojo y el amarillo son utilizados por cadenas de comida rápida, que no creo yo que lo usen porque se asocie a peligro o veneno, y el naranja también es usado por una conocida marca de telefonía, y no creo que sea porque se asocie a toxicidad o precaución. El significado dependerá de donde se use y del mensaje que lo acompañe, y no del significado del color en sí mismo. De hecho los colores, aunque puedan transmitir distintos sentimientos (positivos y negativos), no tienen ningún significado en si mismos.

Por otra parte, los sentimientos de los colores en fuentes luminosas (como las pantallas de ordenador) es diferente al sentimiento de los colores sin fondo luminoso. En el caso de fuentes luminosas, los colores rojos, naranjas y amarillos se consideran cálidos y cercanos, mientras que los colores azules y verdes se consideran fríos y distantes [7]. De hecho, para quienes utilizamos el ordenador de noche, los tonos azules se consideran perjudiciales para la salud por las molestias que causan [8] [9]. Si vemos lo que significan los distintos colores web, tenemos que los naranjas (que son los colores usados actualmente en la plantilla de {{bienvenida}}) no solo no son negativos (alegría, juventud... aumenta el optimismo, la seguridad, la confianza y el equilibrio), sino que el azul por ejemplo puede transmitir depresión o indiferencia [10]. En resumen, que eso de que tal o cual color tiene tal o cual significado, es bastante discutible.

Por mi parte, yo prefiero que la plantilla de bienvenida tenga tonos cálidos (cercanos) en lugar de tonos fríos (distantes), y prefiero tonos claros (calmados) a tonos fuertes (agresivos). Podrá haber distintos gustos sobre los colores o tonos a usar, pero creo que los naranjas actuales están bastante bien, y desde luego mejor que con verdes o azules. --Tximitx (discusión) 21:42 15 mar 2018 (UTC)

Tximitx tiene razón en que no existe un significado unívoco de los colores. El asunto es mucho más complejo y multidimensional. Lo que la psicología ha estudiado es que los colores transmiten sentimientos y producen emociones en contextos determinados. Nadie podría seriamente hacer un diccionario de colores con sus respectivos significados. Por ejemplo, para el diseño de envases de alimentos se prefiere rojo, amarillo, los tonos cálidos y anaranjados, los colores fuertes y definidos. Allí no alteran ni son agresivos (como sí serían en la pared de una sala de clases de la escuela) Los mismos colores no serían los mejores para detergentes o productos de limpieza, donde es más atractivo el verde o el azul. Pero aquí no vendemos papas fritas, ni detergente. Cuando argumentaba, lo hacía en el contexto comunicativo de la bienvenida (luz verde, señal de paso) a este proyecto (una enciclopedia en constante desarrollo) y comentaba las asociaciones de lo verde con lo en desarrollo en comparación con lo amarillo/marrón (así lo veo yo, no sé dónde ven el naranja) y lo que que en contextos de comunicación transmite: advertencia, precaución (amarillo) y antiguo, marchito (marrón). No he pretendido decir que los colores significan algo unívoco. Por cierto, a mí ya nadie me dará la bienvenida, de modo que personalmente, todo esto me da igual. Es solo una de mis tantas preocupaciones sobre el mensaje e imagen que transmitimos a los recién llegados. Mar del Sur (discusión) 02:44 16 mar 2018 (UTC)

En el contexto comunicativo, los colores no tienen ningún significado, sino que el significado depende del mensaje. Si pones el amarillo en un cartel con un hombre electrocutándose, tienes un cartel de advertencia de peligro de electrocución; pero si en el cartel con fondo amarillo pones la palabra "taxi", tienes un cartel informativo (y no de advertencia ni de peligro) de un medio de transporte. Lo que da el mensaje es el contenido del cartel y no el color. El hecho de que se use el amarillo en las señales de peligro es porque se trata de un color llamativo que capta la atención, exactamente la misma razón por la que los taxis en EE.UU. son amarillos. Si nuestro cerebro asociara mensajes con determinados colores sin discernir según el contexto, el negro no podría ser a la vez el color de la elegancia y del luto, ya que siempre que vistiéramos de negro transmitiríamos el mensaje de que estamos de luto. No confundamos el "usar" algunos colores en determinados mensajes o contextos con "transmitir" ese mensaje o contexto. Lo que sí que transmiten los colores son sensaciones o emociones, pero no mensajes (el "peligro de electrocución" es un mensaje y no una sensación; nadie siente peligro por ver un cartel de peligro por muy amarillo que sea, sino que solo se le advierte del peligro). Estas sensaciones no son ni buenas ni malas por el color, sino que dependerá del contexto y del mensaje que le acompañen. Por ejemplo, McDonald's en su logotipo usa un fondo rojo en EE.UU., mientras que usa un fondo verde en Europa. En EE.UU., donde la comida rápida se acepta como parte de su cultura, el rojo que transmite sensación de dinamismo y deseo parece adecuado, pero en Europa, donde la cultura de la comida es más un concepto de relaciones sociales y de salud, se opta por el verde que transmite relajación y calma. Ni uno ni otro es mejor, sino que el contexto en el que se usa es diferente. No se ha cambiado el fondo porque el rojo sea peligro (sea usa en muchos alimentos) o porque el verde sea ecología (poco tiene de ecológico un McDonald's), sino porque el concepto de lo que es comer es diferente en una cultura (comida rápida) y otra (comida lenta). De hecho no solo el color del logotipo es diferente, sino que los McDonald's en Europa son más cómodos e invitan a quedarse más tiempo, simplemente porque en Europa la comida se hace más pausada y se valora más el estar cómodo y relajado en el restaurante.

Volviendo a Wikipedia, el que se use uno un otro color no es ni mejor ni peor. Los colores cálidos (rojos, amarillos, naranjas y marrones) transmiten cercanía y dinamismo; los colores fríos (azules, verdes, morados) transmiten tranquilidad y profesionalidad. Ni unos ni otros son mejores, ya que no tienen ningún significado concreto. Aquí podemos valorar si preferimos unos colores u otros (yo prefiero los tonos cálidos) o la sensación que percibimos con cada uno (si nos gustan más o menos), pero cualquier apreciación no dejará de ser personal. Desde luego lo que no podemos hacer es decir que tal color es bueno o malo porque transmite tal o cual mensaje, ya que eso es totalmente falso. Los colores no transmiten ningún mensaje, ya que el mensaje lo da el contenido y el contexto. --Tximitx (discusión) 12:38 16 mar 2018 (UTC)

No encuentro muy favorable esta propuesta, porque mientras a algunos usuarios les puede resultar grato algunos colores, a otros puede afectarles su sensibilidad, e incluso podría detonar ansiedad, no soy psicólogo, pero medianamente esto conozco de los colores. Consíderese no solo a usuarios registrados, sino también usuarios lectores, que efecto podría tener. Si a mi me afecta un color, a otro tal vez no y viceversa. Se gastaría mucho tiempo en estar investigando que efecto trae a cada usuario este cambio de colores. Realmente no me parece de utilidad practica. --Леон Поланко говорит вам и слушает вас 05:19 16 mar 2018 (UTC)

A mí personalmente me resulta curioso que siendo mi color favorito el verde, en cualquiera de sus tonalidades, en la bienvenida lo encuentro frío y carente de emoción. Prefiero el que tenemos ahora, porque se me antoja más cálido y legible. rodracer M 15:12 16 mar 2018 (UTC)

Me pasa lo mismo que a Rodracer. Sin tener conocimientos profundos de lo que transmiten los colores, así instintivamente se me hace más cálida la bienvenida anaranjada actual (y no solo actual, que ya era así cuando me la dieron a mí hace casi once años) que las propuestas que he visto en verde y azul. Pero es solo una opinión personal, si la percepción general es distinta, pues adelante con los cambios. Furti (discusión) 16:26 16 mar 2018 (UTC).

Para gustos, a mí me parece más neutral, mejor y bien combinado los no-colores negro y blanco, quizá el gris. Los tres son concordantes con el estilo general de la página. 🙝 Miguu ¡Parlamenta! 18:55 16 mar 2018 (UTC)

A mí me parece más amable y positivo el verde. El color actual —que a duras penas llamaría naranja— se me hace no exactamente "desagradable", pero sí anodino y falto de gancho, en términos metafóricos casi diría que como con olor a escapulario y a vieja. Aun así, la Comunidad —y sus gustos mayoritarios— mandan, obviamente. strakhov (discusión) 23:22 16 mar 2018 (UTC)

 A favor del color verde. A mí me produce una sensación más amistosa y relajante que el color indefinido de ahora. Anna (Cookie) 05:18 17 mar 2018 (UTC)

 A favor también del verde de la nueva versión, que ya no resulta chillón como el primero, y sí amistoso y relajante, como dice Cookie. rodracer M 12:53 17 mar 2018 (UTC)

¿Sería posible, de paso, rediseñar la plantilla? Creo que NaBUru38 había creado un borrador en el que se ordenaba mejor y se quitaban enlaces repetidos...--Saludos. Ganímedes 16:19 17 mar 2018 (UTC)

Hola, no recuerdo haber hecho propuestas de mejorar la plantilla de bienvenida. Coincido en que sería conveniente reducir la cantidad de enlaces. Sobre el diseño, propongo usar un estilo similar al de la introducción de Portal:Comunidad y al de Ayuda:Contenidos. Saludos, NaBUru38 (discusión) 22:49 18 mar 2018 (UTC)

Sí, aparte del color, sería estupendo hacer algunas otras modificaciones. Son demasiados enlaces, por empezar. Deberíamos concentrarnos en lo esencial, sin agobiar al recién llegado transmitiéndole la impresión de que debe leer tremendos tochos antes de comenzar. Y hay varios cuya presentación podrían mejorarse, por ejemplo, este enlace:

Cosas que no se deben hacer.
Resumen de errores más comunes que evitar.

no me gusta porque promete algo que no brinda. Podría hacerse una lista de los errores más comunes a evitar, pero definitivamente WP:NOES no es eso, sino el acercamiento a una definición del proyecto por la vía de establecer lo que no es, los contenidos que aquí no tienen cabida. Propongo enlazarlo de otra manera, podría ser algo así:

Lo que Wikipedia no es.
Entérate de los contenidos que no son apropiados para este proyecto.

Mar del Sur (discusión) 01:43 20 mar 2018 (UTC)

Real Academia Nacional de Medicina. Actualización de datos corporativos y biográficos

Hola, buenas. Estoy interesado en actualizar los datos de la entrada de la Real Academia Nacional de Medicina, ya lo he hecho algunas veces, pero añadiendo artículos de sus Académicos y Académicas que aún no tienen. En primer lugar, me gustaría comenzar por sus Presidentes. Puedo contactar directamente con la Real Academia para que me faciliten los datos. Espero vuestras consideraciones, es un proyecto que quise comenzar hace tiempo y ahora me gustaría retomar. Gracias y un saludo. I.camposgomez (discusión) 23:09 18 mar 2018 (UTC)

Date una pequeña vuelta en Wikipedia:Fuentes fiables. Se podría considerar fuente primaria cualquier contenido añadido que no mencione fuentes independientes, y preguntar a la real Academia me parece que no es válido si no se aporta una referencia independiente de la Academia de Medicina. --Леон Поланко говорит вам и слушает вас 12:26 21 mar 2018 (UTC)

Permisos de bloqueo y semiprotección

Se ha cerrado la encuesta sobre los permisos de bloqueo y semiprotección, en cuyos resultados la mayoría se ha opuesto a ambos permisos.

Por supuesto respeto la opinión de la comunidad, pero me gustaría saber que ha pasado para que desde la primera encuesta en la que la mayoría de la comunidad estaba a favor de estos permisos, ahora haya cambiado de opinión y se muestre mayoritariamente en contra. --Tximitx (discusión) 11:49 24 mar 2018 (UTC)

No hay mucho para explicar Tximitx: Has preguntado lo mismo, pero no te han contestado los mismos. En una encuesta se pronunciaron unos y en la otra, otros. El conjunto intersección está constituido por muy pocos usuarios y esos, casi no han cambiado de opinión, al menos no mucho más que lo que ocurre incluso dentro de una misma votación, donde las personas a veces cambian de parecer. Yo misma, por cierto, he cambiado a veces de idea, pero en este caso me opuse ambas veces. Mar del Sur (discusión) 12:26 24 mar 2018 (UTC)

Ya sé que las personas cambian de opinión. Lo que pregunto es porque han cambiado de opinión en este caso (quienes lo hayan hecho), o si se prefiere, porque hay muchas personas que votaron que sí en la primera encuesta y ahora se han abstenido, lo que no ha ocurrido con quienes votaron que no. Simplemente es para poder sacar una conclusión de que es lo que ha pasado, puesto que no entiendo muy bien como antes había una mayoría suficiente para aprobar los permisos (más de 2/3 a favor) y ahora ni si quiera se llega al 50%. Me parece un cambio de porcentaje relevante. --Tximitx (discusión) 13:10 24 mar 2018 (UTC)

Es bueno aclarar que el no ganó por un margen de 1 o 2 votos, por lo que, teniendo en cuenta los resultados y participación de la anterior encuesta, aún cabría la posiblilidad de aprobarse una votación, con una tercera encuesta. 🙝 Miguu ¡Parlamenta! 21:47 24 mar 2018 (UTC)

Sea como sea, será mejor mantener un tiempo prudencial antes de iniciar una nueva encuesta al respecto. -- Leoncastro (discusión) 21:54 24 mar 2018 (UTC)

¡! ¿Tercera encuesta para lo mismo? Creo que quedó claro que la comunidad decide no crear este nuevo permiso. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 21:56 24 mar 2018 (UTC)

No @Penquista, no se vé un resultado negativo, en realidad, eliminando los usuarios repetidos y fusionando los resultados, hay un 61% de usuarios a favor y un 38% en contra de la implementación del permiso para semiproteger páginas. 🙝 Miguu ¡Parlamenta! 22:59 24 mar 2018 (UTC)

Puede que el resultado no haya sido desfavorable a la creación del permiso, pero tampoco suficiente. Por eso he pedido un tiempo prudencial. -- Leoncastro (discusión) 23:02 24 mar 2018 (UTC)

┌─────────────────────────────┘
Un resultado favorable Miguu es de los 2/3 de los usuarios (un 66,6%). No se ha conseguido ese resultado, por lo tanto es desfavorable. Saludos. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 23:20 24 mar 2018 (UTC)

Eso suena a falacia, Penquista. El resultado es favorable, más no lo suficientemente favorable. Y sí, debería hacerse otra encuesta, en un tiempo. 🙝 Miguu ¡Parlamenta! 23:37 24 mar 2018 (UTC)

A ver, dicen "en la primera encuesta la mayoría estaba a favor de ambos permisos". Yo veo que en la primera encuesta la aprobación alcanzó apenas el mínimo necesario para ser aprobados (66.67 % el de bloquear y 68.88 % el de proteger). ¿O me equivoco? Ni siquiera hablamos de un 75%, mucho menos un 80, 90 o más. Por otra parte, una nueva encuesta sobre un tema ya encuestado dos veces puede considerarse un abuso del sistema. Ver por ejemplo el caso de las encuestas/votaciones sobre colores e iconos en las fichas. --Saludos. Ganímedes 12:56 25 mar 2018 (UTC)

La excesiva consulta repetida sobre un mismo tema en poco tiempo también podría en mi opinión llevar a un hastío de los usuarios. Llegado el punto, nadie (o muy pocos) estarán interesados en ir a votar sobre lo que ya se han expresado. Eso podría explicar, por ejemplo, que en la primera encuesta participaran 51 usuarios (34+17 en el primer permiso, por ejemplo) y en la segunda encuesta, para el mismo permiso apenas se alcanzaran 32 votos (14+18), menos incluso que los que participaron por el "si" en la primera votación. --Saludos. Ganímedes 14:06 25 mar 2018 (UTC)

Creo que nos estamos desviando del tema con si la propuesta tiene apoyo o no lo tiene. Las encuestas no sirven para determinar si la comunidad va a aprobar o no estos permisos en una votación formal, ya que en una votación formal vota distinta gente. Las encuestas para lo que sirven es para obtener la opinión que tiene la comunidad sobre una propuesta, y así que haya más opciones de afinar esa propuesta para que consiga mayor apoyo en una votación formal. En este caso, visto los resultados de ambas encuestas, puede concluirse tanto que hay una mayoría favorable a estos permisos, como que con la opciones propuestas la mayoría está en contra. Pero lo que a mi me preocupa no es saber si la propuesta resultaría aprobada o no en una votación formal, sino saber porque hay esa diferencia de apoyo a la propuesta entre una encuesta y otra, o si se quiere, porque muchos de los que eran favorables en la primera encuesta, se han abstenido en la segunda. ¿Es porque los permisos no se pueden limitar del todo técnicamente? Pues entonces podemos olvidarnos de la propuesta porque con el software actual de Wikimedia no se puede hacer una limitación mayor. ¿Es porque las propuestas sobre estos permisos que se han hecho en la segunda encuesta no han gustado? Pues entonces si que se puede hacer cambios en la propuesta para buscar un mayor apoyo. El tema conocer porque esa diferencia de apoyo. No sirve de nada sacar una tercera encuesta o una votación formal si no sabemos porque ha perdido apoyo, ya que no se trata de que en una encuesta salga que sí, sino de buscar aquella propuesta que tenga mayor consenso o apoyo. --Tximitx (discusión) 17:14 25 mar 2018 (UTC)

Pues yo te he dado una explicación factible: la gente se aburre si le preguntas lo mismo una y otra vez, más si es en un breve plazo. De todas formas no creo que haya una forma de saberlo, a menos que les preguntes a los que no votaron la segunda encuesta pero si la primera, a los que se inclinaron por el "no" luego de votar por si, o a ambos... --Saludos. Ganímedes 17:21 25 mar 2018 (UTC)

No creo que preguntar lo mismo haya sido el problema, porque en ese caso se hubieran aburrido tanto los que votaron que sí como los que votaron que no. Eso no es lo que ha ocurrido en este caso. En cuanto a lo de preguntar a quienes cambiaron su voto, supongo que habrá varios de ellos que lean el Café, así que supongo que alguno habrá que pueda dar sus razones. Otra cosa es que quieran explicar sus razones o, como indicas, solo sea que se han aburrido de encuestas. --Tximitx (discusión) 18:32 25 mar 2018 (UTC)

Desconozco las razones de otros. Yo no participé a pesar de ver la encuesta en la página de la comunidad. Mi razón es que, al contrario que mucha gente, a la que le fascina opinar de todo, votar, estampar nombres y hacer oír su voz siempre que tengan la posibilidad, no soy muy fan de eso e intento dosificarme. Influyen el que el voto no sea secreto, que la importancia del proceso sea minúscula (el valor de una encuesta para wikipedia es, en la práctica, nulo) y no haya tenido ganas de leerme el tocho y estudiarlo un poco, además de una progresiva desesperanza general con la utilidad de los procesos comunitariodemocráticos acá.

En mi caso habría habido, en la práctica, más probabilidades de participar si 1) se tratara de una votación 2) fuera al grano, con una o dos preguntas elementales, que implica un trabajo previo de los promotores para separar el grano de la paja y presentar una propuesta viable y orgánica, en lugar de cargarle dicha labor a los votadores ("las masas son estúpidas"). El planteamiento de algunas votaciones/encuestas a veces pareciera análogo a pretender aprobar/redactar una constitución artículo a artículo vía referéndum: "el 153 sí/no, el 154 sí/no, el 155 tampoco", el "en el 8: sí/no a la integridad territorial, sí/no al ordenamiento constitucional" etc).

El asambleísmo y la democracia participativa tienen sus límites, incluso en Wikipedia. strakhov (discusión) 11:29 27 mar 2018 (UTC)

Comentario

Esta serie de encuestas, por las que se pretende "trocear" los permisos asociados a los bibliotecarios para otorgarlos por partes a usuarios para cuya entrega pudiera no haberse hecho un procedimiento de tipo CAB, me hace acuerdo al caso sucedido en la Wikipedia en hindi si mi memoria no me falla, por la que en un consenso comunitario misterioso y mal uso de atribuciones por parte de un administrador, se "troceó" tanto los permisos de los sysop que habían protectores, bloqueadores, eliminadores de páginas, etc. (innumerables grupos de usuario que irónicamente los empleados de la WMF en phabricator aceptaron sin hacer preguntas), y el sysop que orquestó eso otorgó a muchos usuarios varios o todos esos grupos de usuarios a la vez, lo que les permitió ser de hecho sysop sin siquiera haber sido electos por el procedimiento estándar. Además ese administrador creó un filtro antiabusos que prevenía que otros administradores o burócratas pudieran hacer cambios de permisos si no me equivoco, pero esa es otra historia.

En resumen, debe evitarse crear bibliotecarios de hecho que evitan el procedimiento CAB, y ganan de a poco el "bibliotecariado de hecho" capturando permisos uno a uno. --Zrbt (discusión) 16:49 28 mar 2018 (UTC)

Para que puedan comprobar que no estoy delirando, puede verse en meta que existió el caso al que hice referencia: meta:Requests for comment/Userrights on Hindi Wikipedia --Zrbt (discusión) 16:52 28 mar 2018 (UTC)

Para empezar, crear nuevos permisos no es "trocear" los permisos de los bibliotecarios, que seguirán teniendo todos sus permisos completos. Para continuar, la propuesta que se ha hecho aquí no es la de condecer todos esos permisos separados, sino solo unos permisos concretos con un uso limitado claro y buscando el consenso preguntando a la comunidad. Creo que la situación no es nada comparable a lo ocurrido en la Wikipedia Hindi, donde además el abuso solo fue realizado por un único usuario. Se podrá estar en desacuerdo con la propuesta, pero haciendo exageraciones comparando está propuesta con el caso ocurrido en la Wikipedia Hindi, solo se muestra una falta de respeto a esta comunidad, puesto que ni la propuesta ni como se está llevando la misma aquí es en absoluto comparable con el caso de la Wikipedia Hindi. --Tximitx (discusión) 19:06 28 mar 2018 (UTC)

Pues no es el primero que lo piensa. Creo que el caso de Hi:WP que menciona Zrbt no se debe al abuso específico de Mayur, sino a la existencia de "subbibliotecarios", ya que existían tantos permisos fraccionados que de hecho habían usuarios que tenían 80% de los permisos de administradores y burócratas, sin haber sido electos por la comunidad mediante el proceso legítimo. Y creo que es eso lo que preocupa en el fondo a muchos usuarios de esta Wiki, lo que no sabremos a ciencia cierta a menos que se manifiesten. --Saludos. Ganímedes 20:40 28 mar 2018 (UTC)

PD: en todo caso, si te has sentido ofendido has sido tu, dado que no creo que sea una falta de respeto "a esta comunidad", ya que la mayoría ni se ha manifestado. --Saludos. Ganímedes 20:41 28 mar 2018 (UTC)

En la Wikipedia Hindi los abusos si se debieron mayoritariamente al usuario Mayur, puesto que fue este usuario el que dio los distintos permisos de manera masiva a personas acordes a sus intereses incluso ocultando ediciones y registros para evitar ser detectado. Es como si aquí un bibliotecario se pusiera a dar permisos de forma masiva a otros usuarios afines sin además respetar las más mínimas reglas control, borrando registros y ocultando ediciones, y además quitando permisos y bloqueando a otros bibliotecarios para que no pudieran pararle. Evidentemente el mal uso hecho por los otros usuarios con esos permisos no se debe Mayur, pero este sí fue el responsable de dar esos permisos sin control además de retirar los permisos a otros usuarios y entorpecer el control y los registros de uso de esos permisos. Sin la inestimable colaboración de Mayur, los abusos no hubieran llegado al nivel que llegaron, por lo que sin duda fue el máximo responsable, como así fue demostrado en meta. Por otra parte, aquí no se ha propuesto dar el 80% de los permisos de los bibliotecarios, sino solo unos muy concretos y con unas limitaciones de uso también muy concretas. Como he dicho antes, se podrá estar en contra, pero desde luego no es nada comparable a la situación que se dio en Hi:WP.

En cuanto a la ofensa, por supuesto que es una falta de respeto a esta comunidad comparar la propuesta de esta comunidad, limitada y debatida por la comunidad, con el acto de vandalismo ocurrido en Hi:WP. Puede que no todos se sientan ofendidos, pero yo no he hablado de ofensa, sino de falta de respeto, puesto que comparar esta propuesta con un acto de vandalismo cuando además ni si quiera la propuesta es comparable a lo que se aprobó en Hi:WP, es intentar desprestigiar una propuesta seria con hechos que nada tienen que ver con ella. Supongo que la intención de Zerabat no era ofender y tan solo pretendía mostrar su punto de vista contrario a la propuesta, pero creo que podía defender la misma postura y usar los mismos argumentos sin traer a colación unos hechos que él mismo ha declarado que se produjeron con un consenso comunitario misterioso y mal uso de atribuciones por parte de un administrador. No creo que sea el caso de lo que está ocurriendo aquí para compararlos. --Tximitx (discusión) 23:39 28 mar 2018 (UTC)

También se había armado un sistema en el cual los usuarios iban adquiriendo progresivamente permisos, de forma que había una suerte de carrera escalonada. Acceder a tal y cual te daba la oportunidad de aspirar al siguiente escalón, lo que terminaba en una pirámide jerárquica en cuya cima estaba el mentado usuario. Si, es cierto, es un caso particular de una wiki con pocos usuarios, pocos artículos, pocos bibliotecarios activos... Pero también el abuso se vio facilitado porque la gran mayoría de los usuarios desconocían qué eran o cómo operar los filtros, desconocían el funcionamiento de los bots, de los scripts, o eran apáticos y no participaban en las discusiones. Muchas veces discutían 5 o 6 y con ellos se lograba un "consenso". ¿Crees que estamos muy lejos de eso? Tenemos regulaciones y políticas que ellos no, ciertamente. Pero muchos no saben cuáles ni para qué sirven los filtros (muchos privados), con suerte tenemos una veintena de bibliotecarios realmente activos, los operadores de bots se cuentan con los dedos de una mano, e incluso como en el caso más reciente, no es posible acceder al código de un bot para arreglarlo incluso cuando se ha declarado que se garantiza la ejecución y el acceso al código en caso de emergencia o de ausencia desde Toolforge o la máquina virtual bastion (sic) del servidor de Wikimedia España. Y si no, que se lo digan a Superzerocool (que desconozco si se ha enterado o no de la parada del bot). Sin dudas que se tomarán medidas para entregar estos nuevos permisos a determinados usuarios, en determinadas circunstancias y con medidas de seguridad. Pero no quita la idea de que algunos (erróneamente) lo puedan ver como una carrera en la que el premio final es obtener el permiso de bibliotecario. Y ni tanto, porque en Hi:WP no había bibliotecarios porque en su mayoría tenían lo que necesitaban: se arreglaban con el permiso de borrar. Si además tenemos un permiso para bloquear en X condiciones y otro para ... entonces ciertamente ya no serán necesarios los bibliotecarios. Y es el esquema piramidal lo que creo que resulta espinoso aquí. Por otra parte, está la insistencia y la persistencia en pronunciarse una y otra vez sobre cuestiones ya resueltas. Pero ese es otro tema. Por lo demás, como parte de esta comunidad, no creo que se me haya faltado el respeto, así que agradezco que no hables por todos. --Saludos. Ganímedes 00:22 29 mar 2018 (UTC)

Yo tampoco me sentí ofendido, ni irrespetado, por el comentario. Saludos. strakhov (discusión) 00:22 29 mar 2018 (UTC)

┌─────────────────────────────┘
Yo no veo conexión directa alguna con tener una herramienta para trabajar y la extinción de los bibliotecarios. Me parece que pretender que quien ha demostrado que lleva el tiempo suficiente haciendo una tarea que requiere una herramienta y no se le pueda entregar bajo la premisa de que otro desaparecerá, lo cual es solo una especulación sin fundamento, es simplemente hacer que ese trabajador se harte y deje de colaborar también. Como si fuera poco venir a colaborar aquí por amor al arte, además sin herramientas, cuando está más que visto y probado que muchos de los que han llegado a bibliotecarios se han ido marchando por su propia cuenta, igualmente. Es decir, no hay garantía de que quien es bibliotecario no vaya a dejar de colaborar, pero sí llevamos años asegurandonos de que la gente colabore sin herramientas. 82.102.22.5 (discusión) 04:41 29 mar 2018 (UTC)

Yo tampoco veo relación entre tu comentario y el mío. ¿Quién ha dicho que sería la extinción de los bibliotecarios? Tampoco veo que haya voluntad por tener bibliotecarios devaluados. Yo en particular no le asignaría el permiso de borrar a ningún usuario que no haya pasado por una elección comunitaria, y menos el de bloquear. Los otros permisos de los bibliotecarios, son triviales frente a estos. Herramientas para luchar contra el vandalismo se han solicitado pero se han perdido más de las que se han conseguido (básicamente porque el software ha crecido más allá de su programación y han quedado obsoletos), pero no creo que asignar un permiso como el de hacer traslados sin dejar redirecciones, que además tiene un limitadísimo campo de aplicación, sea una ayuda enorme para el mantenimiento. Lo que hay que hacer es lo más resistido: que la edición es libre, pero cuando uno adquiere una responsabilidad mayor como los botones de bibliotecarios, se debe demostrar el mismo compromiso que cuando no se tenía y se trabajaba para conseguirlo. Y para eso, no parece haber nada de apoyo. --Saludos. Ganímedes 13:25 29 mar 2018 (UTC)

Mi comentario tiene relación con el tuyo respecto a que dijiste: "entonces ciertamente ya no serán necesarios los bibliotecarios.. Además, el hilo no habla del permiso de hacer traslados, sino de trocear todos los permisos, por tanto, estás certificando un hecho que no puedes asegurar con certeza, ¿especulando? siendo que en la wiki en portugués, al parecer, según comentaron el otro día, ya llevan seis años usando el permiso de bloquear a vándalos, y se ve que solo han tenido un incidente, lo cual tira completamente por tierra toda la argumentación de aquellos que decían que los permisos eran indivisibles. ¿por qué eran indivisibles, ahora que sabemos que sí lo son, porque no era posible la división o porque les rebajaba el status a ellos? Saludos. 185.189.112.126 (discusión) 14:01 29 mar 2018 (UTC)

Pues si sacas el comentario de contexto, ciertamente puedes interpretar lo que quieras, usuario registrado que se hace pasar por anónimo. --Saludos. Ganímedes 20:58 29 mar 2018 (UTC)