stringtranslate.com

Wikipedia:Encuesta sobre formato de fecha y enlaces

  • WP:ENCUESTA DE FECHA

La siguiente discusión está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.


Esta encuesta trata sobre cuestiones relacionadas con la vinculación o desvinculación de fechas y el uso de formato automático (software que cambia automáticamente el formato de fecha que se muestra según las preferencias establecidas por los editores que hayan iniciado sesión). La encuesta se desarrolla desde las 00:00 horas del 30 de marzo de 2009 (UTC) y finaliza a las 23:59 horas del 13 de abril de 2009 (UTC).

La historia de la disputa

Después de un largo debate en la charla MOSNUM y en otros lugares, una encuesta y un debate posterior en agosto de 2008 llevaron a la desaprobación (es decir, la interrupción) de la vinculación de fechas con fines de formato automático. Varios editores avanzaron entonces con una desvinculación manual, automatizada y semiautomatizada a gran escala de las fechas. Sin embargo, varios editores indicaron su oposición a este cambio, en WT:MOSNUM y en las páginas de discusión de los editores que estaban desvinculando las fechas. La discusión continuó en WT:MOSNUM sobre si suficientes editores habían proporcionado previamente información sobre el tema para representar con precisión el consenso de la comunidad. Hacia fines de noviembre, se lanzaron dos RFC paralelas sobre la vinculación/desvinculación de fechas y el formato automático, que recibieron la información de cientos de editores:

Aunque estas RFC ofrecían orientación sobre varios puntos, no hay acuerdo en cuanto a si esa orientación ha resuelto todos los aspectos del debate. También se ha afirmado que la redacción y la estructura de las preguntas son intrínsecamente sesgadas. Esta RFC pretende aclarar (i) si se desea una forma de formato automático de fechas y (ii) si se debe utilizar la vinculación de fragmentos de fechas y, en caso afirmativo, en qué condiciones.

La encuesta comenzará el 30 de marzo de 2009 y durará dos semanas. Se anima a los usuarios a que revisen las propuestas y voten en las tres secciones: formato automático, vinculación mes-día y vinculación año. Una vez finalizada la encuesta, habrá un período de dos semanas para debatir. Se considerará la posibilidad de realizar una segunda encuesta a finales de abril (si es necesario) para ver cómo se implementarán los resultados de la primera. Aunque los comentarios de los partidos individuales son sumamente bienvenidos, cualquier discusión en cadena se trasladará a la página de discusión.

Autoformato

Declaración de antecedentes

¿La comunidad de Wikipedia apoya el concepto de formato automático de fechas?

El formato automático de alcance es una forma de marcar fechas para permitir que los usuarios registrados elijan su formato de visualización preferido. Se han propuesto diversos métodos para implementar esto. La pregunta que se plantea aquí es si la comunidad desea los elementos básicos y comunes del formato automático.

¿Qué es un formato de fecha? Los angloparlantes utilizan dos formatos de fecha principales: 11 de marzo de 2009 (MDY, principalmente en Norteamérica) y 11 de marzo de 2009 (DMY, principalmente en otros lugares). Otros formatos de fecha se utilizan con menos frecuencia en texto continuo, pero se utilizan con frecuencia como parámetros de entrada para plantillas: 2009-03-11 (YMD, un formato de estilo ISO ).

¿Qué es el formato automático de fechas? Es un sistema que permite que las fechas que se muestran en los artículos cambien automáticamente para reflejar la configuración de un usuario registrado en " Especial:Preferencias/Fecha y hora "; los usuarios no registrados (IP) no pueden acceder a la configuración de preferencias. El sistema de formato automático existente (Fechas dinámicas, descrito aquí), introducido en 2003, requiere el uso de la sintaxis de enlace de doble corchete para identificar las fechas para el formato automático.

Una actualización reciente del software de Wikipedia permite que las fechas se formatee automáticamente mediante el uso de una función ({{#formatdate}}) en lugar de con el marcado basado en enlaces ([[30 de marzo]] [[2009]]). Esta función muestra fechas de texto sin formato con formato automático según las preferencias de un usuario registrado, sin enlaces (" 30 de marzo de 2009 "). Añade la opción de definir un formato de fecha predeterminado para usuarios no registrados y para cualquiera que no haya establecido una preferencia. Al igual que con el sistema original, todas las fechas de un artículo requerirían marcado para garantizar la coherencia.

¿Qué sucede si se acepta el formato automático? Se buscará un consenso sobre las especificaciones, que luego utilizarán los desarrolladores y editores para establecer un sistema basado en una versión modificada del software existente o en un nuevo esquema de marcado o plantilla; las fechas se marcarán en consecuencia.

¿Qué ocurre si se rechaza el formato automático? Se seguirá eliminando el marcado utilizado por el sistema anterior y se corregirán las fechas que no sean coherentes con el formato general del artículo, ya sea de forma manual o automática.

Declaración para

El formato automático de fechas tiene como objetivo ofrecer a los usuarios más opciones . Permite a los usuarios ejercer un control personal sobre la forma en que se presentan las fechas. Este no es un concepto nuevo; el sistema existente de Wikipedia se utiliza desde 2003, y los formatos de fecha personalizados han sido una opción en los sistemas operativos durante décadas. Es una extensión natural de la tendencia hacia una mayor elección por parte de los usuarios en la forma en que interactuamos con nuestros ordenadores, iPods, teléfonos móviles y cualquier otro tipo de tecnología personal.

Más allá de ese objetivo, el formato automático mejora nuestra capacidad de presentar un formato de fecha coherente . En la actualidad, el Manual de estilo permite que las fechas se formatee en estilo DMY o MDY, según el uso regional y el consenso editorial. La ausencia de un formato estándar crea situaciones en las que las páginas son coherentes individualmente , pero estilísticamente dispares cuando se las considera como una colección de artículos. Esto difiere de otras enciclopedias, que emplean un formato coherente en toda la publicación.

Se ha hablado mucho de la supuesta complejidad del autoformato, pero la realidad es que los editores de Wikipedia llevan utilizando el marcado de fechas desde hace casi seis años . Sí, las fechas requieren un formato especial para habilitar la función, pero esto no es diferente de lo que se requiere para prácticamente todas las opciones de visualización en Wikipedia. El marcado nos permite mejorar la presentación de los artículos, desde las opciones más básicas, como el texto en negrita y cursiva o los encabezados de sección, hasta funciones más complejas, como plantillas y tablas. Cualquier cambio a gran escala se puede automatizar mediante el uso de las herramientas de edición existentes. En cuanto al impacto en los editores novatos, Wikipedia nunca ha esperado que dominen todos los aspectos de la interfaz. De hecho, siempre se ha animado a los nuevos usuarios a contribuir sin preocuparse por la ortografía, la gramática o las opciones de formato.

Actualmente, los debates en curso entre los editores y los desarrolladores de Wikipedia se centran en las formas de resolver las preocupaciones expresadas sobre el sistema existente, entre las que se encuentran principalmente los enlaces y lo que ven los usuarios no registrados. Estas cuestiones se están abordando mediante el desarrollo activo de un sistema mejorado, cuyos elementos ya se han incorporado al software del sistema. Otras opciones que se están considerando añadirían mejoras que mejorarían el control sobre los estándares de todo el sitio, permitiendo al mismo tiempo que se etiqueten artículos individuales con formatos de fecha predeterminados específicos de la página cuando se desee. De cara al futuro, el marcado de fechas también se ha identificado como fundamental para el desarrollo de nuevas características , como líneas de tiempo automatizadas, páginas automatizadas de "este día en la historia" y la mejora de la eficiencia con volcados de bases de datos. El formato automático también reemplazaría la necesidad actual de parámetros de "formato de fecha" en las plantillas.

Los beneficios son evidentes tanto para los lectores como para los editores . El formato automático de fechas permite una mayor coherencia en la presentación de nuestros artículos a todos los lectores, ayuda a los editores a presentar un aspecto uniforme y profesional, y ofrece a los usuarios registrados la opción de personalizar su interfaz. En resumen, este debate trata sobre cómo ofrecer más opciones a todos los usuarios de Wikipedia.

Declaración en contra

No hay ningún problema que resolver. Es trivial que el día o el mes aparezcan primero (3 de enero; 3 de enero): todos los angloparlantes reconocen ambos; el ejército de los EE. UU. usa DMY, al igual que muchos canadienses; en cambio, muchas publicaciones fuera de Norteamérica, incluidos los periódicos, usan MDY. Dado este entorno mixto, es poco probable que los lectores se den cuenta, y mucho menos les importe, qué formato se usa en un artículo. Los artículos destacados , que representan nuestros estándares máximos de profesionalismo, abandonaron el formato automático en septiembre pasado y ahora usan exclusivamente fechas simples de texto fijo; esto apenas ha recibido una mención en los candidatos a artículos destacados . En términos más generales, un usuario ha desvinculado y corregido fechas en más de 7000 artículos, pero ha recibido solo un puñado de objeciones.
Principio fundamental de que no debería haber dos clases de usuarios. Debido a que algunos editores registrados verían formatos de fecha diferentes a los de todos los demás (ver Wikipedia:DONOTLINKDATES ), esto conduciría inevitablemente a un lío inconsistente de formatos de fecha.
Complejo y laborioso. Etiquetar decenas de millones de fechas con un marcador como (el doble de pulsaciones de teclas, incluso más si se añade), y especialmente etiquetar casi tres millones de artículos para establecer un formato de fecha predeterminado, sería un precio enorme a pagar por el beneficio muy pequeño de ver las fechas en un formato específico, y complicaría las cosas para los editores nuevos y ocasionales. MOSNUM ya tiene reglas simples y bien aceptadas para el formato de fechas, que no requieren marcado. En el contexto de intentar lograr una solución simple, el Director Técnico de WikiMedia, Brion Vibber, ha declarado: "Mi recomendación personal sería eliminar todo el formato automático de fechas...". Falacia de metadatos. El marcado es innecesario para producir metadatos. Ya tenemos herramientas de búsqueda poderosas, incluyendo la búsqueda de Google restringida por Wikipedia, muy poco utilizada (site:en.wikipedia.org), y búsquedas por categorías. Para que el marcado sea útil, se necesitaría una opción que permita a los editores ver todas las fechas marcadas como si estuvieran vinculadas, otra capa de complejidad; Lo que enlaza aquí con una página de fecha o año produce una lista de miles de artículos cuyo único factor común es que algún evento, relacionado de alguna manera con el tema, ocurrió en esa fecha o año; esos metadatos de baja calidad son prácticamente inútiles para los editores de futuros proyectos basados ​​en el tiempo. Riesgos de desarrollo. El fracaso del formato automático original se debió en gran medida a la creación de metadatos ad hoc.{{#formatdate|March 11, 2009}}|dmy/md

Imposición de un diseño por parte de programadores que actúan sin especificaciones acordadas (objetivos claros) por la comunidad. Las llamadas correcciones sugeridas tienen un alcance y una funcionalidad limitados, y no han sido acordadas por la comunidad. No deberíamos arriesgarnos a permitir que se añadan soluciones poco a poco durante los próximos años, lo que requiere una sintaxis cada vez más complicada, aún más alejada del editor promedio. Entre estos problemas estarían los espacios indivisibles, AD/BC , las barras , las fechas ISO y gregorianas / julianas . Los rangos de fechas (evitando la torpeza y las repeticiones forzadas que implicaba el sistema original) serían un desafío significativo.


Respuestas de formato automático

Indique su voto en UNA opción, acompañado de una breve explicación de su elección. Su explicación es importante para determinar el consenso de la comunidad.
Apoyo el concepto general de formato automático.
  1. Soporte . Aunque no me importa mucho que el usuario tenga una preferencia para convertir todas las fechas en un solo formato, algo como {{#formatdate}} combinado con una palabra mágica {{DEFAULTDATEFORMAT}} para establecer el valor predeterminado para toda la página es necesario para evitar forzar a todas las plantillas de manejo de fechas a tener un parámetro "dateformat" en cada uso o forzar a todas las plantillas de manejo de fechas a permitir cualquier basura arbitraria en sus parámetros "date" y renunciar a cualquier posibilidad de manipulación de fechas. Tampoco veo ningún sentido en no permitir que aquellos que quieren la función la tengan, y francamente los "argumentos en contra" anteriores apestan a FUD y falacia lógica sin sustancia real. Anomie ⚔ 23:14, 29 de marzo de 2009 (UTC) [ responder ]
  2. Apoyo . Me parece mucho más agradable y fácil como lector tener las fechas formateadas automáticamente en un solo estilo. Me parece que cambiar de formato es mucho más molesto que usar variantes ortográficas como -or v. -our o -ize v. ise. Eluchil404 ( discusión ) 00:01 30 mar 2009 (UTC) [ responder ]
  3. Apoyo . Lo apoyo parcialmente por Anomie, pero también porque marcar fechas con metadatos nos permite hacer cosas interesantes que no podríamos hacer de otra manera. Muchos de los argumentos en contra del formato automático en realidad están en contra de la vinculación de fechas. dm ( discusión ) 00:02, 30 de marzo de 2009 (UTC) [ responder ]
  4. Soporte . Establecí mi preferencia de fecha para que se muestren las fechas en formato de EE. UU., por lo que espero que las fechas se muestren como tal. Además, el formato automático ayuda a evitar conflictos de edición. -Jeff (discusión) 00:04, 30 de marzo de 2009 (UTC) [ responder ]
  5. Apoyo lo anterior. Prefiero el formato estadounidense en todo momento. A diferencia de otras diferencias culturales (como la ortografía del Reino Unido frente a la de los EE. UU.), esto es algo que se puede implementar fácilmente, ya que así es como se ha hecho. El mes pasado, estuve parcialmente involucrado en una disputa bastante tonta sobre si usar un formato u otro. Creo que dejó a algunas personas sin ganas de contribuir más. Eso es totalmente innecesario en mi opinión. --♬♩ Hurricanehink ( discusión ) 00:51, 30 de marzo de 2009 (UTC) [ responder ]
  6. Soporte . Estoy de acuerdo con Anomie, creo que gran parte del problema se solucionaría simplemente configurando un valor predeterminado diferente (actualmente el valor predeterminado es no formatear todo, lo que genera inconsistencias) que verían los anónimos y los nuevos usuarios. Creo que sería un simple cambio de configuración. Sr. Z- man 00:59, 30 de marzo de 2009 (UTC) [ responder ]
  7. El soporte para autoformateo podría ser útil al mover citas con plantillas de un artículo a otro: se podría copiar o compartir la cita sin tener que cambiar sus formatos de fecha. Parece menos útil en el texto principal, pero para las citas parece que vale la pena tenerlo. Eubulides ( discusión ) 01:27 30 mar 2009 (UTC) [ responder ]
  8. Admite formato automático sin enlaces automáticos (esto anula la mayoría de los votos de "en contra"). Facilita el mantenimiento de un formato de fecha coherente dentro de un artículo y puede facilitar la recopilación de metadatos. — Arthur Rubin (discusión) 02:05 30 mar 2009 (UTC) [ responder ]
  9. Soporte : no me importa demasiado, pero la dolorosa experiencia me dice que nos inundarán las quejas si no hacemos esto. Sin embargo, cualquier solución de formato automático no debería dar como resultado enlaces automáticos, debería permitir los enlaces intencionales, debería permitir que los lectores ocasionales establezcan una preferencia de visualización (esto no significa Special:Preferences especialmente, solo una forma de establecer una cookie), y debería permitir la configuración por página de valores predeterminados "correctos" (por tema/ubicación) para la visualización de la fecha. Si no hacemos todo esto, simplemente volveremos a toda la fea pelea de nuevo. Gavia immer ( discusión ) 02:46, 30 de marzo de 2009 (UTC) [ responder ]
  10. Soporte, según Anomie y Gavia immer.- gadfium 03:20, 30 de marzo de 2009 (UTC) [ respuesta ]
  11. El soporte , no necesariamente con enlaces automáticos, aunque es posible un manejo adecuado de los metadatos sin esto, facilita el proceso. El paso a artículos formateados con datos reutilizables es un desarrollo necesario en general. Dada la cantidad de wikignomos y el ingenio de los programadores de bots, no debería haber grandes dificultades para implementarlo. DGG ( discusión ) 03:31 30 mar 2009 (UTC) [ responder ]
  12. Soporte , especialmente dado que los desarrolladores ya han agregado la capacidad de autoformateo sin enlaces al sistema. Muchas de las otras preocupaciones expresadas contra DA pueden ser fácilmente abordadas; por ejemplo, la expresión "#formatedate" puede ser fácilmente invocada a través del uso de una plantilla con un nombre mucho más corto, como "{{D}}". También es un medio para presentar un aspecto más profesional, en oposición a la mezcla de formatos que ofrecemos ahora. (La directriz de formato de fecha múltiple está en desacuerdo con la mayoría de las otras publicaciones profesionales, que eligen uno u otro; cuando se ven como una colección, nuestros artículos parecen inconsistentes. ¿Cuándo fue la última vez que vio a Britannica o al Times usar una mezcla de DMY y MDY?) -- Ckatz chat spy 04:33, 30 de marzo de 2009 (UTC) [ responder ]
  13. Apoyo , según Eluchil404. También apoyaría un formato automático de regionalización ortográfica. AKAF ( discusión ) 06:58, 30 de marzo de 2009 (UTC) [ responder ]
  14. Soporte . Antes de que se introdujera el formato automático, había largas filas sobre cómo formatear las fechas. Parece que esto ha vuelto a ocurrir recientemente, justo cuando algunos comenzaron a desvincular las fechas. -- Usuario:Docu
  15. Apoyo . El formato automático tiene sentido para el lector. Sin embargo, probablemente hubiera votado en contra si la opción sin enlaces no estuviera disponible. YLee ( discusión ) 09:17 30 mar 2009 (UTC) [ responder ]
  16. Soporte . Por favor, déjenlo como está (o como estaba). Esto, aquello y lo otro [ discusión ] 09:31, 30 de marzo de 2009 (UTC) [ responder ]
  17. Apoyo . En el entendido de que la función de formato automático evita debates y posibles conflictos sobre el formato de fecha. -- Born2flie ( discusión ) 09:36, 30 de marzo de 2009 (UTC) [ responder ]
  18. Apoyo Las posibilidades de los metadatos de las fechas. Alegría. No habrá ninguna obligación de utilizar fechas de formato especial, además, lo que los robots deshicieron, seguramente lo podrán rehacer. Los argumentos espurios no sirven. -- billinghurst ( discusión ) 10:23, 30 de marzo de 2009 (UTC) [ responder ]
  19. A pesar de todas las razones expuestas en el apartado de ventajas, esto es demasiado simple como para ser considerado "complicado", como los opositores quieren hacernos creer. —Locke Cole • t • c 10:53, 30 de marzo de 2009 (UTC) [ responder ]
  20. Soporte . El uso de esta función no supone una carga para los editores (la uso todo el tiempo para las fechas que agrego) y es una forma práctica de resolver la perpetua disputa entre el formato de fecha de EE. UU. y el del Reino Unido. Me opongo firmemente a las campañas de desvinculación unilaterales de los bots y otros editores. -- DAJF ( discusión ) 11:44, 30 de marzo de 2009 (UTC) [ responder ]
  21. Soporte . El entorno puede ser mixto, pero Wikipedia es un proyecto unificado. Puedo vivir leyendo formatos de fechas que no coinciden, incluso si se trata del mismo artículo, pero sería mejor si toda Wikipedia se adhiriera a un estándar. æron phone home 12:42, 30 de marzo de 2009 (UTC) [ responder ]   
  22. Soporte . El formato de las fechas es un tema menor, pero es muy importante tener un formato estándar en todo el proyecto. -- Unionhawk ( discusión ) 12:58, 30 de marzo de 2009 (UTC) [ responder ]
  23. Apoyo . Por DAF. Yo fui uno de los usuarios que se opuso a las "campañas de desvinculación unilateral por parte de bots y otros editores", y fui tratado con bastante rudeza por la otra parte, con extrañas acusaciones de "elitismo", entre otras cosas. Parece haber algunas razones arraigadas contra el formato automático que no tienen nada que ver con el formato automático en sí. Me alegra ver finalmente una encuesta a nivel de todo el proyecto sobre esto, aunque no entiendo por qué no se hizo esto primero . También apoyo las medidas para garantizar que las fechas se muestren de manera consistente a los usuarios no registrados. - BillCJ ( discusión ) 13:03, 30 de marzo de 2009 (UTC) [ responder ]
  24. Soporte . El formato general de todas las fechas proporciona una salida consistente para todos los artículos. Las mejoras propuestas en el software para permitir o no que se vincule la fecha cuando se aplica formato automático lo convierten en una solución aún más atractiva para que las personas no tengan que preocuparse por lo que realmente hay en el texto del artículo, sino que lo vean como quieren. Keith D ( discusión ) 13:26 30 mar 2009 (UTC) [ responder ]
  25. Apoyo : en mi opinión, el beneficio obtenido de la coherencia entre los artículos supera los problemas potenciales. Camw ( discusión ) 13:36 30 mar 2009 (UTC) [ responder ]
  26. Soporte - Al final, es mucho más fácil leer las fechas cuando se presentan de forma coherente en todos los artículos. Esto evitará que la gente edite artículos para cambiar la fecha según sus preferencias personales, algo que veo a menudo. Lo más importante es que Wikipedia tiene como objetivo proporcionar artículos para el lector, no proporcionar un pasatiempo para los editores, ya que esos argumentos sobre pulsaciones de teclas adicionales y razones técnicas son un poco irrelevantes. Martin 4 5 1 ( discusión ) 14:02, 30 de marzo de 2009 (UTC) [ responder ]
  27. Soporte , aunque sea para aplicar fácilmente un formato de fecha consistente en una página (yo no tengo preferencias de fecha configuradas). Si la función de formato tiene una sintaxis más corta como {{#date:...}} será fácil de usar, fácil de entender, hará que sea más fácil incluir plantillas con fechas en ellas y sólo una persona tendrá que preocuparse una vez por el formato de fecha adecuado en un artículo determinado en lugar de que cada editor agregue una fecha. -- Amalthea 14:17, 30 de marzo de 2009 (UTC) [ responder ]
  28. Apoyo . Soy un usuario de esto (fechas ISO para mí, por favor) y lo extrañaré si desaparece. La declaración en contra no me hace pensar lo contrario. — the Sidhekin ( discusión ) 14:51 30 mar 2009 (UTC) [ responder ]
  29. El soporte para el formato automático de fechas puede proporcionar una apariencia uniforme en todos los artículos para los usuarios con preferencias o con una opción predeterminada. Esta característica ya existía y se utilizaba, aunque lamentablemente estaba vinculada a la vinculación de fechas anteriormente. Las preocupaciones tecnológicas se pueden superar una vez que se acuerde su uso como característica y la comunidad decida el comportamiento y el marcado exactos. Además, la característica facilita el uso de plantillas de citas. — Ost ( discusión ) 14:56, 30 de marzo de 2009 (UTC) [ responder ]
  30. Quiero que la fecha y la hora se muestren como a mí me gusta. -- Morten ( discusión ) 14:59 30 mar 2009 (UTC) [ responder ]
  31. SoporteBellhalla ( discusión ) 15:05 30 mar 2009 (UTC) [ responder ]
  32. Apoyo - Apoyo por varias razones. 1) Para los usuarios que no ven las fechas de la misma manera 2) Porque ahorra códigos extraños (no muchos, pero pueden acumularse, créanme). Además, cuando se eliminó el formato automático, nos quedamos con fechas en los artículos que se veían así (2007-02-03 o 2007-30-11). Creo que fue una mala planificación cuando se eliminó por primera vez.  BIGNOLE  (Contácteme) 15:15, 30 de marzo de 2009 (UTC) [ responder ]
  33. Soporte - El formato automático sin enlaces wiki me parece una buena solución. -- TreyGeek ( discusión ) 15:44 30 mar 2009 (UTC) [ responder ]
  34. Apoyo el concepto general , pero no la forma en que se implementó. Creo que se podría aplicar formato automático sin incluir enlaces wiki y, de algún modo, incorporar las preferencias de fecha o de región del usuario en lugar de depender únicamente de que el 0,5 % de los lectores cambien sus configuraciones y el resto de nosotros supongamos que lo han hecho. Orderinchaos 15:59, 30 de marzo de 2009 (UTC) [ responder ]
  35. Admite formato automático sin enlaces automáticos, principalmente para su uso en metadatos. Sin embargo, consideraré eliminar mi preferencia de fecha para poder ver las páginas como las ven las direcciones IP, incluso si el formato predeterminado no es mi favorito. Certes ( discusión ) 16:02 30 mar 2009 (UTC) [ responder ]
  36. Admite el formato automático porque es necesario que haya coherencia, ya que a veces resulta confuso si se mezclan, por ejemplo, 03/03/2009 significa el tercer día del tercer mes del año 2009, y a veces me confundo. DeMoN 2009 16:14, 30 de marzo de 2009 (UTC) [ responder ]
  37. Soporte - Aunque reconozco que prácticamente todos los hablantes de inglés reconocen una fecha en cualquier formato común, el formato de fecha es un problema que rara vez les ocurre a los editores, y parece descuidado tener varios formatos diferentes en un artículo. -- Skeezix1000 ( discusión ) 16:26, 30 de marzo de 2009 (UTC) [ responder ]
  38. Soporte . No puedo evitar la sensación de que esto no sería un problema si la implementación de #formatdate hubiera venido primero, en lugar de sobrecargar esta función en la vinculación. Francamente, no sabía que existía #formatdate hasta que vi esta encuesta, pero siempre pensé que algo como esto era el mejor enfoque. En el pasado, generalmente he desvinculado fechas al realizar otras ediciones a artículos; ahora puedo reformatear en su lugar. Esto es un progreso. Rklear ( discusión ) 16:48, 30 de marzo de 2009 (UTC) [ responder ]
  39. Soporte . Los lectores pueden estar familiarizados con "3 de febrero de 2009" y "3 de febrero de 2009" (y no tengo una preferencia marcada por ninguno de los dos formatos), pero el formato automático puede ayudar a evitar las abominaciones que son "3/2/09" y "2/3/09", tanto al formatear como "DD MMM AAAA" o "MMM DD AAAA" (es decir, no "DD/MM/AA" o "MM/DD/AA") como al alentar a los editores a especificar las fechas utilizando la plantilla. La coherencia a lo largo de un artículo es una gran ventaja, y la opción para que los lectores vean los formatos de fecha según su navegador o configuración regional del sistema operativo es una ventaja. En el futuro, el formato automático podría incluso utilizarse para crear enlaces wiki a meses y años, lo que haría que tratar el resultado de las dos discusiones siguientes fuera relativamente trivial. Saludos, Esta bandera alguna vez fue roja actos de propaganda 17:14, 30 de marzo de 2009 (UTC) [ responder ]
  40. Apoyo . Estoy de acuerdo con el punto de vista de flag. Para mí es mucho más rápido ver las fechas de una manera que veo todos los días y puedo reconocer. Grk1011/Stephen ( discusión ) 17:20 30 mar 2009 (UTC) [ responder ]
  41. EspañolApoyo la idea , ya que me resultó muy útil e interesante poder hacer clic en una fecha y ver qué otros eventos sucedieron en ese momento. Sí, había (y todavía hay) muchos artículos vinculados a fechas específicas (como sucede en un mundo con una larga historia), pero creo que ese argumento es irrelevante. Toda esta preocupación por los artículos que tienen demasiados enlaces a ellos es una preocupación inútil, ya que tendremos cada vez más artículos vinculados entre sí a medida que la enciclopedia crezca. ¿Vamos a empezar a limitar la cantidad de enlaces que se pueden colocar en los artículos cuando alcancemos los 5 o 10 millones de artículos solo para no tener "demasiados enlaces" a un artículo determinado? Eso es simplemente absurdo. Vamos a tener que aceptar que muchos artículos sobre un tema principal tendrán cientos, miles y quizás decenas de miles de enlaces a ellos. En el caso de las fechas, es probable que estén en el extremo superior de las cosas, pero eso es lo que sucede cuando una enciclopedia en línea crece. Y el argumento de que alguien tendrá que volver a colocar los enlaces que alguien eliminó es absurdo. Simplemente ejecute los mismos bots nuevamente, pero al revés. Seguramente no será más difícil de lo que fue eliminarlos a todos. También creo que la parte del formato de fecha es muy útil, y no sería difícil establecer el valor predeterminado para los usuarios anónimos (y aquellos que no lo han cambiado) en algo como "3 de junio de 1934". ***¿ Holandés ? * Hablar con Nihonjoe 17:37, 30 de marzo de 2009 (UTC) [ responder ]
    1. Hago comentarios adicionales, ya que SIllyFolkBoy no parece pensar que mis comentarios anteriores estén lo suficientemente enfocados. El formato automático sería extremadamente útil (como señalé anteriormente) para crear un formato consistente para las fechas, y no sería difícil establecer el formato predeterminado en algo que sea útil para todos (como el ejemplo que di anteriormente). Como creo que la forma más fácil de implementar esto es la vinculación de fechas ya existente mediante corchetes, incluí los comentarios sobre la utilidad de hacerlo, así como mi opinión sobre lo absurdo del argumento "pero crea demasiados enlaces entrantes al artículo". ***日本穣? * Hablar con Nihonjoe 19:13, 30 de marzo de 2009 (UTC) [ responder ]
  42. Soporte . Proporcionar un formato de fecha consistente sería beneficioso para la apariencia de los artículos y de Wikipedia. Presumiblemente, el rastreo de IP también podría usarse para proporcionar MDY para lectores norteamericanos y DMY para otros, incluso si no son usuarios registrados. También eliminaría la necesidad de enlaces de fecha como una forma de autoformato que diluye los enlaces wiki y generalmente es de poca utilidad. Por favor, al menos implementen el código para que exista la opción de usar autoformato que se puede determinar, como con los estilos de referencia, por consenso en artículos individuales. |→ Spaully † 18:07, 30 de marzo de 2009 ( GMT )
  43. Soporte Soy un usuario de EE. UU. que lee y edita principalmente artículos de EE. UU., pero odio el estándar de EE. UU. para el formato de fechas y prefiero el estándar europeo. Es bueno que Wikipedia pueda ofrecer a todos la opción de formatear las fechas como prefieran. Creo que el sistema funcionaba bien hasta que a alguien le entró un problema con los enlaces "innecesarios". Ntsimp ( discusión ) 18:27, 30 de marzo de 2009 (UTC) [ responder ]
  44. Apoyo para dar una opción al usuario. davidwr / ( discusión )/( contribs )/( e-mail ) 18:31 30 mar 2009 (UTC) [ responder ]
  45. EspañolApoyo que vale la pena tenerlo como una opción. Me gustaría señalar que la eliminación del formato automático de los artículos destacados no fue debatida, simplemente se hizo. En ese momento me opuse, argumentando que no mejoraba las cosas, pero tuve la sensación de que no valía la pena insistir. Desde entonces, ha sido _un solo_ usuario el que lo ha impulsado. Dicho esto, un sistema que fuera totalmente automático sería mucho mejor, en particular si también pudiera manejar zonas horarias (que es un problema mucho más importante que el formato de fecha). Mike Peel ( discusión ) 18:54, 30 de marzo de 2009 (UTC) [ responder ]
  46. Admite formato automático. Prefiero DMY, no me molesta mucho MDY, pero odio el formato YMD. Es muy feo y me parece poco profesional. Mjroots ( discusión ) 19:10 30 mar 2009 (UTC) [ responder ]
  47. Soporte por usuario:Esta bandera alguna vez fue roja -- Cybercobra ( discusión ) 19:47 30 mar 2009 (UTC) [ responder ]
  48. Soporte . Simplemente mejor . Lo ideal sería que se pudiera elegir mediante (en orden de prioridad) (i) opción de usuario (ii) opción de artículo (iii) opción predeterminada para todo el sitio y otras. Mr Stephen ( discusión ) 19:51, 30 de marzo de 2009 (UTC) [ responder ]
  49. Apoyo . Creo que el formato automático es bueno, pero si hay un problema con el software que permite a los usuarios elegir de qué manera quieren ver la fecha, entonces los desarrolladores deberían solucionarlo para que podamos dejar de votar al respecto. Kumioko ( discusión ) 20:07, 30 de marzo de 2009 (UTC) [ responder ]
  50. Soporte Esto elimina la complicación potencial de intentar unificar los estilos posteriormente para que todas las fechas sean uniformes. ¿Por qué hacer que aparezcan de forma diferente en distintos artículos o intentar ponerse de acuerdo sobre un método (lo que nunca sucedería), cuando podemos convertirlo en una preferencia del usuario? JeremyMcCracken ( discusión ) ( contribuciones ) 20:18, 30 de marzo de 2009 (UTC) [ responder ]
  51. Soporte - ¿Por qué no dejar que los usuarios elijan cómo se muestran las fechas? -- Jackieboy87  ( discusión  * contribs ) 20:25, 30 de marzo de 2009 (UTC) [ responder ]
  52. Sería mejor que MediaWiki formateara automáticamente las fechas con un marcado adicional, sin que hubiera excepciones en el formato de nowiki. -- Jeandré , 2009-03-30 t 21:23z
  53. Apoye los beneficios de las líneas de tiempo automatizadas; esta página de un día en la historia podría ser muy importante. Brandonrush ¡Guau, cerdo! 21:26, 30 de marzo de 2009 (UTC)[ responder ]
  54. Tal vez soy obsesivo-compulsivo, pero le doy mucha importancia a la personalización como parte integral de la usabilidad. La nueva actualización del software ofrece un gran punto intermedio. – Sarregouset (discusión) 21:27 30 mar 2009 (UTC) [ responder ]
  55. Aunque no creo que sea un gran problema, lo apoyaría . Debería ser lo suficientemente automatizable como para no ser una gran carga. Ofrece la posibilidad de (por ejemplo) buscar todos los artículos que hagan referencia a una fecha en particular, lo que, a pesar de las afirmaciones en contra, actualmente no parece ser posible. La coherencia para los lectores es buena. Gareth McCaughan ( discusión ) 21:32 30 mar 2009 (UTC) [ responder ]
  56. Soporte . Wikipedia debería estar escrita para los lectores, y proporcionar a los usuarios registrados una visualización coherente de las fechas mejora su experiencia sin restar valor a la información proporcionada a un usuario no registrado, ya que seguiría viendo un formato coherente dentro de un artículo. -- Whpq ( discusión ) 21:44, 30 de marzo de 2009 (UTC) [ responder ]
  57. Soporte . Preferiría tener formato automático sin enlaces automáticos, pero lo aceptaré de cualquier manera. RossPatterson ( discusión ) 22:08 30 mar 2009 (UTC) [ responder ]
  58. Soporte . La coherencia y la personalización del lector son factores importantes en este caso. Julianhall ( discusión ) 22:16 30 mar 2009 (UTC) [ responder ]
  59. Soporte . Como programador web que participa en muchos debates de i18n , cualquier forma de proporcionar a los usuarios (más lectores que editores) coherencia en los datos que se muestran es útil. -- Mike Vitale 22:38, 30 de marzo de 2009 (UTC) [ responder ]
  60. Fuerte apoyo Con la nueva función de análisis y la posibilidad de un valor predeterminado, se resuelven las principales razones de oposición. Además, no hay ninguna razón por la que debamos proporcionar algo que no sea la experiencia de visualización más cómoda posible Alex fusco 5 23:59, 30 de marzo de 2009 (UTC) [ responder ]
  61. Soporte . Preferiría tener la posibilidad de elegir el formato de fecha con el que estoy más familiarizado. -- Le Petit Modificateur Laborieux ( discusión ) 01:12 31 mar 2009 (UTC) [ responder ]
  62. Soporte de conveniencia. Además, mantiene el mismo estilo que antes... el formato automático es útil. Daniel Benfield ( discusión ) 01:15, 31 de marzo de 2009 (UTC) [ responder ]
  63. Admite formato automático. Es importante que las colecciones de artículos tengan un formato de fecha coherente, y el método actual permite incómodas discordancias entre artículos. El formato automático también permite preferencias del usuario, lo que hace que Wiki sea más universal y menos centrada en la cultura del editor o editores del artículo. Chuckiesdad / Discusión / Contribs 01:56, 31 de marzo de 2009 (UTC) [ responder ]
  64. Fuerte apoyo La coherencia dentro y entre los artículos y la elección del usuario son importantes para muchas personas. Si no es importante para ti, ¿por qué votas? hulmem ( discusión ) 03:13, 31 de marzo de 2009 (UTC) [ responder ]
  65. También apoyo el formato automático sin enlaces automáticos. shoy ( reacciones ) 03:33, 31 marzo 2009 (UTC) [ responder ]
  66. Se necesita soporte para la recuperación fiable de datos semánticos Nicolas1981 ( discusión ) 06:10 31 mar 2009 (UTC) [ responder ]
  67. Soporte : A pesar de mi temor por el esfuerzo que implica implementar el sistema, me gusta la propuesta de autoformato como una forma de ayudar a los lectores. Hasta donde yo sé, las enciclopedias impresas no cambian de formato de fecha, así que ¿por qué Wikipedia debería hacerlo? (Disculpas por agrupar los diferentes tipos de enciclopedias en una sola categoría). Si tienes alguna pregunta, por favor contáctame en mi página de discusión . Ian Manka 06:13, 31 de marzo de 2009 (UTC) [ responder ]
  68. Soporte : La localización y la personalización son el futuro. Wikipedia debe sumarse a esta tendencia. — D. Wo. 06:38, 31 de marzo de 2009 (UTC) [ responder ]
  69. El apoyo se basa más en el argumento de la conformidad y la uniformidad que en cualquier otra cosa. bahamut0013 palabras hechos 07:01, 31 de marzo de 2009 (UTC) [ responder ]
  70. Apoyo . El formato automático es algo bueno, especialmente porque la mayoría de los editores se niegan a escribir fechas en el formato que me parece más fácil de descifrar. Con el formato automático, todos pueden estar contentos al mismo tiempo. En serio, ¿quién podría objetar eso? La mayoría de los votos "en contra" aquí parecen argumentar en contra de la vinculación de fechas, lo cual es ciertamente inquietante, pero tampoco es lo que se pregunta en esta encuesta. – Henning Makholm ( discusión ) 11:00, 31 de marzo de 2009 (UTC) [ responder ]
  71.  –  aroma de iride 13:03, 31 de marzo de 2009 (UTC) [ responder ]
  72. Soporte . El formato automático es neutral en apariencia, pero se adapta a los usuarios que desean una preferencia en el estilo de fecha. GraemeLeggett ( discusión ) 15:39, 31 de marzo de 2009 (UTC) [ responder ]
  73. suppoet Bubba73 (discusión) , 15:52 31 mar 2009 (UTC) [ responder ]
  74. Soporte Se utiliza para trabajar de forma transparente y eficaz para dar a los usuarios conectados la preferencia de fecha de su elección. -- Old Moonraker ( discusión ) 16:18 31 mar 2009 (UTC) [ responder ]
  75. Apoyo Creo que la vinculación de fechas/metadatos es, de lejos, el aspecto más interesante. Obtener un formato de fecha uniforme sería un buen añadido, ¡y apoyemos a los budistas! Los argumentos en contra parecen propaganda ludita, por supuesto, la plantilla debería ser lo más fácil de usar posible. Realmente no entiendo el argumento en contra de ISO, ¿qué tiene de difícil 20090331? No, en serio. Unomi ( discusión ) 16:31 31 mar 2009 (UTC) [ responder ]
  76. Apoyo . Evite discusiones sobre qué formato utilizar para un artículo en particular. Bluewave ( discusión ) 16:54 31 mar 2009 (UTC) [ responder ]
  77. Soporte . La fecha es un elemento esencial para registrar y archivar datos, información y conocimiento. El formato es un aspecto importante para las marcas de fecha y hora. El formato debe ser uniforme en toda la comunidad. Después de todo, ¿no somos una comunidad? Desafortunadamente, muchos de los argumentos en contra no son convincentes; parecen más propaganda anarquista que comentarios u opiniones constructivas sobre el tema en discusión. Si nosotros, como comunidad, no podemos establecer una expectativa básica para la datación de registros, ¿por qué tenemos todas las demás reglas y pautas en vigor? PatientSafetyGuru ( discusión ) 17:31 31 mar 2009 (UTC) [ responder ]
  78. Apoyo . Es esencial que logremos que esto sea coherente para evitar algo como 1-2-2009/2-1-2009, que es ambiguo. La falta de estandarización es simplemente descuidada y hace que los artículos parezcan carentes de credibilidad. Dado el poder de los wikibots, formatear todo automáticamente no debería ser una tarea excesivamente difícil. -- Analogue Kid ( discusión ) 17:54, 31 de marzo de 2009 (UTC) [ responder ]
  79. Apoyo . Esta es la manera de hacerlo, porque es muy efectivo. Showtime2009 ( discusión ) 18:09 31 mar 2009 (UTC) [ responder ]
  80. Soporte . Entiendo que puede ser un fastidio reconfigurar páginas usando plantillas o funciones de análisis, pero no creo que esa sea una razón para limitar la elección de un usuario. ¿No se podría escribir un bot para hacer esto de todos modos (o quizás escribirlo en AWB)? ¿Y escribir entre 10 y 20 caracteres adicionales es realmente un problema tan grande? Daniel J Simanek ( discusión ) 18:40, 31 de marzo de 2009 (UTC) [ responder ]
  81. Apoyo . No debería ser algo fuera de lo común permitir el formato automático de las fechas. Además, cualquier oposición con fundamentos en contra de la vinculación de fechas debería ser ignorada; no deberíamos contar los votos de las personas que han demostrado claramente que no entienden la propuesta. El argumento de que no hay ningún problema que resolver también es algo así como un non-sequitur , si todo lo que estás diciendo es que a ti personalmente no te molesta tanto cambiar entre diferentes formatos de fecha, entonces esa no es una razón para bloquear la elección de otros. La objeción sobre la base de que te causa más trabajo es posiblemente válida si realmente sientes que no puedes con las pulsaciones de teclas adicionales. Personalmente, preferiría una sintaxis más corta que, por ejemplo, {{#formatdate|31 de marzo de 2009}}, algo como {{d|2009-03-31}} podría funcionar, como otros han sugerido. -- SallyScot ( discusión ) 19:53 31 mar 2009 (UTC) [ responder ]
  82. Soporte . Por el precio de cuatro corchetes ([[ ]]) alrededor de las fechas y no más de diez horas de tiempo de programación de un desarrollador PHP experimentado (lo sé porque ya escribí el código una vez) podemos tener formatos de fecha consistentes en todo el proyecto, la capacidad de tener valores predeterminados por artículo que anulen los valores predeterminados de todo el sitio, soporte para rangos de fechas y la capacidad para que los usuarios registrados especifiquen sus preferencias de formato de fecha y de enlace de fechas de forma independiente. Esto eliminaría por completo la necesidad de volver a discutir sobre formatos de fecha o enlaces de fechas, y permitiría que casi todos tengan lo que quieren. -- UC_Bill ( discusión ) 20:34, 31 de marzo de 2009 (UTC) [ responder ]
  83. Fuerte apoyo . El formato de fecha debe verse como un primer paso obvio hacia el objetivo más general de mostrar a los lectores de Wikipedia el contenido de los artículos presentados de la manera que el lector individual encuentre más útil. Deberíamos hacer esto para algo tan pequeño como los formatos de fecha ahora. Podríamos hacer esto para algo tan grande como las variaciones ortográficas del idioma inglés. Esperamos que algún día podamos hacerlo para mucho más que eso. ( sdsds - discusión ) 20:36, 31 de marzo de 2009 (UTC) [ responder ]
  84. Los estándares de soporte son una cosa maravillosa - el problema es que hay tantos para elegir - Ahora tenemos la solución a un caso de ese problema: el formato automático de fecha ;) ClemMcGann ( discusión ) 21:44, 31 de marzo de 2009 (UTC) [ responder ]
  85. Soporte Es realmente confuso si estás editando un artículo en un formato y su visualización está en el otro formato Nessie ( discusión ) 21:55, 31 de marzo de 2009 (UTC) [ responder ]
  86. Apoyo Pero, por favor, apoyemos todos lo que decidamos y dejémoslo así. Este es un tema monumentalmente aburrido. Todos deberíamos volver a escribir e investigar. ---- CharlesGillingham ( discusión ) 22:51 31 mar 2009 (UTC). [ responder ]
  87. El hecho de permitir que los usuarios vean las fechas como prefieran contribuye a que Wikipedia sea más fácil de usar. También observo que muchos de los votos en contra se quejan de los enlaces y del "mar azul", que son irrelevantes para la solución propuesta y, por lo tanto, deberían descartarse. -- Arwel Parry (discusión) 22:57, 31 de marzo de 2009 (UTC) [ responder ]
  88. Las preferencias de los usuarios (es decir, los lectores) deberían tener prioridad sobre las decisiones editoriales. Prefiero que los formatos de fecha (y los enlaces) se especifiquen en las preferencias, en lugar de que los dicte un pequeño grupo de MOSNUM. -- Sapphic ( discusión ) 00:02 1 abr 2009 (UTC) [ responder ]
  89. No hay que pensarlo dos veces. No interrumpas el análisis del artículo con obstáculos como formatos extraños (para el lector). -- Kbh3 rd talk 01:22, 1 de abril de 2009 (UTC) [ responder ]
  90. Soporte , sorprendiéndome a mí mismo después de pensarlo un poco. Al principio, solo me molestaba la eliminación del marcado existente, ya que los argumentos "KISS" y "No hay ningún problema que resolver" son convincentes, y las aplicaciones existentes (vinculación automática a una página sobre ese año o una página sobre esa fecha, permitiendo a los usuarios registrados elegir su formato de visualización de fecha) son de dudoso mérito. Pero la idea de que estos metadatos puedan tener algún uso futuro es tentadora:
    • Existe una diferencia de rendimiento y calidad entre una búsqueda que utiliza un algoritmo de análisis (es decir, uno que intenta reconocer datos mediante la comparación de patrones de los datos en sí) y una que utiliza metadatos. Algo que ha sido marcado por un editor humano como una fecha es más informativo, desde el punto de vista de la máquina, que su propia conjetura sobre lo que podría ser una fecha. Esto es así incluso si el texto marcado de esta manera no sigue ninguna convención estándar más allá de ser legible por humanos como una fecha. Si se permite <tag>18 de octubre de 1945</tag>, así como <tag>Dieciocho de octubre de 1945</tag> e incluso <tag>en octubre de ese año</tag>, la existencia de las etiquetas no hace nada para restar valor a los datos presentados y permite el desarrollo de futuras aplicaciones que bien podrían presentar datos útiles al usuario. Consideremos, por ejemplo, un analizador que fuera capaz de resolver ese último ejemplo, a partir del contexto del artículo, como una fecha concurrente con los dos primeros: esa podría ser una característica de investigación útil, y una cuyo funcionamiento sólo podría verse facilitado por el etiquetado de fechas. O imaginemos un artículo histórico en el que el autor considera útil utilizar el calendario local antiguo para relacionar la secuencia de eventos. Si se etiqueta cada fecha, una aplicación podría ofrecer conversiones automáticas emergentes de cada fecha a otros calendarios relevantes.
    • El argumento de que la mayoría de los usuarios actuales no ven ninguna diferencia es relevante sólo para las aplicaciones existentes, que nadie parece considerar útiles. Si una aplicación futura puede explotar estos metadatos con fines útiles, dicha aplicación podría convertirse en parte de la interfaz estándar, en lugar de configurarse opcionalmente para cada usuario.
    • Si bien el etiquetado de fecha descrito anteriormente podría ser potencialmente útil para las máquinas y, al mismo tiempo, prácticamente no afectaría al usuario, sería MUCHO MÁS útil para las máquinas agregar un campo a la etiqueta que especifique la fecha en un formato estándar, mientras que el texto adjunto continúa mostrándose tal como está escrito. Esto permitiría el etiquetado por parte de robots sin afectar el contenido principal (por ejemplo, las citas) y permitiría que los defensores actuales del formateador automático opcional sigan experimentando con él.
    • No es necesario que todas las fechas, o incluso algunas, estén etiquetadas en un artículo y, mientras no aparezca una "aplicación revolucionaria" que haga que los editores quieran fechas etiquetadas, es posible que la mayoría de los artículos no tengan ninguna que no esté insertada mediante el etiquetado de un bot. Con la aparición de una aplicación de este tipo, probablemente se produciría un aumento del etiquetado de fechas retrospectivo.
    • Por supuesto, la duplicación de la fecha en la etiqueta implica el riesgo de que las dos fechas acaben siendo diferentes, pero esto no me parece nada nuevo para los editores de Wikipedia: casi todos los datos de la enciclopedia se pueden encontrar en más de un lugar y, en muchos casos, en cientos de artículos diferentes. Evitar la posibilidad de incoherencia no es un objetivo realista ni necesario.
    • El trabajo adicional que implica crear páginas no debería ser un problema: los editores que no estén convencidos del valor de las etiquetas de fecha pueden simplemente omitirlas. Siempre que su elección de formato no sea demasiado oscura ("en la tercera luna después de Michaelmas, en el año del largo invierno"), no debería ser demasiado difícil para los editores y bots posteriores agregarlas, si así lo desean.
    Nyelvmark (discusión) 01:30, 1 de abril de 2009 (UTC) [ respuesta ]
  91. Soporte - Soy de Australia y prefiero ver las fechas en formato DMY. Si hay una manera de formatear automáticamente todas las fechas según las preferencias de cada usuario, entonces creo que es una gran idea. Wcp07 ( discusión ) 05:23, 1 abril 2009 (UTC) [ responder ]
  92. EspañolApoyo Este es un problema real dentro de Wikipedia que ya ha llevado a ArbCom a varios usuarios. Me parece mucho más fácil establecer una regla para que las fechas aparezcan de manera consistente que permitir, bueno, a veces el formato A y a veces el formato B porque siempre habrá áreas grises . Una guía específica reducirá los problemas si todos nos pusiéramos de acuerdo en un formato estándar para usar. No tengo ninguna preferencia en particular. Dicho esto, permitir que las configuraciones personales determinen la presentación del material sería el siguiente mejor paso. Sin embargo, la razón principal por la que estoy respondiendo es que los problemas planteados en la oposición. También me gustaría tomarme unos segundos para abordar cada comentario en la notificación de oposición.
    " No hay ningún problema que resolver ", dice un caso actual en ArbCom
    " El hecho de que el día o el mes aparezcan primero (3 de enero; 3 de enero) es trivial: todos los angloparlantes reconocen ambos; el ejército de los EE. UU. usa DMY, al igual que muchos canadienses; por el contrario, muchas publicaciones fuera de Norteamérica, incluidos los periódicos, usan MDY ". Reconocer que existen diferentes formatos no es nada especial. El problema es que cada uno usa estándares diferentes a los demás y Wikipedia es un conglomerado de todas estas preferencias nacionales.
    " Dado este entorno mixto, es poco probable que los lectores se den cuenta, y mucho menos les importe, qué formato se utiliza en un artículo. Los artículos destacados, que representan nuestros estándares máximos de profesionalismo, abandonaron el formato automático en septiembre pasado y ahora utilizan exclusivamente fechas de texto fijo y simple; esto apenas ha recibido una mención en los candidatos a artículos destacados ". Si bien a pocos les importa qué formato se utiliza, una enciclopedia de calidad (que es un objetivo de Wikipedia) utiliza fechas consistentes. Los lectores sí lo hacen, y deberían notar este tipo de problemas: "El aire alrededor de Los Ángeles estaba contaminado desde el 21 de diciembre de 2008 hasta el 3 de enero de 2009", por lo que la gente nota tales inconsistencias. Los criterios de los artículos destacados se basan en WP:MoS para estos asuntos, por lo que de todos modos no son el lugar apropiado para tales discusiones. Como colaborador de más de una docena de artículos destacados, puedo asegurarles que formatear cientos de fechas en un artículo (que aparecen principalmente en las referencias) es un verdadero dolor de cabeza. Y no es algo "sencillo" de hacer, pero la coherencia de fechas es un requisito para los agentes financieros. Esto simplificaría el proceso drásticamente.
    " En términos más generales, un usuario ha desvinculado y corregido fechas en más de 7.000 artículos, pero ha recibido sólo un puñado de objeciones ". Otro lo ha hecho con muchos más artículos y ahora sus acciones lo han colocado en ArbCom.
    " El principio fundamental es que no debe haber dos clases de usuarios. Como algunos editores registrados verían formatos de fecha diferentes a los del resto (véase Wikipedia:DONOTLINKDATES), esto conduciría inevitablemente a una confusión de formatos de fecha inconsistentes ". Todo este argumento es una pista falsa. Ya existen diferencias significativas entre los usuarios registrados y los anónimos (es decir, subidas de imágenes, movimiento de páginas, páginas semiprotegidas, etc.). Añadir una más no es un gran problema. Mientras elijamos un formato de fecha predeterminado, no debería haber inconsistencias con los usuarios no registrados.
    " Complejo y laborioso. Etiquetar decenas de millones de fechas con un marcador como {{#formatdate|11 de marzo de 2009}} (el doble de pulsaciones de teclas, incluso más si se añade |dmy/md), y especialmente etiquetar casi tres millones de artículos para establecer un formato de fecha predeterminado, sería un precio enorme a pagar por el beneficio mínimo de ver las fechas en un formato específico, y complicaría las cosas para los editores nuevos y ocasionales. MOSNUM ya tiene reglas simples y bien aceptadas para el formato de fechas, que no requieren marcado. En el contexto de intentar lograr una solución simple, el Director Técnico de WikiMedia, Brion Vibber, ha declarado: "Mi recomendación personal sería eliminar todo el formato automático de fechas...". " Esto no es demasiado complejo y un bot podría implementarlo sin muchos problemas y evitaría problemas posteriores. Las opiniones del Director Técnico Brion Vibber son suyas y esto es menos un problema técnico que un problema de coherencia de escritura . Toda guía de escritura tiene un estándar y todas las enciclopedias importantes utilizan una fecha fija. ¿Por qué nosotros deberíamos ser diferentes?
    " Falacia de metadatos... " Todo parece estar relacionado con la capacidad de vinculación del texto, que solía ser la norma. Este no es el caso aquí y está completamente fuera de tema.
    " El fracaso del autoformato original se debió en gran medida a la imposición ad hoc de un diseño por parte de programadores que actuaban sin especificaciones acordadas (objetivos claros) por la comunidad. Las llamadas correcciones sugeridas tienen un alcance y una funcionalidad limitados, y no han sido acordadas por la comunidad. No deberíamos arriesgarnos a permitir que se añadan soluciones poco a poco durante los próximos años, lo que requeriría una sintaxis cada vez más complicada, aún más alejada del editor promedio. Entre estos problemas estarían los espacios indivisibles, AD/BC, las fechas con barra, ISO y Gregorianas/Julianas. Los rangos de fechas, evitando la torpeza y las repeticiones forzadas que implicaba el sistema original, serían un desafío significativo. " Bien... ¿y qué? Ya tenemos estos problemas, pero al estandarizar las fechas, permitimos que esos cambios masivos en toda Wikipedia se implementen con un solo cambio en una sola plantilla en lugar de millones de cambios.
    — BQZip01 —  discusión 05:39 1 abril 2009 (UTC) [ responder ]
  93. Soporte - Me gustó la posibilidad de que la fecha se ajustara a mis preferencias personales antes de que quedara obsoleta y de configurar todo el contenido que escribí de esa manera; además, por supuesto, ¿qué sentido tiene tener la opción de cambiar la preferencia si los artículos en sí no se pueden cambiar con ella? Colds7ream ( discusión ) 07:25 1 abril 2009 (UTC) [ responder ]
  94. Soporte - Esto es obvio. Por supuesto, los lectores deberían ver las fechas en su formato preferido. -- guyzero | discusión 07:30, 1 abril 2009 (UTC) [ responder ]
  95. Es mejor que intentar descifrar qué significa realmente 01-02-03 o 04-05-2006 o 2009-08-07. — Twas Now ( discusióncontribse-mail ) 09:20 1 abr 2009 (UTC) [ responder ]
  96. Soporte Creo que es una muy buena idea, especialmente porque algunas personas necesitan este tipo de facilidad de uso. XxReikoxX - The Visual Asia Geek ( discusión ) 09:38, 1 abril 2009 (UTC) [ responder ]
  97. Soporte – En realidad, se trata de dos cosas diferentes: ¿debería haber algún tipo de marcado para identificar algo como una fecha y debería utilizarse el marcado para permitir preferencias personales en el formato? En términos generales, el marcado suele ser una buena idea, incluso si no podemos pensar en buenos usos para él en este momento. Disfruto de tener la capacidad de especificar una preferencia personal para el formato de fecha y me gustaría poder especificar preferencias personales para incluso más cosas en el futuro (unidades métricas versus unidades no métricas, "color" versus "color", etc.); tales cosas son imposibles sin el marcado. Estoy de acuerdo con la objeción de que los usuarios anónimos no deberían ser excluidos de las funciones que disfrutan los usuarios registrados y contraataco que es posible, en principio, modificar el software para permitir que los usuarios anónimos almacenen preferencias en cookies. Estoy de acuerdo con la objeción de que {{#formatdate|11 de marzo de 2009}} sería complejo y laborioso, pero contraataco que la sintaxis de marcado real aún no se ha determinado y espero que no sea tan compleja y laboriosa. No estoy de acuerdo con la objeción que se hace en el apartado "Falacia de metadatos" de la "Declaración en contra"; es casi imposible para una herramienta de búsqueda diferenciar entre una fecha que es candidata a reformatearse y otra que no lo es (por ejemplo, las fechas entre comillas no deberían reformatearse). Estoy de acuerdo con las preocupaciones que se plantean en el apartado "Riesgos de desarrollo" de la "Declaración en contra", y espero que esas preocupaciones se tengan en cuenta cuando se resuelvan los detalles de sintaxis. Las personas que se quejan de los enlaces excesivos no entienden el punto; el formato y los enlaces son conceptos independientes, aunque ambos requieren marcado. — AlanBarrett ( discusión ) 15:44, 1 abril 2009 (UTC) [ responder ]
  98. Apoyo a AlanBarrett, que lo resumió muy bien. — Nightstallion 16:26, 1 de abril de 2009 (UTC) [ responder ]
  99. Soporte Al permitir el formato automático, marcamos explícitamente el hecho de que una parte particular de la fecha es una fecha. Cualquier marcado semántico de esa forma obtiene mi apoyo, independientemente de cómo se use (dentro de lo razonable). Estoy de acuerdo con algunos de los otros comentarios de que la sintaxis {{#formatdate}} es verbosa; tal vez se pueda encontrar algo mejor. Pero eso es incidental. Escribir un bot para convertir entre sintaxis es fácil, como lo es escribir un bot para eliminar la sintaxis. (Escribir un bot para agregar marcado es necesariamente propenso a errores, lo que significa que molestará a las personas, pero con suerte no necesitamos hacer eso. Un bot que revisara las ediciones anteriores de Lightbot y revirtiera todas las ediciones de eliminación de marcado de fecha podría ayudar). ¿Qué ganamos con esto? El formato automático, en el sentido actual de permitir que los usuarios registrados jueguen con alguna configuración bien oculta y cambien entre "1 de abril" y "1 de abril" es solo la punta del iceberg. Tal vez en el futuro podamos usar RDF/A para indicar a los navegadores que se trata de una fecha, y los navegadores del futuro podrían soportar el formato automático (de hecho, me sorprendería que no lo hicieran). Esto permitirá que el software (por ejemplo, los rastreadores web) extraigan fechas de los artículos de la misma manera que Google Maps lo hace con las coordenadas geográficas. En cinco años, quién sabe qué será posible y qué querrá la gente que Wikipedia pueda hacer. Pero puedo estar bastante seguro de que conservar la mayor cantidad posible de marcado semántico (es decir, marcar fechas como fechas, nombres como nombres, etc.) sólo puede ayudar a lograrlo. Perder información es casi siempre un paso atrás. Así que tengamos algún tipo de marcado de fecha incluso si decidimos que con el software Mediawiki actual no queremos habilitar el formato automático. — ras52 ( discusión ) 17:23, 1 abril 2009 (UTC) [ responder ]
  100. Apoyo , pero no porque piense que el formato automático en sí mismo sea el mayor problema a resolver, sino porque creo que las fechas deberían ser capturadas en metadatos y microformatos apropiados. Se debería evitar la vinculación de fechas a menos que sea relevante, pero si esos enlaces se eliminan de manera que el texto en prosa simple sea todo lo que quede para el marcado de fechas, entonces se pierde demasiada información valiosa. — Andrwsc  ( discusión  · contribs ) 18:31, 1 abril 2009 (UTC) [ responder ]
  101. Soporte , Es importante implementarlo correctamente, pero veo muy pocas desventajas en tener más metadatos y tener contenido personalizado en formato. Las objeciones me parecen estar orientadas a 1 argumentos KISS y 2 argumentos de pérdida de tiempo. El primero es, sin más, una generalización del segundo, y el segundo parece equivocado, particularmente dada la enorme cantidad de ediciones generadas al desvincular en primer lugar. 3 El impacto en el usuario casual es cero, el impacto en el usuario avanzado es relevante solo si uno elige anular las configuraciones, y la única desventaja es para los usuarios que eligen "perder" su tiempo, y los desarrolladores que ya "perdieron" su tiempo programándolo (según la propuesta, la función ya existe). 4 Las quejas restantes parecen estar basadas en un malentendido (que el formato automático = enlace automático, un punto que otros dejan en claro que no es la propuesta), o que 5 todos deberían "superarlo" o que es una buena experiencia educativa. Este último argumento apenas merece ser mencionado, salvo para decir que los usuarios deberían ser tratados como adultos (como lo son en la mayoría de las otras áreas de la -pedia) y pueden informarse sobre los formatos de fecha si así lo desean; los editores paternalistas no necesitan tomar esa decisión por ellos. Shadowjams ( discusión ) 19:47 1 abril 2009 (UTC) [ responder ]
  102. Apoyo . Prefiero ver las fechas de una determinada manera. Powers T 23:41, 1 de abril de 2009 (UTC) [ responder ]
  103. Soporte . Es un beneficio para los lectores y el mantenimiento puede ser realizado en su mayor parte por bots. Chonak ( discusión ) 00:23 2 abr 2009 (UTC) [ responder ]
  104. Apoyo . Prefiero formatos de fecha unificados y los metadatos también pueden ser útiles. Mark Hurd ( discusión ) 02:37, 2 abril 2009 (UTC) [ responder ]
  105. Soporte , me resulta más fácil editar y leer artículos sin preocuparme si la fecha está en MDY o DMY, y tener la opción de elegir es una buena idea en mi opinión, e incluso si la opción está ahí, eso no significa necesariamente que siempre tenga que estar formateada correctamente, wikipedia se trata de que los usuarios editen, por lo que si un usuario se encuentra con una fecha mal formateada, puede cambiarla, si al usuario no le importa, no tiene que hacerlo, todos ganan. -- GoldMan60 ¤ Discusión 04:39, 2 de abril de 2009 (UTC) [ responder ]  
  106. Apoyo Fue una gran solución para una guerra de edición en la que participé hace seis años, y cualquier cosa que dificulte a algunos imponer su punto de vista sobre las fechas vale la pena. Eclecticology ( discusión ) 08:25 2 abr 2009 (UTC) [ responder ]
  107. Permitir el formato automático según las preferencias personales detendrá toda la guerra de edición de enlaces y desvinculaciones, permitirá a los usuarios tener sus propias preferencias sin forzarlas a nadie más. Resuelve un montón de problemas de una sola vez. Si los desarrolladores simplemente crearan el formato automático para las fechas, no estaríamos teniendo esta discusión. La cantidad limitada de formatos de fecha significa que incluso se podría hacer sin formato adicional si los desarrolladores hicieran el esfuerzo. - Mgm | (discusión) 09:52, 2 abril 2009 (UTC) [ responder ]
  108. Soporte Como Wikipedia es una enciclopedia, la coherencia es esencial. Si un usuario realmente se opone a tener que prestar especial atención a la forma en que ingresa las fechas, estoy seguro de que un robot y los usuarios de soporte podrían encargarse de esa tarea. - m - i - k - e - y - talk 10:53, 2 de abril de 2009 (UTC) [ responder ]
  109. Soporte débil "Débil" debido al problema de inconsistencia para usuarios no registrados. Ed Fitzgerald t / c 13:08, 2 de abril de 2009 (UTC) [ responder ]
  110. Soporte , según Jeff (fechas consistentes, menos conflictos de edición).--Esprit15d • charlacontribuciones 13:29, 2 de abril de 2009 (UTC) [ respuesta ]
  111. Soporte , concentrémonos en el contenido. Dejemos el formato al sistema. -- NullSpace ( discusión ) 14:59 2 abr 2009 (UTC) [ responder ]
  112. Fuerte apoyo Personalmente, creo que SÍ vale la pena hacer un pequeño esfuerzo adicional para tener formato de fecha. Sin embargo, aquellos que no quieran hacer el esfuerzo pueden simplemente dejarlo en manos de otra persona. Debería ser una obviedad: dejemos que quienes quieran el formato lo tengan; que quienes no lo quieran lo ignoren. -- ThaddeusB ( discusión ) 16:23 2 abr 2009 (UTC) [ responder ]
  113. Apoyo , principalmente porque reducirá esa guerra de ediciones inútil y molesta. Davidelit ( discusión ) 17:13 2 abr 2009 (UTC) [ responder ]
  114. Fuerte apoyo ¿Por qué la gente le tiene miedo a la tecnología? Si no te gusta, desactívala en tus preferencias, pero no elimines opciones. Este fue uno de los beneficios de registrarte y algo que me animó a hacerlo originalmente. -- Patrick «» 17:14, 2 de abril de 2009 (UTC) [ responder ]
  115. Soporte , sólo por el argumento de metadatos. Si desmarcamos las fechas, estamos perdiendo información. Recuperar esa información, haciendo búsquedas de expresiones regulares o lo que sea, puede ser posible con frecuencia, pero ¿por qué molestarnos en hacerlo? -- Northernhenge ( discusión ) 17:48, 2 de abril de 2009 (UTC) [ responder ]
  116. Apoyo firmemente el formato automático de fechas por la sencilla razón de que es el método más simple para mantener a Wikimedia del lado del LECTOR cuando se trata del tema WYSIWYG que requiere el segundo número más pequeño de dígitos. El formato que reduciría el número de dígitos en el formato de fecha a un código simple de siete dígitos es uno que utilizaría un año de 4 dígitos, seguido de un día de 3 dígitos, dentro de corchetes, pero sin guiones interiores. Este método dependería de que el servidor interpretara el código y produjera el formato dictado por el LECTOR. Este método requeriría calcular el número del día en cuestión, recordando que hay 366 días en los años bisiestos. Concediendo que este método puede ser desalentador para algunos, recurro al método actual, que utiliza un año de 4 dígitos, un mes de 2 dígitos y un día de 2 dígitos, más 2 guiones interiores, para llevar el número total de dígitos a 10 más los corchetes. Es el compromiso que tiene más sentido desde todos los puntos de vista. El tema de los metadatos también es correcto. En cuanto al tema de los usuarios no registrados , la solución sencilla para ellos es editar su entrada para corregir el formato de los datos. - SSG Cornelius Seon (retirado) ( discusión ) 17:53 2 abril 2009 (UTC) [ responder ]
  117. Apoyo . Las fechas no son texto. Dejar que la heurística (¡o los humanos!) averigüen qué fecha se "pretendía" es algo malo. -- Alvestrand ( discusión ) 18:42 2 abr 2009 (UTC) [ responder ]
  118. Apoyo , creo que deberíamos intentar incluir una variedad más amplia de formatos de fecha. Además, esto facilita el cambio entre, por ejemplo, fechas vinculadas o no vinculadas. Muchos de los cambios se podrían realizar con AutoWikiBrowser / bots. -Zeus- u | c 19:43, 2 de abril de 2009 (UTC) [ responder ]
  119. Apoyo . No veo ninguna razón para impedir que otros obtengan un formato que puedan leer fácilmente, ya que no es un inconveniente para personas como yo, a quienes no les importa el formato que obtengan. Un escritor de artículos necesitará escribir unas cuantas teclas más, pero estará ingresando un formato estándar y no necesitará pensar en elegir un formato apropiado para el tema del artículo. Como tema secundario, creo que el formato automático sería una herramienta social útil para desalentar la aparición de fechas numéricas confusas (3/2/09 vs. 2/3/09, etc.). Esobocinski ( discusión ) 20:05 2 abril 2009 (UTC) [ responder ]
  120. Soporte . Creo que esta es una característica útil para los usuarios que no están acostumbrados al (mayormente usado) estilo de fecha de Norteamérica. Permitir el formato automático sería una solución conveniente para todos (aquellos a quienes no les importe podrían seguir viendo la fecha "normal" tal como está escrita en los diferentes artículos, mientras que aquellos a quienes les importe podrían elegir sus respectivas preferencias). Creo que esta es más la manera "wikipedista" de actuar que imponer el formato de fecha que un autor ha elegido usar en su artículo. Old Death ( discusión ) 21:29, 2 abril 2009 (UTC) [ responder ]
  121. Soporte - "Esto es obvio. Por supuesto, los lectores deberían ver las fechas en su formato preferido". -Arb. ( discusión ) 21:51 2 abr 2009 (UTC) [ responder ]
  122. Soporte - Demasiados artículos ya están marcados con la plantilla de mantenimiento globalizado por las razones más triviales, algunas incluso más triviales que el formato de la fecha. La solución ofrecida para reemplazar el formato automático (es decir, confiar en el "formato general" de un artículo para la localización del formato de fecha) probablemente agravará esta situación en lugar de mitigarla. -- JeffBillman ( discusión ) 23:11 2 abr 2009 (UTC) [ responder ]
  123. Soporte – Soy un fanático de las opciones, pero soy un fanático aún mayor de la consistencia , que es extremadamente difícil (más bien imposible) de lograr en un sitio wiki. momoricks (make my day) 00:39, 3 de abril de 2009 (UTC) [ responder ]
  124. Apoyo - Iba a votar "No" en base a la dificultad de implementar el sistema de Autoformato - pero pensándolo bien siento que Wikipedia es sólo la plataforma para que estos sistemas tecnológicos se desarrollen - y tener consistencia en todos los artículos para los usuarios es algo muy bueno. En respuesta al argumento "No hay problema" - no creo que el cambio deba necesariamente ser negado en base a tener un problema o no. El argumento "Si no está roto, no lo arregles" ignora la posibilidad de nuevas herramientas que pueden o no proporcionar una mejor experiencia. Sin embargo, nunca lo sabrás si no lo intentas. Matt australiano ( discusión ) 02:03, 3 abril 2009 (UTC) [ responder ]
  125. Apoyo firmemente Permitir que las fechas se formatee automáticamente por usuario es una idea excelente. Esto encarna el espíritu de neutralidad de Wikipedia. La etiqueta de formato automático agrega el beneficio de garantizar que las fechas en Wikipedia estén etiquetadas, de modo que si más adelante se discute un formato mejor, se puedan transferir al nuevo formato muy fácilmente. Dicho esto, creo que una sintaxis más sencilla podría hacer que sea más comprensible para los nuevos usuarios.
    Entiendo que algunas personas tienen una "confianza" emocional con el formato actual, y dedican miles de horas a editar manualmente las fechas para adaptarlas a su formato actual. Les agradezco su contribución, pero tengo el mismo aprecio por sus miles de horas de trabajo que por un programador que completó una tarea de escala similar en varias horas de codificación (siempre que ese programador no haya pisoteado demasiados pies). No debemos olvidar que es el fruto de su trabajo el que se propaga a la comunidad, no su trayectoria. Gsonnenf ( discusión ) 04:39 3 abr 2009 (UTC) [ responder ]
  126. Soporte condicional : el servidor debería formatear automáticamente las fechas a medida que se arma la página para el lector. Los editores no deberían tener que hacer nada para lograr esto: basta con escribir la fecha de manera uniforme en todo el artículo y listo. Binksternet ( discusión ) 05:52, 3 de abril de 2009 (UTC) [ responder ]
  127. El soporte para mirar hacia el futuro, el formato automático de fechas con sintaxis simple proporciona una garantía de futuro que va más allá de lo que muchos usuarios comprenden actualmente. Todo (bueno, en su mayoría) es alcanzable por BOT y proporciona una consistencia que no se logra actualmente debido en gran parte a inconsistencias y constantes ediciones y reversiones. Presentación predeterminada para usuarios de IP, e incluso eso se puede orientar en función de la ubicación percibida. Incluso se pueden proporcionar preferencias de forma individual para IP mediante un sistema de cookies como el que utiliza Google y muchos otros. ¿Cuál es la resistencia a la mejora aquí? No hay trabajo para quien no quiera hacerlo, los BOT y los wikignomos pueden hacer que suceda mucho mejor que el lío actual. El formato automático también permite cambiar instantáneamente entre vincular y desvincular según el argumento anual sobre eso - y sí, soy consciente de que vincular no está entrelazado con el formato.-- Club Oranje T 07:29, 3 de abril de 2009 (UTC) [ responder ]
  128. Soporte . Para mí, las ventajas del formato automático son obvias. Los robots se encargarán de actualizar las páginas existentes. Dampinograaf ( discusión ) 21:03, 3 abril 2009 (UTC) [ responder ]
  129. Soporte . -- IanOsgood ( discusión ) 22:39 3 abr 2009 (UTC) [ responder ]
  130. Soporte . La semántica a través de la sintaxis es algo bueno. Además, mucha gente navega en en.wikipedia.org y, en mi humilde opinión, preferiría el estilo ISO. Además, poder dar más detalles sobre una fecha y mostrar sólo unos pocos (como los enlaces wiki) daría como resultado artículos más legibles y aún más repletos de información. PAStheLoD ( discusión ) 23:09 3 abr 2009 (UTC) [ responder ]
  131. Soporte . Los días de los sistemas mainframe inflexibles han terminado, para bien o para mal, y la complejidad percibida que permiten es probablemente peor. Ahora es rutinario experimentar publicidad en banners que se relaciona con nuestro historial de navegación individual reciente, y sitios web que nos saludan por nuestro nombre y recuerdan nuestras preferencias, aunque sirven a millones de usuarios. Agregar una funcionalidad que obedezca a una cookie del navegador para mostrar las fechas en el formato preferido sin reformatear las fechas citadas no es un desafío técnico. En lo que respecta a la funcionalidad wiki, es una ingeniería completamente mundana. Además de la facilidad de uso, una gran ventaja en dicha codificación es simplificar y promover la recolección de fechas, que podría usarse para crear una base de datos de eventos para responder preguntas como "¿En qué mes hay más naufragios en el Pacífico Norte?" "¿Qué sucedió en el condado de Harney, Oregón, en 1894?" "¿Cuál fue el evento notable posterior a la muerte de Abraham Lincoln?" — EncMstr ( discusión ) 05:55, 4 de abril de 2009 (UTC) [ responder ]
  132. Apoyo , con algunas salvedades: (a) Un lector no registrado debe ver un conjunto de fechas con formato consistente dentro de cualquier artículo, por cualquier medio que sea posible (etiquetar cada artículo automáticamente para la variedad de inglés de EE. UU./Reino Unido y hacer una asignación aleatoria donde no haya pistas discernibles por bots? O algo basado en la dirección IP del usuario, por continente? O... ?). Veo el peligro de que debido a que todos los editores probablemente hemos establecido nuestras preferencias de fecha, no llegamos a ver el desastre potencial que la mayoría de los lectores ven. (b) (pequeño problema secundario) Una prioridad máxima debe ser evitar y corregir cualquier uso de fechas ambiguas como 3-4-2009 o 3/4/2009 (¿ayer o el mes pasado?). (c) La entrada requerida de los editores debe ser mínima en pulsaciones de teclas y fácil de recordar, y/o un bot debe ser capaz de detectar fechas para formatear (sugiero que una etiqueta de "no formatear" para cualquier fecha mencionada en una cita o título de una obra sería útil). Pero en general, dado que los dos formatos de fecha tienen tanto soporte como las ortografías honor/honour etc., apoyo el formato de fecha si se puede satisfacer lo anterior. PamD ( discusión ) 10:33, 4 de abril de 2009 (UTC) [ responder ]
  133. Soporte : para mí, esta es una característica de sentido común que una enciclopedia en línea debería soportar, y la complejidad adicional requerida no es tanta; si la complejidad hubiera sido una preocupación desde el principio, WP nunca se hubiera creado. Time3000 ( discusión ) 10:48, 4 de abril de 2009 (UTC) [ responder ]
  134. Apoyo ; prefiero la idea de uniformidad. tsjackso ( discusión ) 14:52 4 abr 2009 (UTC) [ responder ]
  135. Soporte ; Si se puede encontrar una discusión, entonces habrá una discusión. No puedes mantener a todos contentos a menos que les des lo que prefieren. Aunque parezca trivial, se han producido discusiones por menos motivos. Si el formato automático puede dar a la gente su propio formato de fecha preferido, entonces todo es bueno. El sistema actual funciona y sólo está siendo desaprobado por los editores que buscan encontrar algo incorrecto y luego discutir al respecto. La naturaleza humana en su máxima expresión. Por lo tanto, en mi opinión, el formato automático es el camino a seguir utilizando el sistema actual, que es fácil de lograr, fácil de recordar cómo hacerlo sin ningún formato de plantilla arcano que recordar. ¡Lo fácil es bueno, lo fácil es menos propenso a errores y lo mejor de todo es que lo fácil es una gran manera de enojar a la gente que sólo quiere complicarse la vida por el mero hecho de hacerlo! -- Web H amster 15:56, 4 de abril de 2009 (UTC) [ responder ]
  136. Soporte ; De esta manera, tanto la globalización como la localización se hacen más fáciles. Existe una ambigüedad genuina en DMY o YMD, por ejemplo, mi cumpleaños 12/04/72. En los artículos con mucha colaboración, especialmente en las referencias, las fechas NO suelen ser coherentes dentro del artículo, incluso ahora. Dejemos que la máquina haga el trabajo estúpido. Además, el hecho de que exista la función no significa que deba hacerse obligatoria, al igual que no es obligatorio vincular o poner algo en secciones. SimonTrew ( discusión ) 19:56, 4 de abril de 2009 (UTC) [ responder ]
  137. Soporte en la fecha actual de 05/02/09 o 02/05/09. Principalmente porque todos los angloparlantes reconocen que ambas son patentemente falsas, si este fuera el caso no habría la mitad de los problemas de fecha de MOS y las guerras de reversión de fecha. Khu kri 23:32, 4 de abril de 2009 (UTC) [ responder ]
  138. Soporte . Sería bueno tener esta función disponible. Si no te gusta, entonces no la uses. --catslash ( discusión ) 23:43 4 abr 2009 (UTC) [ responder ]
  139. Soporte . La coherencia, especialmente dentro de un artículo, sería una gran ayuda para la legibilidad y reduciría la molesta tarea de asegurarse de que las fechas sean coherentes internamente con el resto del artículo existente. La incoherencia en el formato de las fechas en varios artículos es una molestia, sin duda, aunque no un impedimento. Preocuparse por todas las fechas existentes dentro de los artículos es una pista falsa; no hay necesidad de salir y arreglarlas todas, aunque sospecho que se podría escribir un robot que lo hiciera. -- btphelps ( discusión ) ( contribuciones ) 01:17, 5 de abril de 2009 (UTC) [ responder ]
  140. Soporte . Tiene sentido poder identificar fechas como tales sin tener que vincularlas, y la capacidad de modificar formatos según el usuario es una ventaja. Igenlode ( discusión ) 02:17 5 abr 2009 (UTC) [ responder ]
  141. Soporte . a) El autoformateo debería estar disponible como una funcionalidad separada e independiente de la vinculación de fechas. b) Tal vez "todos los angloparlantes reconocen ambos" cuando no es ambiguo , pero "reconocer ambos" no es ni la cuestión ni el problema. El problema es la ambigüedad. c) Dejemos que la máquina haga el trabajo. d) Si está disponible, su uso es opcional (no obligatorio). Si no está disponible... e) Háganlo lo más simple posible. f) etc. Pdfpdf ( discusión ) 06:52, 5 abril 2009 (UTC) [ responder ]
  142. Apoyo Por lo anterior, me resulta más fácil y rápido ver las fechas en un formato al que estoy acostumbrado Brian | (Discusión) 08:01, 5 de abril de 2009 (UTC) [ responder ]
  143. Sería bueno que se admitiera el marcado para fines de metadatos, y también podríamos tener formato automático para los lectores que lo hayan solicitado específicamente . La sintaxis {{date|...}} no sería tan difícil de entender, y podrías encontrar documentación en Template:Date. En los artículos, la sintaxis especial que utiliza almohadillas o corchetes sería más un misterio. JonH ( discusión ) 09:01, 5 abril 2009 (UTC) [ responder ]
  144. Apoyo . Definitivamente lo apoyaré en principio y los métodos más nuevos para el formato de fecha están en camino. Nja 247 21:11, 5 de abril de 2009 (UTC) [ responder ]
  145. El soporte ofrece al usuario opciones y consistencia. -- Boson ( discusión ) 21:32 5 abr 2009 (UTC) [ responder ]
  146. Soporte Da coherencia a toda la wiki. Hohohob ( discusión ) 00:02 6 abr 2009 (UTC) [ responder ]
  147. El apoyo #90 plantea argumentos convincentes Captndelta ( discusión ) 00:57 6 abr 2009 (UTC) [ responder ]
  148. Soporte Resolvería automáticamente una de las discrepancias entre los diferentes tipos de inglés para los artículos: simplemente elija el formato que prefiera y Wikipedia lo mostrará automáticamente. Me encanta esta idea y creo que tiene potencial para expandirse a otras áreas del inglés también. Suicup ( discusión ) 06:19, 6 de abril de 2009 (UTC) [ responder ]
  149. Soporte Aquí hay dos cuestiones distintas. Una es cómo se ve la fecha para el lector y la otra es cómo se formatea realmente la fecha en el artículo. Mientras haya coherencia en la forma en que se formatea realmente una fecha, el problema de cómo se ve la fecha para el lector es fácil de implementar. Estoy totalmente a favor de dar al lector opciones adicionales si el costo es bajo. Phil_burnstein ( discusión ) 09:31, 6 abril 2009 (UTC) [ responder ]
  150. Soporte -- Siempre me molesta que la sintaxis ~~~~ no se autoformatee, ya que hace más difícil mantener las fechas y horas sincronizadas visualmente con el historial. Por eso siempre utilicé el formato UTC y aaaa-mm-dd en mis preferencias. -- William Allen Simpson ( discusión ) 14:17 6 abr 2009 (UTC) [ responder ]
  151. Soporte débil : Apoyo el concepto de formato automático de fechas por la única razón de su "capacidad mejorada para presentar un formato de fecha consistente" en los artículos.
    1. Mi apoyo se vería reforzado si la incorporación de esta capacidad se combinara con un cambio en MOSNUM que requiriera el uso de una función (por ejemplo, {{#formatdate}) para formatear fechas.
    2. Mi apoyo no fue influenciado por estos argumentos:
      1. (a favor) ... los beneficios son obvios . Este es solo un resumen de los tres puntos a favor; además, consideré que el concepto merecía una reflexión antes de decidir, por lo que no me resultó obvio.
      2. (en contra) "No hay ningún problema que resolver". Si bien estoy de acuerdo en que el problema que se plantea en este argumento, "si el día o el mes vienen primero (3 de enero; 3 de enero)", no es importante, no estoy de acuerdo en que no haya problemas que resolver. Por el contrario, creo que la falta de coherencia enciclopédica es un problema, y ​​que la falta de coherencia del formato de fecha en toda la enciclopedia es una parte del problema de coherencia general.
      3. (en contra) ... dos clases de usuarios . Creo que esta preocupación, tal como se describe, no es un problema porque un usuario individual, durante cualquier sesión determinada, esté conectado o no, vería un estilo de fecha consistente
      4. (en contra) Falacia de metadatos . No veo que este argumento se presente en las declaraciones a favor del concepto, aunque se hace referencia a él en algunos de los comentarios de quienes votaron.
      5. (en contra) de los riesgos del desarrollo , sólo porque este argumento es un subconjunto del argumento complejo y laborioso , con el que estoy de acuerdo, a continuación.
    3. Mi apoyo se vio debilitado por estos argumentos:
      1. (a favor) ... dar a los usuarios más opciones . En mi opinión, menos opciones en términos de formato de datos y más coherencia en el estilo de fecha en los artículos (es decir, en toda la enciclopedia) es una adición necesaria a la mera adición de la funcionalidad (según entiendo, a especificar). Agregar la funcionalidad sin un cambio en MOSNUM cambiaría por un apoyo débil a la oposición.
      2. (en contra) Complejo y laborioso . Lo que más me influyó en este sentido fue la declaración a la que se hace referencia del director de tecnología de WikiMedia
        : 4wajzkd02 ( discusión ) 18:38, 6 de abril de 2009 (UTC) [ responder ]
  152. Apoyo Permitir a los usuarios elegir su idioma. Quiero leer Wikipedia en un estilo lo más parecido posible a mi inglés nativo y reducir al máximo las intrusiones discordantes del estilo y la práctica estadounidenses. Cyclopaedic ( discusión ) 19:29 6 abr 2009 (UTC) [ responder ]
  153. (a favor) Este es un aspecto importante para la interoperabilidad en el futuro. Crossbottle ( discusión ) 22:48 6 abr 2009 (UTC) [ responder ]
  154. Soporte . Tanto la coherencia como la elección del usuario son importantes. No hay ninguna razón técnica por la que las preferencias de formato de fecha y otras preferencias de usuario de naturaleza similar deban restringirse a los usuarios registrados; un simple truco de JS podría permitir que incluso los usuarios no registrados elijan su formato de fecha preferido configurando una cookie de sesión. 121a0012 ( discusión ) 02:58, 7 de abril de 2009 (UTC) [ responder ]
  155. Soporte . El formato automático ayudaría a eliminar los problemas de coherencia que afectan a muchos artículos actuales. También sería bueno permitir a los usuarios dar formato como prefieran para su comodidad. Brian Powell ( discusión ) 03:35, 7 abril 2009 (UTC) [ responder ]
  156. Soporte Permite al lector determinar cómo le gustaría que se vean sus fechas y asegura que no se confunda con otros estilos. Y como cada uno puede elegir su propio estilo, debería reducir las guerras de edición sobre las fechas en los artículos. -- Falcorian  (discusión) 05:50 7 abr 2009 (UTC) [ responder ]
  157. El soporte agrega coherencia, ya que todos los usuarios ven su formato preferido. Cualquier dolor inicial causado por la implementación se verá enormemente aliviado por los beneficios a largo plazo que traerá. Scrxisi ( discusión ) 12:31, 7 abril 2009 (UTC) [ responder ]
  158. Soporte Mejora definitiva en la experiencia general del usuario, y esto ni siquiera necesita un hack de JS o MediaWiki para implementarse (aunque podrían hacerlo más fluido). Una plantilla, algunas clases CSS y la #timefunción de analizador ya existente serían suficientes para lograrlo. Carolina wren ( discusión ) 16:38 7 abr 2009 (UTC) [ responder ]
  159. Wikipedia es una aplicación web enriquecida. Tener una opción para el formato de fecha definido por el usuario en una aplicación web enriquecida es una obviedad.
  160. Apoyo a los puntos 149 y 90. (Sí, lo he pensado yo mismo, pero otras personas escriben argumentos mejor que yo.) ~ usuario:orngjce223 ¿Cómo estoy escribiendo? 20:06, 7 de abril de 2009 (UTC) [ responder ]
  161. Apoyo - No me interesa mucho este debate, pero no tengo ningún problema con el concepto general del formato automático. Los beneficios parecen bastante obvios, los costos mucho menos. Robofish ( discusión ) 23:47 7 abr 2009 (UTC) [ responder ]
  162. Soporte . El formato automático es una forma eficaz de localizar fechas en un formato con el que el usuario esté más familiarizado y evitaría inconsistencias en los formatos de fecha en los distintos artículos. NTP ( discusión ) 04:23 8 abr 2009 (UTC) [ responder ]
  163. Apoyo . Hay demasiada inconsistencia en Wikipedia. Apoyo cualquier medida que aumente la coherencia entre los artículos. ... Misty Willows  talk 08:09, 8 de abril de 2009 (UTC) [ responder ]
  164. Soporte Me gustaría ver un formato consistente de fechas, pero como los distintos usuarios tienen diferentes preferencias, se requiere algún tipo de formato automático. -- MightyWarrior ( discusión ) 11:44 8 abr 2009 (UTC) [ responder ]
  165. Apoyo porque creo que será más fácil tener esta característica que acordar un formato común para las fechas; y sin un formato común acordado, los artículos comienzan a verse desordenados e inconsistentes. Y rew D alby 12:41, 8 de abril de 2009 (UTC) [ responder ]
  166. Apoyo Esto debería resolver todos los problemas razonables. Hipocrite ( discusión ) 14:06 8 abr 2009 (UTC) [ responder ]
  167. Soporte . Esto, además de permitir que cada usuario elija el formato de fecha, también les da la opción de vincular fechas o no. Esto debería complacer a los usuarios registrados, y el verdadero debate debería ser sobre la vinculación automática para usuarios no registrados. (Supongo que el formato de fecha se elegiría en función del país de origen del usuario y, por lo tanto, no es necesario debatirlo). — Comentario anterior sin firmar agregado por Psbsub ( discusióncontribs )
  168. Soporte . ¡Solo para poder obtener formatos de fecha que no sean de Norteamérica! Wikipeterproject ( discusión ) 21:18 8 abr 2009 (UTC) [ responder ]
  169. Apoyo ; aunque como editor no me importa mucho una cosa ni la otra, como lector es simplemente más fácil y accesible ver las fechas presentadas de manera consistente en el formato al que estoy acostumbrado. EyeSerene talk 09:49, 9 de abril de 2009 (UTC) [ responder ]
  170. Apoyo . El hecho mismo de que haya gente que prefiera formatos de fecha no norteamericanos (como Wikipeterproject) me obliga a votar de esta manera. Para mí, cualquier cosa que no sea "9 de abril de 2009" parece rara y fea. Y estoy seguro de que muchos estadounidenses lo ven de la misma manera. Sin embargo, creo que no tenemos por qué dominar las cosas, por lo que el formato automático debería permitirme ver "9 de abril de 2009", mientras que estos otros verían "9 de abril de 2009" o "2009-04-09". No entiendo por qué alguien se opone a ello. -- BRG ( discusión ) 13:45 9 abr 2009 (UTC) [ responder ]
  171. Apoyo . Aunque soy relativamente nuevo en Wikipedia (habiendo dejado el lugar en 2006 por razones en su mayoría irrelevantes para la discusión aquí antes de volver a unirme recientemente), creo que necesito dar mi opinión al respecto. Dicho esto, y habiendo leído tanto las declaraciones a favor como en contra, creo que las declaraciones a favor tienen más sentido. En primer lugar, no estoy de acuerdo en que estemos tratando de resolver un problema inexistente aquí. La coherencia del formato es una parte importante e integral de cada publicación, y el uso de un formato inconsistente y de estándares dobles refleja falta de profesionalismo. Sí, es un poco injusto que los usuarios no registrados no puedan elegir el formato de fecha que quieran usar, pero esto se contrarresta con el hecho de que al menos podrán ver un formato de fecha consistente en cada artículo. ¿Laborioso y complejo? ¡Pensé que para eso estaban los bots! Y la búsqueda de Google restringida por Wikipedia está infrautilizada por una buena razón: es una chapuza . ¿Por qué no podemos usar nuestro propio motor de búsqueda, en lugar de tener que depender de un motor de búsqueda externo? Los riesgos de desarrollo son un problema real, pero creo que, a menos que no tengamos la previsión necesaria para solucionarlos antes de implementar esta solución, no debería ser un problema demasiado grave. -- AKR ( discusión ) 16:14 9 abr 2009 (UTC) [ responder ]
  172. Soporte . Muchas personas tienen diferentes formatos de fecha, por lo que {{#formatdate}}realmente puedo ayudar. Aparte de eso, dado que la encuesta a continuación (en la página Wikipedia:Encuesta sobre formato y vinculación de fechas) tiene una mayoría que está de acuerdo en que solo se vinculan las fechas necesarias, si no aprobamos esto, las fechas no se formatearán automáticamente. ¡Por lo tanto, apoyo la aprobación de este formato automático! Math Cool 10 ¡Firma aquí! 18:52, 9 de abril de 2009 (UTC) [ responder ]
  173. Apoyo : una estandarización que vale la pena, pero que conserva la libertad de elección de cada persona. Finavon ( discusión ) 18:55 9 abr 2009 (UTC) [ responder ]
  174. Sería una gran mejora contar con un formato de fecha optimizado en todos los ámbitos.Drunauthorized 22:46, 9 de abril de 2009 (UTC)
  175. La uniformidad de las fechas en toda Wikipedia sería una pequeña, pero necesaria, mejora en el profesionalismo del sitio web. Sean118 ( discusión ) 00:03 10 abr 2009 (UTC) [ responder ]
  176. El soporte para el formato automático evita las guerras de edición entre mentes diminutas. Hay usuarios que piensan que las fechas con formato de enlace actuales son un regalo de Dios y que eliminar todo el formato automático probablemente los molestará mucho. Cstaffa ( discusión ) 00:06 10 abr 2009 (UTC) [ responder ]
  177. Soporte - La opción de elegir cómo se muestran las fechas es importante. Seguro, los usuarios de ambos sistemas pueden reconocerse mutuamente, pero ¿por qué deberían hacerlo? Facilita todo y evita guerras de edición. -- Alinnisawest , Dalek Empress ( solicitudes de exterminio aquí ) 03:05, 10 de abril de 2009 (UTC) [ responder ]
  178. Soporte -- Michael ( discusión ) 04:21 10 abr 2009 (UTC) [ responder ]
  179. Soporte - Tener fechas en diferentes formatos es confuso. -- Pot ( discusión ) 04:45 10 abr 2009 (UTC) [ responder ]
  180. Soporte - La confusión en los formatos de fecha es algo común en el mundo real. No lo hagamos más grave. Tarlneustaedter ( discusión ) 05:03 10 abr 2009 (UTC) [ responder ]
  181. Soporte . Para los lectores, Wikipedia parece amateur debido a la inconsistencia actual en los formatos de fecha en los distintos artículos (y a menudo incluso dentro de ellos). Especialmente las fechas ISO "en bruto" ("2008-05-12") que observo durante los últimos meses en las referencias que utilizan las plantillas de citación (por ejemplo, en Pearl_Jam_discography#References , ¡eso es incluso una lista destacada !). En mi opinión, el formato automático de fechas es la única manera de salir de este limbo. Para los lectores de IP, estoy convencido de que se puede encontrar una solución técnica que muestre "14 de enero de 2006" para las IP de América del Norte y "14 de enero de 2006" para las IP de otros lugares. Para los editores , el sistema tiene que ser simple de usar y fácil de entender para los novatos mirando los ejemplos existentes. Mi preferencia sería un sistema de plantillas simple basado en el estándar ISO , por ejemplo {{date:2006-01-14}} para la fecha anterior, {{date:2006-01}} para enero de 2006, o simplemente {{date:2006}} para 2006. Los intervalos podrían ser {{date:2006-01-14/2006-01-22}} para el 14-22 de enero de 2006. Etc. Si este sistema puede funcionar para otros (y puede, de lo contrario no sería ISO), ¡también puede funcionar para nosotros! – IbLeo ( discusión ) 05:09 10 abr 2009 (UTC) [ responder ]
  182. Soporte - La coherencia es valiosa. Esto (con el tiempo) ayudará. Ingolfson ( discusión ) 09:44, 10 de abril de 2009 (UTC) [ responder ]
  183. Soporte : lo más importante es que el lector comprenda fácilmente la fecha y que sea coherente en todos los artículos. Dar formato a la fecha local del usuario parece ser la decisión correcta en este caso. De todos modos, vincular y desvincular fechas ha sido una tontería. Muchos defensores de las fechas vinculadas solo buscaban cierta coherencia en la forma en que se expresan las fechas. Vincular a una lista de cosas que sucedieron en esa fecha nunca proporcionó mucho valor. El esfuerzo involucrado en hacer que esto funcione no es insignificante, pero parece un trabajo ideal para un BOT. --RadioFan (discusión) 12:05, 10 de abril de 2009 (UTC) [ responder ]
  184. Apoyo - Wikipedia debería ser genuinamente internacional. Si cualquier otro país que no sea Estados Unidos hubiera adoptado un formato de fecha diferente, ni siquiera estaríamos teniendo este debate. Sin embargo, dada la preponderancia de los editores estadounidenses, no es descabellado darles un hueso y dejar que formatee las fechas como les parezca mientras el resto del mundo sigue con su trabajo. AngoraFish 木13:54, 10 de abril de 2009 (UTC) [ responder ]
  185. Apoyo si la sintaxis es simple; también, considere algo (por ejemplo, un pequeño punto en superíndice) para asegurarle al lector que está viendo una fecha con formato automático y no solo texto literal que podría confundir. Pero mi apoyo desaparece si de alguna manera conduce de nuevo a esa horrible sobrevinculación de años, fechas, etc. EEng ( discusión ) 19:03, 10 de abril de 2009 (UTC) [ responder ]
  186. Los enlaces irrelevantes sólo distraen de aquellos que son verdaderamente valiosos para el lector. -- droll  [chat] 22:38, 10 de abril de 2009 (UTC) [ responder ]
  187. El costo adicional parece menor y permite a los lectores ver las fechas de manera consistente. Además, considere que puede llegar el día en que el formato "11 de marzo de 2009" parezca terriblemente pasado de moda y todos querremos que se actualicen esas instancias individuales. Es mejor automatizarlo ahora, mientras Wikipedia aún es pequeña. Spiel496 ( discusión ) 01:29 11 abr 2009 (UTC) [ responder ]
  188. Soporte Esto mejorará la coherencia y mostrará las fechas según las preferencias del usuario. Pero, ¿eliminará miles de errores de puntuación, como la omisión de la coma final de "9 de septiembre de 1974", donde "1974" es esencialmente un apositivo que debe separarse con comas a ambos lados? Martindelaware ( discusión ) 06:29 11 abr 2009 (UTC) [ responder ]
  189. Apoyo para hacer las cosas más fáciles y consistentes para los lectores. -- Auntof6 ( discusión ) 07:08 11 abr 2009 (UTC) [ responder ]
  190. Apoyo por parte del usuario Ckatz y el argumento sobre los metadatos (el más importante, en mi opinión). También debería ser obligatorio utilizar fechas gregorianas ISO 8601 (prolépticas) como parámetro de entrada para #formatdate, ya que se trata de la norma internacional que casi todos los países han adoptado (incluso los EE. UU. y la UE). Nsaa ( discusión ) 10:27 11 abr 2009 (UTC) [ responder ]
  191. El soporte como fecha y hora es común a todas las áreas temáticas, y la estandarización es una extensión lógica de esto. -- Gavin Collins ( discusión | contribuciones) 10:43 11 abr 2009 (UTC) [ responder ]
  192. Soporte . ¿Por qué permitir que un editor establezca una "fecha y preferencia" en su perfil y luego ignorarla? MeegsC | Discusión 11:58, 11 de abril de 2009 (UTC) [ responder ]
  193. Apoyo . El día que alguien decidió que esa fecha debía desvincularse fue el día en que alguien le creó un gran dolor de cabeza a WPTC. Todavía no podemos decidir porque nuestros artículos cubren los océanos, no la tierra. Potapych ( discusión ) 12:34 11 abr 2009 (UTC) [ responder ]
  194. Soporte , permite la elección personal con problemas mínimos. (No, "No puedo leer el wikitexto" no es una queja válida, ya que ya es ilegible gracias a la omnipresencia de plantillas de citas y funciones de análisis.) Tito xd ( ?!? - cosas interesantes ) 18:19, 11 de abril de 2009 (UTC) [ responder ]
  195. Apoyo Como lector, me gusta.-- Fabrictramp | háblame 23:17, 11 de abril de 2009 (UTC) [ responder ]
  196. Fuerte apoyo . Por IbLeo (#182)-- EMU CPA ( discusión ) 02:21, 12 de abril de 2009 (UTC) [ responder ]
  197. Apoyaremos esta opción siempre que sea opcional y no tengamos robots que cambien fechas de texto simple por fechas formateadas. Dejemos que el consenso real, a través de la edición humana normal, decida si esto es útil o no. DHowell ( discusión ) 04:11, 12 de abril de 2009 (UTC) [ responder ]
  198. Admite una función útil para mejorar la usabilidad internacional JulesH ( discusión ) 11:02 12 abril 2009 (UTC) [ responder ]
  199. Se podría hacer de forma gradual y opcional (como { { ipa | } } ), y ayudaría a resolver los otros dos problemas mencionados. — Jch thys 14:34, 12 de abril de 2009 (UTC) [ responder ]
  200. Soporte No es necesario ejecutar ningún bot, pero como se dijo anteriormente, deje que esto se desarrolle naturalmente. La opción es importante porque, como editor de paso, uno no quiere preocuparse por formatear las fechas de la manera correcta (¿Es este un artículo estadounidense o inglés?). El formato automático funcionará bien Agathoclea ( discusión ) 14:38, 12 de abril de 2009 (UTC) [ responder ]
  201. Soporte - El autoformato tiene potencial, sin duda. Me gustaría ver más opciones, como que los usuarios que no hayan iniciado sesión puedan establecer algún tipo de preferencia, para aprovechar aún más la naturaleza electrónica de Wikipedia. Es bueno que ya no se requieran enlaces para el autoformato, y aún existe la posibilidad de permitir que los robots hagan la mayor parte del trabajo, aunque podría desarrollarse lentamente con el tiempo mediante la edición humana. Creo que la coherencia en los artículos sería útil, como ocurre con otras enciclopedias, y aunque tal vez debería ser trivial, esto claramente es importante para más de unas pocas personas. Camaron | Chris (discusión) 14:40, 12 de abril de 2009 (UTC) [ responder ]
  202. Fuerte apoyo Wikipedia no es una enciclopedia WP:PAPER , y los editores a quienes no les importe o no sepan cómo formatear las fechas pueden dejarlo en manos de los editores que sí puedan. La simantización (si es que existe esa palabra) de los artículos es algo bueno. --  M2Ys4U ( discusión ) 15:33 12 abr 2009 (UTC) [ responder ]
  203. Fuerte apoyo Tiene sentido apoyar el formato más popular -- Thelostlibertine ( discusión ) 18:01 12 abr 2009 (UTC) [ responder ]
  204. Apoyo . Creo que sería bueno que se vincularan fechas, ya que ayudarían a evitar conflictos, como cuando los ciclones tropicales transfieren cuencas, lo que causa dolores de cabeza a los miembros del WPTC. También creo que si se supone que debemos vincular a "artículos relevantes", ¿por qué no deberíamos vincular a los artículos de fecha? Jason Rees ( discusión ) 23:32, 12 de abril de 2009 (UTC) [ responder ]
  205. Soporte . El formato de fecha permite al lector comprender rápidamente las fechas, y cada uno tiene sus preferencias (yo configuré la mía hace un tiempo). Para los usuarios no registrados, sería una quimera combinar eventualmente el formato automático con la configuración regional del sistema operativo o del navegador (si se puede acceder desde el servidor web) o inferir el país donde se origina el dominio de la dirección IP (usando algún tipo de base de datos GeoIP). + m t 00:56, 13 de abril de 2009 (UTC) [ responder ]
  206. El soporte como la mejor solución a las inconsistencias de artículos relacionados, las guerras de edición y los bloqueos de políticas que resultan sin él (por ejemplo, la situación WP:WPTC mencionada anteriormente , sin mencionar la incapacidad histórica para lograr consenso con propuestas de formato de fecha como esta ). El formato automático proporciona una capacidad superior para adaptar y distribuir el contenido de Wikipedia en un entorno global. Las diferencias de formato de fecha conllevan problemas de sesgo sistémico, por ejemplo, MDY conlleva un sesgo sistémico particularmente estadounidense que, si se aplicara a muchos artículos, reflejaría mal a Wikipedia como un proyecto global (y eso es WP:NPOV ). También algunos formatos de fecha utilizados en la práctica ( ISO 8601 , YMD) están excluidos por la política, pero podrían recuperarse con el formato automático. La mayor parte de la capacidad ya está implementada en Wikimedia: es una fruta madura en términos de i18n y L10n que debería limpiarse para rangos de fechas y usuarios no registrados, luego deberíamos avanzar y una vez más hacer un buen uso de ella. Dl2000 ( discusión ) 01:18 13 abr 2009 (UTC) [ responder ]
  207. Soporte - Definitivamente me gusta la idea de que el sistema (finalmente) formatee las fechas según mis preferencias, en lugar de cualquier formato que le guste al autor. Personalmente, prefiero "AAAA-MM-DD", ya que es a lo que estoy acostumbrado por la programación informática. La otra forma en que me gusta ver las fechas es "DDDD, MMMM D, AAAA". La idea de poder cambiar las fechas de esa manera (algo que las computadoras pueden hacer fácilmente) es muy agradable. Siempre he odiado usar el marcado wiki como un truco para que eso funcione, así que tendía a no hacerlo. Pero una vez que esto se apruebe y podamos comenzar a formatear las fechas automáticamente, será maravilloso. Debería ser lo más automático y transparente posible para el usuario. Idealmente, no se requieren etiquetas especiales. Si una fecha está en el artículo y se reconoce como una fecha, el software debería adaptarla. Si hay algo que no es una fecha pero se reconoce como tal, debería haber una etiqueta simple (nowiki quizás, ¿porque es familiar y tiene un propósito similar?) que evitaría los falsos positivos. -- Will scrlt  ( →“¡¿Hablar?!” ) 14:06, 13 de abril de 2009 (UTC) [ responder ]
  208. Los lectores que se preocupan lo suficiente como para establecer una preferencia por el formato de fecha deberían poder ver las fechas mostradas de manera consistente de esa manera. Los lectores que no se preocupan lo suficiente como para establecer una preferencia simplemente no les importa, y los editores antiformato tampoco deberían preocuparse por ellos; al menos esos lectores las verían en un formato consistente que les da una apariencia profesional. Chris the speller ( discusión ) 14:10 13 abr 2009 (UTC) [ responder ]
  209. Soporte . Esto mejora la apariencia de la enciclopedia, al brindar la opción para que los usuarios (registrados) vean su contenido en el formato más apropiado para sus necesidades. Aunque los usuarios no registrados no pueden hacer esto a través de una configuración de preferencias, podría ser posible implementar una cookie de localización, o algo similar, que les ofrezca la misma opción. Para el usuario no registrado ocasional (de los cuales hay muchos), al formatear automáticamente, podríamos definir un estado predeterminado para cada artículo, de modo que las guerras de edición pudieran limitarse a una plantilla de localización que establezca el formato de fecha predeterminado (y tal vez otras convenciones de estilo) para todo el artículo. Con eso, todavía hay un beneficio neto para todos los usuarios en términos de consistencia de formato, aunque solo algunos usuarios serían conscientes del beneficio adicional de establecer su propio formato preferido. Reconozco que podría haber una penalización de rendimiento debido al análisis de fechas, pero habiendo implementado el análisis de fechas en otras plataformas, no puedo ver esto como una desventaja desproporcionada, computacionalmente. Además, aunque no estoy familiarizado con la implementación de MediaWiki, parece razonablemente simple almacenar en caché estos resultados computacionales de una manera que limite la penalización. Básicamente, a menos que el backend de MediaWiki sea un desastre, dudo que haya pérdidas significativas de rendimiento, en comparación con la carga regular de páginas y la evaluación de plantillas. Finalmente, cualquier buena implementación debe evitar la vinculación obligatoria de la fecha (que parece ser la intención de la pregunta de la encuesta), pero por la misma razón, la sintaxis elegida no debe evitar la vinculación de la fecha, cuando sea apropiado. TheFeds 16:23, 13 de abril de 2009 (UTC) [ responder ]
Me opongo al concepto general de formato automático.
  1. Oposición Si Brion piensa que se debe eliminar el formato automático, eso es suficiente para mí. Creo que los beneficios del formato automático no superan los problemas que su implementación causará, como etiquetar millones de fechas con un marcador para permitir el formato automático. Steve Crossin Talk / 24 23:12, 29 de marzo de 2009 (UTC) [ responder ]
  2. En contra Por todos los argumentos en contra. No necesitamos más opciones. Ninguno de los estilos de fecha aceptados es difícil de entender. Creo que deberíamos seguir alejándonos del estilo ISO y no deberíamos depender del formato automático para mantener la coherencia. La venganza de Rambo (¿Cómo lo estoy haciendo?) 23:16, 29 de marzo de 2009 (UTC) [ responder ]
  3. Oposición : Este es un software complicado, no dejes que nadie te convenza de que es pan comido. Si no han podido hacerlo bien en SEIS AÑOS, nada me hace pensar que lo harán bien en un futuro próximo. Por supuesto, Brion Vibber sabe de lo que habla. Aunque la gente diga "sin dolor no hay ganancia", esto es simplemente mucho dolor para poca ganancia. Ponerle lápiz labial a un cerdo no cambia el hecho de que es un cerdo. Ohconfucius ( discusión ) 23:21 29 mar 2009 (UTC) [ responder ]
  4. Me opongo débilmente . Si este problema surgiera ahora, lo resolveríamos permitiendo ambos formatos, siguiendo el ejemplo de WP:ENGVAR . El formato automático fue un intento fallido de solucionar técnicamente un problema de comportamiento, y enfrenta dificultades gramaticales irresolubles sobre si una coma va después de la fecha. Septentrionalis PMAnderson 23:23, 29 de marzo de 2009 (UTC) [ responder ]
  5. Oposición según PMAnderson. -- John ( discusión ) 23:34 29 mar 2009 (UTC) [ responder ]
  6. Me opongo . El análisis de Bugzilla está en general en contra. La mayoría de los usuarios pueden entender ambos formatos principales (DMY y MDY). No veo ningún sentido si no se va a adaptar, pero es probable que sea una pesadilla - y automatizarlo sería muy arriesgado, ya que el análisis de Bugzilla identifica tipos de casos en los que la adaptación automática sería incorrecta. Finalmente, si hacer que funcione requiere una plantilla o cualquier otro tipo de marcado adicional, estoy totalmente en contra - WP es tan propenso a WP:CREEP que probablemente se convertiría en un requisito de MOS en unos pocos años, y no conozco ningún mecanismo por el cual podríamos legislar ahora que MOS nunca debería exigirlo. - Philcha ( discusión ) 23:45, 29 de marzo de 2009 (UTC) [ responder ]
  7. Oposición No hay ningún "problema" que resolver. Como se ha señalado, WP:ENGVAR funciona bien para las variantes en inglés, así que ¿por qué no para las fechas? Dabomb87 ( discusión ) 23:47 29 mar 2009 (UTC) [ responder ]
  8. Oponerse . -- Donald Albury 23:53, 29 de marzo de 2009 (UTC) [ responder ]
  9. Oposición : ¿Qué problema estamos intentando resolver con esto? seicer | discusión | contribuciones 23:55, 29 de marzo de 2009 (UTC) [ responder ]
  10. Como colaborador destacado, no he encontrado ninguna razón para ello. -- Der Wohltempierte Fuchs ( discusión ) 23:57 29 mar 2009 (UTC) [ responder ]
  11. Oposición . Los argumentos a favor no son convincentes en absoluto, pero los argumentos en contra describen problemas muy reales. ¿Todas las desventajas sólo para dar a unas pocas personas la opción de mostrar un artículo con ortografía estadounidense en formato de fecha del Reino Unido o viceversa? Esto es una evidente exageración de funciones. --Hans Adler ( discusión ) 00:00, 30 de marzo de 2009 (UTC) [ responder ]
  12. Oposición : la mayoría de los usuarios de Wikipedia son lectores , no editores, por lo que la mayoría de las funciones deberían estar diseñadas para ellos. Los enlaces de fecha devalúan los enlaces útiles y también exigen un trabajo extra inútil para los editores. Awadewit ( discusión ) 00:07 30 mar 2009 (UTC) [ responder ]
  13. Oponerse al formato automático. Odio ese lío azul sin sentido de fechas superpuestas . ¿Y no es bastante extraño que se suponga que la gente de los EE. UU. y el Reino Unido se confundan con los formatos de fecha prácticamente idénticos de cada uno, cuando el resto del mundo, con su formato de fecha mucho más variable, es perfectamente capaz de entender ambos? Bishonen | discusión 00:07, 30 de marzo de 2009 (UTC). [ responder ]
  14. Oposición , no creo que sea necesario, no estoy convencido de que exista un problema que necesite esta solución. Raven1977 Háblame Mis ediciones 00:15, 30 de marzo de 2009 (UTC) [ responder ]
  15. Oposición Yo habría pensado que esto ya se había resuelto la primera, segunda y tercera vez . Ahora estamos en ello por cuarta vez. No, el formato automático no es deseable. Tampoco es necesario. Simplemente elija el formato más apropiado para el artículo (basándose en las pautas de MOSNUM ), escríbalo en un texto fijo y listo. Pasar por todos estos obstáculos sólo para que un puñado de editores se puedan ahorrar la sorpresa de ver un formato de fecha que desaprueban es algo a lo que sobrevivirán; lo garantizo. Greg L ( discusión ) 00:26 30 mar 2009 (UTC) [ responder ]
  16. Oposición . Si los lectores de Wikipedia son lo suficientemente inteligentes como para diferenciar entre "color" y "color" y entre "aluminio" y "aluminio", pueden diferenciar entre "30 de marzo" y "30 de marzo". Sobre esa base, yo aplicaría el principio KISS y evitaría la complejidad añadida. -- Tcncv ( discusión ) 00:31 30 mar 2009 (UTC) [ responder ]
  17. Oposición : no es necesario el formato automático. Como ya se ha mencionado, realza las diferencias entre los usos registrados y no registrados, enmascarando posibles inconsistencias. Todos los artículos deberían ser coherentes, utilizando WP:MOSNUM y WP:ENGVAR . — MDCollins ( discusión ) 00:36 30 mar 2009 (UTC) [ responder ]
  18. Por Tcncv. NuclearWarfare ( Discusión ) 00:46 30 mar 2009 (UTC) [ responder ]
  19. Oponerse . Que los editores vean un resultado diferente al de los lectores es una receta para el desastre. Aprecio el formato automático, es bueno tenerlo (el formato internacional es lo mejor), pero cuando me di cuenta de sus defectos, dejé de usarlo. Desde entonces, he visto una gran cantidad de artículos que son inconsistentes debido a esto. Artículos que se han corregido porque desactivé la función. La única forma en que apoyaría el formato automático es si TODOS los artículos tuvieran el MISMO resultado para los usuarios no registrados, preferiblemente fechas internacionales (DD MM AAAA) ya que nos dirigimos a un público de lectores internacional. Es decir, no etiquetar páginas individuales con palabras mágicas que especifiquen en qué formato deben mostrarse las fechas, eso es simplemente pedir que haya guerras de reversión interminables hasta el fin de los tiempos. Headbomb  { ταλκ κοντριβς  –  WP Physics } 01:24, 30 de marzo de 2009 (UTC) [ responder ]
  20. Oposición : las ventajas señaladas benefician sólo a aquellos que están conectados. Aquellos que no están conectados o no son usuarios registrados, pueden ver fechas con distintos formatos. El formato automático no promueve la coherencia; el texto real sigue siendo inconsistente (y, como se ha señalado, obvio para aquellos que no están conectados). Sin el formato automático, los editores detectarían fácilmente cualquier error de coherencia en los formatos de fecha de un artículo. Jappalang ( discusión ) 01:46, 30 de marzo de 2009 (UTC) Complemento : esto se añade en respuesta a la difusión de Sapphic a los usuarios que se han opuesto con el argumento de que "el formato automático se puede arreglar para los usuarios anónimos".[1][2] Sigue sin resolver nada; en primer lugar, nadie ha propuesto una solución viable todavía (sólo se propone). En segundo lugar, los editores no necesitan pasar por más obstáculos para simplemente introducir una fecha. Mi oposición sigue en pie. Jappalang ( discusión ) 01:19 1 abr 2009 (UTC) [ responder ]
  21. Oponerse : los lectores deberían ver lo mismo que ve un editor conectado, y no deberíamos tener que pasar por un millón de obstáculos para que eso suceda. Ealdgyth - Discusión 01:47, 30 de marzo de 2009 (UTC) [ responder ]
  22. Oponerse El sistema de autoformato vincula una fecha a un artículo sobre esa fecha, no necesariamente sobre los detalles que se identificaron en el artículo original. También los veo como una mancha azul en un artículo, que sólo sirve para confundir por completo a un recién llegado que prueba cada uno de los enlaces wiki. En cuanto a ver el formato en la fecha de preferencia, simplemente escriba el artículo para la audiencia, especialmente si el artículo trata sustancialmente sobre un tema europeo donde predomina el estándar día-mes-año o en artículos militares. Nuevamente, esta es una solución que busca un problema para resolver. FWiW Bzuk ( discusión ) 01:59, 30 de marzo de 2009 (UTC). [ responder ]
  23. Oposición : marcar millones de artículos para beneficio de unos pocos editores definitivamente no vale la pena el esfuerzo. SteveB67 ( discusión ) 02:07 30 mar 2009 (UTC) [ responder ]
  24. Juliancolton  |  Discusión 02:13, 30 marzo 2009 (UTC) [ responder ]
  25. Oposición : hay muchas razones: los costos son horrendos y los beneficios son escasos (francamente, ninguno, ya que el orden día-mes/mes-día es trivial); los riesgos de que las cosas se compliquen o de que nos quedemos con un cachorro muy maloliente son altos; esto rompe un principio básico de que la simplicidad es lo mejor (si es que es posible, y es la realidad ahora). Espero que los seguidores de WP sean cautelosos y descarten esto para siempre. Tony (discusión) 03:31 30 mar 2009 (UTC) [ responder ]
  26. Oposición : demasiados trucos. Las fechas deberían introducirse en un formato coherente en todos los artículos y los editores que hayan iniciado sesión deberían ver lo mismo que los lectores que no hayan iniciado sesión. Sssoul ( discusión ) 04:21 30 mar 2009 (UTC) [ responder ]
  27. Oponerse . Esto parece tener una prioridad menor que el formato automático de ortografía ({{#formatword|color|colour}}), y haría que los cuadros de edición fueran igual de difíciles de leer. -- Srleffler ( discusión ) 04:42, 30 de marzo de 2009 (UTC) [ responder ]
  28. OponerseChris! c t 05:01, 30 de marzo de 2009 (UTC) [ responder ]
  29. Oppose , Pmanderson lo expresa bastante bien. Fut.Perf. ☼ 05:58, 30 de marzo de 2009 (UTC) [ responder ]
  30. Oponerse Como lo señalaron los argumentos anteriores, este problema está relacionado con el modelo de servicio y el comportamiento, no con cuestiones técnicas. -- KrebMarkt 06:44, 30 de marzo de 2009 (UTC) [ responder ]
  31. Oponerse El argumento en contra resume el punto a la perfección. Esto creará un montón de trabajo para un montón de editores por muy poco beneficio. Oren0 ( discusión ) 07:12 30 mar 2009 (UTC) [ responder ]
  32. Oponerse a la mecanografía y corrección de textos adicionales que no aportan ningún beneficio real. bridies ( discusión ) 07:29 30 mar 2009 (UTC) [ responder ]
  33. En contra Estoy de acuerdo con los argumentos en contra. Dougweller ( discusión ) 08:04 30 mar 2009 (UTC) [ responder ]
  34. Oponerse . El autoformato obliga a que personas sanas tomen medicamentos en masa, sólo porque a algunas personas no les gusta estornudar. Lightmouse ( discusión ) 08:09 30 mar 2009 (UTC) [ responder ]
  35. Expansión trivial e innecesaria del ancho de banda. DrKiernan ( discusión ) 08:09 30 mar 2009 (UTC) [ responder ]
  36. Oponerse . Es completamente innecesario. Lo siguiente podría ser "cambio automático entre inglés de EE. UU. e inglés de EE. UU."-- HJensen , discusión 09:03, 30 de marzo de 2009 (UTC) [ responder ]
  37. ¿Oponerse a que se marquen todas las fechas de todos los artículos (millones de ellos) sólo para que la gente pueda elegir entre día-mes y mes-día? ¡Qué locura! Colonias Chris ( discusión ) 09:19 30 mar 2009 (UTC) [ responder ]
  38. Oponerse Sinceramente creo que esto es mucho trabajo para muy poco beneficio. dottydotdot ( discusión ) 10:03 30 mar 2009 (UTC) [ responder ]
  39. Oponerse . Tcncv  ( discusión  · contribuciones ) lo expresa de forma agradable. —  TKD :: {discusión} 11:04 30 mar 2009 (UTC) [ responder ]
  40. Oponerse . Por las mismas razones que en todas las otras ocasiones en que nos han hecho la misma pregunta. Función completamente inútil que proporciona trabajo extra y complicación para editores y desarrolladores, mientras que no aporta nada de valor para nadie (especialmente para nuestros lectores que de todos modos no la verán). También dañará a Wikipedia, ya que si los editores usan esta herramienta, no verán las fechas como las ven los lectores, y por lo tanto dejarán ciertos errores (puntuación, consistencia de formato) sin corregir. --Kotniski ( discusión ) 11:18, 30 de marzo de 2009 (UTC) [ responder ]
  41. Me opongo . Entiendo la diferencia entre autoformato y vínculo. Veo muchos problemas que surgen del autoformato. Cualquiera que haya maldecido a MS Word (como hago yo cuando uso la máquina de otra persona) debería oponerse a una extensión de nannydom. (Yo uso OpenOffice.) Peridon ( discusión ) 12:34, 30 de marzo de 2009 (UTC) [ responder ]
  42. Oponerse . Parecen ridículos, a menudo enlazan a páginas que no tienen nada que ver y devalúan enlaces importantes en artículos "difíciles". He contribuido con tres autores y no veo ningún valor en tener fechas enlazadas. Cuando descubrí Wikipedia por primera vez, hice clic en esas fechas enlazadas tontas pensando que podría encontrar información adicional sobre el tema en cuestión. Estoy seguro de que otros han hecho lo mismo. Graham Colm Talk 13:01, 30 de marzo de 2009 (UTC) [ responder ]
  43. Opóngase a que es una "solución" a un "problema" que no es serio, y que implementarlo sería simplemente añadir otra tarea interminable a Wikipedia. (Los nuevos usuarios no necesariamente sabrán cómo formatear automáticamente las fechas, por lo que tendríamos que estar constantemente limpiando lo que dejan atrás). r ʨ anaɢ  discusión / contribuciones 13:18, 30 de marzo de 2009 (UTC) [ responder ]
  44. Me opongo a que se dé trabajo extra para obtener un beneficio mínimo. -- NE2 13:37, 30 de marzo de 2009 (UTC) [ responder ]
  45. Oponerse sin repetir el razonamiento por enésima vez en otra encuesta (y teniendo en cuenta que la mayor parte del razonamiento de los partidarios es erróneo). Sandy Georgia ( Discusión ) 13:38 30 mar 2009 (UTC) [ responder ]
  46. Oposición . ¿Cuántas encuestas más vamos a realizar sobre este tema? —  Emil  J. 13:40, 30 de marzo de 2009 (UTC) [ responder ]
  47. Oposición . Lo que más importa es la coherencia interna de los artículos (como en la cuestión del idioma), y el formato automático no es necesario para este fin. Punkmorten (discusión) 13:43 30 mar 2009 (UTC) [ responder ]
  48. Oposición . Aunque no tengo una opinión firme ni informada sobre ningún tema, la idea no me parece buena. Agrega complejidad donde no es necesaria y parece inventar un problema y solucionarlo. JBarta ( discusión ) 13:51 30 mar 2009 (UTC) [ responder ]
  49. Oponerse Si se prohíbe el formato automático, los editores verán lo que ven los lectores y, por lo tanto, harán un mejor trabajo creando contenido para los lectores. El lector típico no está conectado y no tiene preferencias. Además, ambas opciones para implementar el formato automático son problemáticas. Los enlaces crean enlaces innecesarios que ocultan enlaces de valor agregado para los lectores. El uso de plantillas hará que sea más difícil para nosotros conseguir nuevos editores, ya que se convierte en una pieza más de sintaxis que deben aprender para hacer un cambio que debería ser simple. GRBerry 14:01, 30 de marzo de 2009 (UTC) [ responder ]
  50. En contra Estoy en contra de todo lo que aumente aún más las diferencias entre usuarios registrados y no registrados - Dumelow ( discusión ) 14:15 30 mar 2009 (UTC) [ responder ]
  51. Oponerse No es necesario. Entiendo ambos formatos de fecha y (¿casi?) todos los que saben leer inglés también lo hacen. Y no es exactamente difícil de entender si no estás familiarizado con uno de los formatos de fecha. Rreagan007 ( discusión ) 14:49 30 mar 2009 (UTC) [ responder ]
  52. Oponerme Me he opuesto antes y lo volveré a hacer. -- SkyWalker ( discusión ) 14:56 30 mar 2009 (UTC) [ responder ]
  53. Débil. Oposición. No veo cómo se compensan los beneficios con los recursos gastados. Tal vez se hubiera establecido algún tipo de estándar antes de que el contenido de Wikipedia se hubiera expandido tanto, pero intentar adaptarlo parece una tontería. -- The Red Pen of Doom 14:58, 30 de marzo de 2009 (UTC) [ responder ]
  54. Oponerse El quid de la cuestión es: ¿a quién va dirigida Wikipedia: al número relativamente pequeño de editores registrados o a los millones de lectores no registrados que la utilizan como enciclopedia en línea? Todos los argumentos a favor del formato automático de fechas son irrelevantes para la gran mayoría de los que leen un artículo de Wikipedia sin estar registrados. A diferencia de opciones como el texto en negrita y cursiva o los encabezados de sección, que aparecen por igual para los lectores registrados y no registrados, el marcado especial no "mejora la presentación de los artículos" para los lectores no registrados, ni ayuda en absoluto a lograr "un formato consistente en toda la publicación". De hecho, el formato automático sólo beneficia a los editores registrados y su eliminación en realidad mejora la presentación de los artículos para el lector no registrado al eliminar la distracción del molesto y confuso resaltado de fechas en azul.  JGHowes  talk 15:06, 30 de marzo de 2009 (UTC) [ responder ]
  55. Oponerse En algunos campos, por ejemplo, la historia, el formato de una fecha puede ser un elemento importante de su contenido informativo. Sin duda, una oportunidad para el autoformato no es lo mismo que el uso automático del autoformato. Pero una oportunidad para que el contenido sea cambiado por algo que no sea la decisión meditada de un editor parece intrínsecamente peligrosa para la exactitud y autenticidad de la información enciclopédica. Tal vez sería diferente si el autoformato funcionara sólo condicionalmente, por ejemplo, si se introduce una bandera especial en el wikitexto de algún artículo y se activa realmente para reflejar una decisión consciente de un editor de que los formatos de fecha no son de importancia intrínseca en este artículo. Terry0051 ( discusión ) 15:09, 30 de marzo de 2009 (UTC) [ responder ]
  56. Oponerse El esfuerzo no vale la pena, ya que, como se ha señalado, no tenemos ningún problema en reconocer y entender estas fechas independientemente del formato. No necesitamos esto más de lo que necesitamos un marcado especial para que las palabras terminen consistentemente con -or o -our, o para que terminen consistentemente con -ize o -ise (¡pero en palabras en las que el uso varía!), o para que aparezcan o no comas consecutivas, o para que las citas primarias estén delimitadas por comillas simples o dobles, según nuestras preferencias. —Largo Plazo ( discusión ) 15:08 30 mar 2009 (UTC) [ responder ]
  57. Oponerse . ¿Para quién es Wikipedia, para los lectores o para los editores? La gran mayoría de nuestros usuarios nunca editan y no están registrados. Y desde la perspectiva de un usuario no registrado, el formato automático empeora nuestros artículos, no los mejora, porque alienta a los editores a formatear sus fechas sin tener en cuenta la forma en que generalmente se formatean las fechas en el artículo en cuestión. Una simple extensión de WP:ENGVAR resuelve el problema. Pfainuk talk 15:22, 30 de marzo de 2009 (UTC) [ responder ]
  58. Me opongo a cualquier tipo de formato automático que requiera que las fechas (o páginas) tengan una sintaxis especial. Esto es una barrera de entrada para editores nuevos o inexpertos que no parece justificarse por el insignificante beneficio que proporciona a los usuarios registrados. Me sorprendería que hubiera muchos editores que no entendieran que el 2 de marzo y el 2 de marzo son la misma fecha. También me opongo al formato automático de todas las fechas de una página porque eso afectaría negativamente a las citas, que deberían tener la fecha en el formato en que se utilizó en la fuente. Karanacs ( discusión ) 15:23 30 mar 2009 (UTC) [ responder ]
  59. Oponerse No vale la pena el esfuerzo. Alan 16 discusión 15:53, 30 marzo 2009 (UTC) [ responder ]
  60. Oposición <suspiro> Felicitaciones a Ryan P y a todos los demás que han intentado mantener esto en marcha de manera civilizada, pero este tema es tedioso. El formato automático no trae beneficios y tiene desventajas. -- Dweller ( discusión ) 15:57 30 mar 2009 (UTC) [ responder ]
  61. Oponerse -- JBC3 ( discusión ) 16:04 30 mar 2009 (UTC) [ responder ]
  62. Oponerse No vale la pena el esfuerzo y reduciría la legibilidad del código fuente de la wiki. Plastikspork ( discusión ) 16:20 30 mar 2009 (UTC) [ responder ]
  63. Oposición , demasiada complejidad para la mayoría de los usuarios y cero beneficios para la gran mayoría de nuestros lectores. -- Laser brain (discusión) 16:21 30 mar 2009 (UTC) [ responder ]
  64. En contra, sinceramente no le veo el sentido: las fechas son más que legibles tal como están. Solo es ganar más trabajo para obtener un beneficio mínimo. Aunque puedo ver el interés en los foros, creo que Wikipedia debería dejar su estilo como está. Greggers ( t • c ) 16:23, 30 de marzo de 2009 (UTC) [ responder ]
  65. Oppose PMAnderson resume mis puntos de vista exactamente. -- RexxS ( discusión ) 16:37 30 mar 2009 (UTC) [ responder ]
  66. Oposición , esto parece generar más trabajo y problemas con muy pocos beneficios. Contamos con algunos programadores increíbles que pueden ayudarnos con cualquier problema percibido. Nuestros lectores merecen mejores artículos y realmente hemos dedicado mucha energía a estas discusiones y a todo el proyecto sobre este tema. -- Banj e b oi 16:50, 30 de marzo de 2009 (UTC) [ responder ]
  67. Oposición: Otros lo han dicho bien, a saber, Pfainuk, Greg L, Largo Plazo y GRBerry. Una extensión de WP:ENGVAR es aplicable al tema de los formatos de fecha, y es mucho mejor que alentar a los editores a que observen sólo sus formatos locales. No tenemos problemas para reconocer las diferentes variaciones y también podríamos formatear automáticamente las comas de serie o cualquier otra miríada de variaciones que acechan en el idioma inglés. Voto por enfocarnos en perfeccionar el contenido y tener artículos consistentes internamente, en lugar de crear montones de trabajo para permitir una preferencia exclusiva del editor que la mitad nunca se molestaría en "activar" de todos modos. Mae din \ talk 16:56, 30 de marzo de 2009 (UTC) [ responder ]
  68. Oponerse viola el principio KISS y, además, el formato automático es un enfoque excesivo para un aspecto tan menor: Todos nuestros lectores entienden perfectamente tanto MD como DM. ¿Alguna vez has visto a un niño mirar las fechas MD/DM y decir "¿qué significa eso?"? Ya se ha dedicado demasiado tiempo de la comunidad a esto. Todos tenemos mejores cosas con las que contribuir o mejorar Wikipedia. Sillyfolkboy ( discusión ) 17:06 30 mar 2009 (UTC) [ responder ]
  69. Oposición Mientras las fechas sean coherentes dentro de un artículo no hay problema con otras variaciones internacionales. OrangeDog ( discusiónediciones ) 17:19 30 mar 2009 (UTC) [ responder ]
  70. Concesión innecesaria a gente que se enoja por nada. -- Scott Mac (Doc) 17:28, 30 de marzo de 2009 (UTC) [ responder ]
  71. Oponerse al formato automático Me parece poco importante y propenso a problemas. También me opongo a que se repitan más problemas de este problema que se niega a desaparecer. Los editores "perdedores" deberían empezar a actuar como adultos y aceptar el hecho de que el consenso de la comunidad está en su contra. WhatamIdoing ( discusión ) 17:30 30 mar 2009 (UTC) [ responder ]
  72. Editar Conflicto En contra Primero señalaré la naturaleza omnisciente de los desarrolladores ( ver enlace ). Entendido esto, estoy de acuerdo con Brion en que no es necesario hacerlo y que tendemos a hacer las cosas más difíciles de lo que deben ser en WP. Veo beneficios, pero las desventajas ciertamente superan a las ventajas. hmwith τ 17:33, 30 de marzo de 2009 (UTC) [ responder ]
  73. En contra Creo que es difícil disociar el formato automático del enlace automático: actualmente, hay que crear un enlace o utilizar una función de análisis. El primero distrae cuando se ve un artículo, el segundo cuando se edita un artículo. No creo que la función merezca la pena. La sintaxis de wikitexto resultante, más sencilla, beneficiará a los nuevos editores y al rendimiento, al hacer que el código sea (ligeramente) menos complejo. RupertMillard ( Discusión ) 17:37, 30 de marzo de 2009 (UTC) [ responder ]
    Aparentemente, esto no fue lo suficientemente claro para el gusto de User:Sapphic . No quiero decir que sea técnicamente difícil tener uno sin el otro porque eso sería absurdo. Quise decir que es difícil debatir uno de forma aislada: si la única forma en que WP tendrá autoformato es con la sintaxis [[]] (autolinking o no) o {{#formatdate}}, el wikitexto resultante, feo y chapucero, es, en mi opinión, un precio demasiado alto a pagar por un beneficio muy leve. Ahora bien, si alguien quiere preguntarme sobre el autoformato con una nueva sintaxis como <<2009-04-01>>, como creo que vi en alguna parte, seré neutral, siempre y cuando los usuarios de IP vean algo agradable a la vista, ya sea adaptado a su ubicación o no. RupertMillard ( Discusión ) 08:32, 2 de abril de 2009 (UTC) [ responder ]
  74. Oponerse a lo que dicen otros. TheAE talk /sign 18:44, 30 de marzo de 2009 (UTC) [ responder ]
  75. Oponerse . Es mejor aceptar las diversidades internacionales que usar las preferencias de usuario para desdeñarlas. Uno debería acostumbrarse a ver las diferencias tal como lo haría en su estantería. Eso es parte de la experiencia de aprendizaje.
    ⋙–Ber ean–Hun ter—► ( (⊕) ) 18:49, 30 de marzo de 2009 (UTC) [ responder ]
  76. Oponerse . El formato automático, incluso si pudiera lograrse que funcionara correctamente, ofrece muy pocas ventajas, pero tiene desventajas muy significativas, como otros han señalado anteriormente. -- Malleus Fatuorum 19:16, 30 de marzo de 2009 (UTC) [ responder ]
  77. Oponerse . Liffey ( discusión ) 19:24 30 mar 2009 (UTC) [ responder ]
  78. Oponerse , solución sin problema. — Hex (❝ ?! ❞) 19:32, 30 de marzo de 2009 (UTC) [ responder ]
  79. Oponerse ... siempre lo ha hecho y siempre lo hará 21st CENTURY GREENSTUFF 20:01, 30 de marzo de 2009 (UTC) [ responder ]
  80. Oponerse . Mucho trabajo extra para todos a cambio de un beneficio insignificante para una pequeña minoría. Volvamos a mejorar la enciclopedia. — Remember the dot ( discusión ) 20:09 30 mar 2009 (UTC) [ responder ]
  81. Oppose Alohasoy ( discusión ) 20:10 30 mar 2009 (UTC) [ responder ]
  82. Oponerse Las pequeñas mejoras en la legibilidad para algunas personas que tienen problemas con los formatos de fecha no justifican el esfuerzo de formatear todas las fechas en todas partes de la enciclopedia. Incluso los estadounidenses pueden aprender a leer DD/MM/AAAA. Kellen T 20:14, 30 de marzo de 2009 (UTC) [ responder ]
    Obviamente estoy bromeando con el comentario anterior: soy estadounidense. Kellen T 09:25, 1 de abril de 2009 (UTC)[ responder ]
  83. En contra , no veo ninguna razón clara para hacer esto; simplemente no es un problema tan grande. Si se aplicara a todos, tal vez, pero sólo a los usuarios registrados... no. Anaxial ( discusión ) 20:38 30 mar 2009 (UTC) [ responder ]
    Para aclarar: el hecho de que sea posible que esto se aplique a todos significa que me opongo menos firmemente de lo que lo haría de otra manera; pero no cambia mi voto actual, porque mi primera oración anterior sigue en pie. Anaxial ( discusión ) 17:32 1 abril 2009 (UTC) [ responder ]
  84. Oposición Mientras las fechas se introduzcan en un formato coherente en cada artículo, no hay ningún problema real. WP:ENGVAR funciona bien para las variantes en inglés, las fechas deberían ser sólo una extensión de esto. CS 46 21:06, 30 de marzo de 2009 (UTC) [ responder ]
  85. Me opongo , ya que el formato automático se aplicaría sólo a la minoría de lectores que también son editores registrados. Yo apoyaría una solución técnica de formato automático que permitiera que se aplicara un formato determinado a un artículo individual (con excepciones para las fechas entre comillas y similares) para todos los lectores , pero eso no parece ser lo que se está discutiendo aquí. — Josiah Rowe ( discusióncontribuciones ) 21:12, 30 de marzo de 2009 (UTC) [ responder ]
  86. Oponerse Sólo por las variaciones en el formato no satisfará a todos. Al igual que hacemos con la ortografía, creo que se debería permitir que los artículos de EE. UU. mantengan el formato del 9 de mayo de 1957, mientras que los artículos del Reino Unido, Australia y otros países fuera de EE. UU. deberían poder usar el formato del 9 de mayo de 1957. Si podemos (o podremos) establecer nuestras preferencias como predeterminadas, y esto deja de ser un problema, entonces apoyaría. — Ched ~ (¿sí?) / © 21:18, 30 de marzo de 2009 (UTC) [ responder ]
  87. Oponerse No hay ningún problema que resolver aquí y esto creará más problemas - Ahunt ( discusión ) 22:05 30 mar 2009 (UTC) [ responder ]
  88. No veo ninguna razón para ello. Aparte de complicar innecesariamente las cosas, no veo qué se conseguiría con ello. faithless ( hablar ) 22:19, 30 de marzo de 2009 (UTC) [ responder ]
  89. Oposición . Mucho trabajo inútil para ningún beneficio importante. Wildhartlivie ( discusión ) 22:33 30 mar 2009 (UTC) [ responder ]
  90. Oposición - ¡Uf! ¿Otra RFC? ¿Cuántas veces vamos a pasar por esto? -- Pres N 23:43, 30 de marzo de 2009 (UTC) [ responder ]
  91. Oposición . No hay ninguna ambigüedad en la comprensión de los dos formatos permitidos. Es mucho esfuerzo para una cuestión puramente cosmética. Es el mismo problema que las diferencias ortográficas regionales y debería tratarse exactamente de la misma manera. -- NrDg 00:02, 31 de marzo de 2009 (UTC) [ responder ]
  92. Oposición - No hay ninguna razón por la que los lectores en general deban ver algo diferente que unos pocos usuarios conectados que tienen configuradas sus preferencias. Giants2008 ( 17-14 ) 00:12, 31 marzo 2009 (UTC) [ responder ]
  93. Oponerse , no sirve para nada en cuanto a enlaces, ya que los enlaces no llevan a ningún lugar útil, agregando enlaces azules excesivos en todas partes (por defecto, automáticamente "enlaza" el artículo ya que las fechas generalmente se repiten varias veces. También niega el propósito de formatear las fechas en los artículos, y puede ser confuso para IP y nuevos usuarios que ven una cosa en el artículo, deciden editar y ven algo totalmente diferente. Escríbalos como texto y déjelo así. -- Collectonian (discusión  · contribs ) 01:55, 31 de marzo de 2009 (UTC) [ responder ]
  94. Oponerse . El formato automático es una "solución" que busca un problema. Ni siquiera es una buena solución, ya que no puede abordar todos los formatos de fecha que se utilizan actualmente en WP; y no hay ninguna indicación de que se pueda encontrar una solución técnica para todos los problemas planteados durante el debate. Si se implementa una solución técnica, su sintaxis promete ser lo suficientemente compleja como para ponerla fuera del alcance del editor promedio. Una solución real al "problema" de la coherencia de las fechas es simplemente introducir las fechas de forma coherente, utilizando texto sin formato. Todos los demás problemas importantes simplemente desaparecen con la estrategia del "texto sin formato".  HWV258  02:07, 31 de marzo de 2009 (UTC) [ responder ]
  95. Oposición. El software de ordenador debería ser lo más sencillo posible. Si empiezas a complicarlo, siempre te meterás en problemas. VikSol 02:32, 31 de marzo de 2009 (UTC) [ responder ]
  96. Oponerse al formato automático. No hay motivos para preocuparse por esto. Hmains ( discusión ) 03:01 31 mar 2009 (UTC) [ responder ]
  97. Oponerse al formato automático. Se trata de una solución técnica que no tiene ningún problema que resolver. Tempshill ( discusión ) 03:04 31 mar 2009 (UTC) [ responder ]
  98. Oponerse : Parece una solución en busca de un problema. Hay una penalización significativa en términos de hacer que el marcado sea más complicado e intimidante para los nuevos usuarios. Mantenlo simple. Hawthorn ( discusión ) 03:09 31 mar 2009 (UTC) [ responder ]
  99. Oposición. No me importa si mi fecha está formateada de una manera u otra. Es como color contra color. Puedo leer y comprender ambos. Arcoíris de lluvia De luz Talk 03:22, 31 de marzo de 2009 (UTC) [ responder ]
  100. "Bienvenidos a Wikipedia, la enciclopedia que cualquiera puede editar". Lo que siempre me ha gustado de Wikipedia es que lo más importante que hay que aprender para contribuir es cómo crear un wikilink. La información básica, como las fechas, no debería requerir un formato más complejo que eso. Wikipedia ha desarrollado una cultura que no desalienta a los usuarios nuevos y antiguos por igual y no hay necesidad de codificar el sitio para que esté en sintonía con esa cultura excluyente. otherl left No, en serio, de otra manera... 03:33, 31 de marzo de 2009 (UTC) [ responder ]
  101. Oponerse al formato automático La vinculación de fechas no tenía ningún propósito racional y hacía perder el tiempo a escritores y editores. No quiero que vuelva. Finetooth ( discusión ) 03:47 31 mar 2009 (UTC) [ responder ]
  102. Opóngase al llamado formato automático. Es realmente innecesario y excesivamente complicado para editar el texto original que hay detrás de cada artículo. El exceso de marcado intimida a todo el mundo. Bueno, a mí me intimida. Atentamente, un amigo para todos, GeorgeLouis ( discusión ) 05:03 31 mar 2009 (UTC) [ responder ]
  103. Oponerse Simplemente demasiado trivial para que valga la pena invertir tiempo o pulsaciones de teclas por parte de editores o desarrolladores. Las fechas de texto fijo de cualquier formato son igualmente útiles para los lectores. -- Clay Collier ( discusión ) 05:05 31 mar 2009 (UTC) [ responder ]
  104. Oponerse Corríjame si me equivoco al suponer que la gran mayoría de los usuarios, es decir, todos los lectores/editores que nunca registran una cuenta, no tienen activado el formato de fecha. La utilidad es tan superficial que en realidad resulta inútil teniendo en cuenta la pequeña minoría que lo utiliza. Al principio me opuse a la desvinculación masiva cuando empezó, simplemente porque me desagradan los cambios como a cualquier otro ser humano, pero ahora, después de pensarlo un poco, creo que es una buena idea. LonelyMarble ( discusión ) 06:34 31 mar 2009 (UTC) [ responder ]
  105. Oponerse Cada pequeña complejidad añadida al marcado de wikitexto hace más difícil pretender que se trata de una enciclopedia que cualquiera puede editar. Ian Spackman ( discusión ) 07:18 31 mar 2009 (UTC) [ responder ]
  106. Oposición : No hay ningún problema que esto resuelva. Si las fechas deben estar en un formato determinado, se pueden tratar de forma similar al inglés británico frente al inglés estadounidense: se debe utilizar un formato determinado cuando sea razonable. NJGW ( discusión ) 07:54 31 mar 2009 (UTC) [ responder ]
  107. Débil Oposición : Me opondría con más fuerza si creyera que es un tema importante, pero no veo que debamos ofrecer formato automático si no es consistente en todas las fechas de la enciclopedia (incluidas las firmas), y podría permitir todo tipo de fechas en primer lugar. Sin embargo, es un tema que no tiene importancia; sería mejor que acordáramos un estilo reconocido en el MOS si solo eso fuera posible. --  WORM MЯOW  08:03, 31 de marzo de 2009 (UTC) [ responder ]
  108. Oposición Necesitamos menos enlaces en las páginas. Las fechas enlazadas obstruyen las páginas con azul, lo que reduce la legibilidad. También hacen que las páginas parezcan menos profesionales. No tenemos un sistema de formato automático enlazado para "convertir" entre la ortografía de EE. UU. y el Reino Unido, ¿por qué deberíamos tenerlo para un sistema de citas que es completamente comprensible para ambas partes? El formato automático ha sido una limitación para Wikipedia durante años y debería eliminarse lo antes posible. Arsenikk (discusión) 08:07, 31 de marzo de 2009 (UTC) [ responder ]
  109. Los usuarios no registrados no ven el autoformato, pero sí los enlaces de fecha, y parecen un caso clásico de enlaces excesivos . De hecho, durante años ni siquiera conocía la función de autoformato y me irritaban constantemente estos enlaces superfluos. Todavía me parecen poco profesionales, al igual que no enlazarías la palabra "nacido" en " Barack Obama nació en Hawai ". -- Zvika ( discusión ) 08:54, 31 de marzo de 2009 (UTC) Añadido en respuesta a un comentario de Sapphic: Aunque mi principal oposición es a los enlaces de fecha, también me opongo al autoformato que no aparece como un enlace, principalmente por las complicaciones de marcado wiki que parecen ser inevitables con este tipo de enfoque. Nuestro marcado necesita simplificación, no lo contrario. Quizás algún día , cuando tengamos un editor WYSIWYG. - Zvika ( discusión ) 13:36, 1 de abril de 2009 (UTC) [ respuesta ]
  110. Oponerse Puede crear demasiados enlaces azules en los artículos. -- JD554 ( discusión ) 11:35 31 mar 2009 (UTC) [ responder ]
  111. Aparte del problema de los enlaces, este es un proyecto enciclopédico que produce una versión de un artículo para todos. ¿Qué será lo próximo? ¿Permitir a los usuarios cambiar entre inglés americano y británico? Incluso si esa personalización fuera deseable, ciertamente no vale la pena el esfuerzo y la complicación.  Sandstein  11:44, 31 de marzo de 2009 (UTC) [ responder ]
  112. ¡Hurra! Las opciones sobre formatos de fecha son justo lo que me gustaría ver para distraerme de escribir artículos. No hay problema que resolver, déjenlo así. — Cyclonenim ( discusión · contribuciones · correo electrónico ) 11:54 31 mar 2009 (UTC) [ responder ]
  113. Oposición El formato de la fecha es un problema de ENGVAR, como la ortografía o la gramática. Un artículo debe ser coherente con todos estos aspectos. Colin ° Discusión 12:33, 31 de marzo de 2009 (UTC) [ responder ]
  114. Oponerse No hay ningún problema que solucionar, al intentar solucionar algo que está perfectamente bien, lo único que sucederá es que generaremos más problemas, por ejemplo, exceso de enlaces, problemas de desarrollo, etc. Spitfire Tally-ho! 12:54, 31 de marzo de 2009 (UTC) [ responder ]
  115. Oponerse -- Apoc2400 ( discusión ) 15:00 31 mar 2009 (UTC) [ responder ]
  116. Oponerse Me sentí enormemente aliviado cuando se suspendió el formato automático el verano pasado. Para la mayoría de los usuarios, son enlaces excesivos e inútiles que aportan muy pocos beneficios. Todo el mundo entiende lo que se quiere decir, ya sea que el formato utilizado sea "Día Mes" o "Mes Día". Mientras seamos coherentes en los artículos individuales, no hay ningún problema que solucionar. -- Jackyd101 ( discusión ) 16:00, 31 de marzo de 2009 (UTC) [ responder ]
  117. Oponerse . El hecho de que podamos hacer algo no significa que debamos hacerlo o que lo necesitemos. El formato de una fecha en un artículo no es un problema importante. Wikipedia:Manual_de_Estilo_(fechas_y_números)#Fechas cubre la situación bastante bien. La gente está bastante acostumbrada a ver el 17 de noviembre de 1956 y el 17 de noviembre de 1956, y esto no causa ningún problema. Los lectores pueden entender ambas versiones y la mayoría de la gente se encuentra con ambas versiones en la vida cotidiana y las usará. Parece totalmente inapropiado crear trabajo para la mayoría de los editores con el fin de resolver un problema que ni siquiera existe. Espero que esta sea la última encuesta que tengamos sobre este tema. Cuatro encuestas en 6 meses es demasiado. Cada vez el consenso es que esto no es necesario ni deseado. ¡Basta ya con las encuestas! SilkTork * ¡SÍ! 16:20, 31 de marzo de 2009 (UTC) [ responder ]
  118. ¿Oponerse a que se marquen todas las fechas de todos los artículos (millones de ellos) sólo para que la gente pueda elegir entre día-mes y mes-día? ¡Qué locura! WAS 4.250 ( discusión ) 16:26 31 mar 2009 (UTC) [ responder ]
  119. Oponerse a esto parece una solución en busca de un problema. Algo que creo que la gente está olvidando es que la gran mayoría de nuestros lectores no están registrados. Las personas a las que se supone que esto les proporcionará el mayor beneficio ni siquiera van a saber que está sucediendo. Déjenlo como está y dejen que una solución del tipo WP:ENGVAR se encargue de ello. Parsecboy ( discusión ) 16:30 31 mar 2009 (UTC) [ responder ]
  120. Me opongo . Estoy más convencido de que no hay ningún problema que resolver . Me preocupaba el argumento de los "metadatos", pero creo que se responde correctamente en la sección Falacia de los metadatos de la "declaración en contra". — Dominus ( discusión ) 16:32 31 mar 2009 (UTC) [ responder ]
  121. Oponerse No hay ningún problema que resolver. No creo que funcione nunca para lectores que no hayan iniciado sesión, por lo que no vale la pena hacerlo. Nunca funcionará en todas las situaciones gramaticales. -- Jc3s5h ( discusión ) 16:33 31 mar 2009 (UTC) [ responder ]
  122. Oposición No hay ningún problema que solucionar. Hay otras formas de tratar los metadatos de las fechas. Gwen Gale ( discusión ) 16:38 31 mar 2009 (UTC) [ responder ]
  123. Oponerse Esta es una solución débil que no plantea ningún problema. La mayoría de los lectores ni siquiera están conectados. Richard75 ( discusión ) 17:22 31 mar 2009 (UTC) [ responder ]
  124. Estoy de acuerdo con Richard75; no creo que esto sirva de mucho, salvo para disuadir a los nuevos editores y hacer que otros editores dediquen tiempo a realizar pequeñas modificaciones, con un efecto muy reducido. Ricardiana ( discusión ) 17:29 31 mar 2009 (UTC) [ responder ]
  125. Oposición . La mayoría de los lectores no están conectados y, de todos modos, los diferentes formatos de fecha son fáciles de entender. Además, cualquier cosa que reduzca el mar azul en los artículos es bienvenida. Esta es una solución que busca un problema. SlimVirgin discusión| contribuciones 17:30, 31 de marzo de 2009 (UTC) [ responder ]
  126. Oposición . Lo que dice la declaración en contra es que no hay ningún problema que resolver. Además, la solución es ardua para los nuevos editores y potencialmente propensa a errores. David Brooks ( discusión ) 17:40 31 mar 2009 (UTC) [ responder ]
  127. OponerseLa Izquierda 18:03 , 31 marzo 2009 (UTC) [ responder ]
  128. Oponerse : simplemente resolver problemas que no existen. Tenemos muchos problemas reales que resolver y artículos que ampliar. The Rambling Man ( discusión ) 18:10 31 mar 2009 (UTC) [ responder ]
  129. Por Steve Crossin. -- Nemo bis ( discusión ) 18:12 31 mar 2009 (UTC) [ responder ]
  130. Oponerse : parece que se trata de hacer una montaña de un grano de arena, así como de buscar una solución a un problema. En general, estoy en contra de añadir capas adicionales de complejidad (código) a cosas básicas como texto simple, lo que solo aleja a los nuevos usuarios y conduce a errores técnicos en la edición. "31 de marzo de 2009" y "31 de marzo de 2009" significan lo mismo, y nadie necesita un formato automático para obtener el mismo significado de cualquiera de los dos formatos. -- IllaZilla ( discusión ) 19:01 31 mar 2009 (UTC) [ responder ]
  131. Algunos comentarios: La plantilla:Fecha es una adición interesante a esta discusión, y me hizo pensar mucho sobre esto. He leído docenas de comentarios en estos hilos, y estoy de acuerdo en que muchas personas que se oponen parecen tener la idea equivocada de que esta subencuesta trata sobre "enlaces". Apoyo firmemente la idea de obtener metadatos, sin enlaces azules. Pero tengo un conflicto sobre el formato automático, en parte porque ¿quién decide si mdy o dmy es el valor predeterminado? y en parte porque se debe evitar una mayor complejidad del código wiki si es posible. Creo (actualmente) que el estilo/formato de nuestras fechas debe tratarse como ENGVAR (porque el mundo es diverso y actualmente lo reflejamos), como nuestras FA, como la wiki alemana (sin fechas vinculadas), y que se debe encontrar una solución técnica alternativa para extraer metadatos, una que no afecte en absoluto a los lectores o editores . Así que, supongo que soy una débil oposición . Pero si no se puede desarrollar otra solución, entonces el atractivo de la generación de "líneas de tiempo automatizadas" es suficiente para hacerme reconsiderar en el futuro. ¿Hay alguna demostración disponible para eso? -- Quiddity ( discusión ) 19:05, 31 de marzo de 2009 (UTC) [ responder ]
  132. Oposición : los metadatos son importantes, pero no es así como hay que hacerlo. Solución en busca de un problema. – Quadell ( discusión ) 19:39 31 mar 2009 (UTC) [ responder ]
  133. Oponerse . Ha beneficiado quizás a unos cuantos miles de usuarios a costa de miles (¿millones?) de horas de trabajo y recursos del servidor. El formato automático es, en términos simples, una locura. --- RockMFR 19:48, 31 de marzo de 2009 (UTC) [ responder ]
  134. Oposición . Es un pequeño detalle que nos carga miles de enlaces. Además, creo que es extraño que exijamos que los artículos orientados a los EE. UU. se escriban con ortografía estadounidense y que permitamos el formato automático de las fechas. El formato de fecha debería aplicarse con la ortografía. -- Magioladitis ( discusión ) 19:52, 31 de marzo de 2009 (UTC) [ responder ]
  135. Oponerse . -- DuLithgow ( discusión ) 21:01 31 mar 2009 (UTC) [ responder ]
  136. Oposición . Deberíamos dejar de usar enlaces de fechas para el formato automático. Puede que haya otras formas menos intrusivas de formatear fechas automáticamente. — Xavier , 21:29, 31 de marzo de 2009 (UTC) Actualización, a petición de un editor, y para que quede claro: me opongo a cualquier tipo de marcado con el único fin de dar formato automático a las fechas. — Xavier , 21:10, 3 de abril de 2009 (UTC) [ responder ]
  137. Oposición . Creo que la verdadera señal de alerta aquí es esa afirmación de que el formato automático "ha sido una opción en los sistemas operativos durante décadas". Sí, esto es cierto, porque hace décadas la mayoría de los sistemas operativos mostraban las fechas en formato numérico, lo que generaba una auténtica ambigüedad sobre el significado de la fecha si se encontraba en los primeros doce días del mes. Esto parece haber llevado a la suposición en el mundo de los nerds de que también existe un problema de ambigüedad/legibilidad incluso cuando se escribe el mes con todas las letras. No deberíamos seguir los sistemas operativos, sino las fuentes de información del mundo real. Nunca me he encontrado con una fuente de información web o un proveedor de noticias que se preocupe lo suficiente por esto como para dar a los lectores una opción sobre cómo mostrar la fecha, así que para nosotros preocuparnos por el tema es dedicarnos a una investigación original . En el mundo de habla inglesa fuera de los Estados Unidos no hay una preferencia nacional por un formato u otro: es sólo una cuestión de estilo personal o de la guía de estilo de una publicación individual. ¿ Están los angloparlantes del Reino Unido confundidos porque The Times [3] usa MMM DD, AAAA pero The Guardian [4] usa DD MMM AAAA? ¿O en la India porque The Hindu [5] dice MMM DD, AAAA pero The Times of India [6] DD MMM AAAA? ¿O en Australia porque The Age [7] usa MMM DD, AAAA y la Australian Broadcasting Corporation [8] DD MMM AAAA? Canadá: Toronto Star [9] MMM DD, AAAA, pero Canadian Broadcasting Corporation [10] DD MMM AAAA? Ninguno de estos sitios web, ni ningún otro que pueda encontrar, da la opción a los lectores de mostrar la fecha en un formato diferente, pero no veo ninguna queja. ¿Y dónde están todas las fuentes confiables que discuten sobre cómo los estadounidenses que se alistan en las fuerzas armadas se confunden acerca de que las fechas tengan un formato diferente? El formato automático de la fecha es un caso clásico de una solución que espera un problema. O nos ceñimos al actual estándar pragmático de estilo o, como parece que sólo en Estados Unidos hay una fuerte preferencia por un formato sobre el otro, ¿por qué no decimos simplemente que es MMM DD, AAAA en todos los casos? Phil Bridger ( discusión ) 23:02 31 mar 2009 (UTC) [ responder ]
  138. Oponerse . -- Tan poco valor añadido, tanto tiempo perdido. Ground Zero | t 23:36, 31 de marzo de 2009 (UTC) [ responder ]
  139. Oposición . El formato de las fechas no aporta nada a ningún artículo. Deberíamos prohibir los enlaces wiki a las fechas. Esta propuesta va en la dirección opuesta. SMP0328. ( discusión ) 00:25 1 abril 2009 (UTC) [ responder ]
  140. Oposición : El formato automático es tan oneroso como la vinculación de fechas, en lo que respecta al editor. Con mis habilidades de mecanografía, sería simplemente otra oportunidad para cometer errores. PKKloeppel ( discusión ) 01:10 1 abril 2009 (UTC) [ responder ]
  141. No me opongo, no hay necesidad de ello. Kablammo ( discusión ) 01:23 1 abr 2009 (UTC) [ responder ]
  142. Oponerse: intrusivo, inútil. Ceoil ( discusión ) 01:29 1 abr 2009 (UTC) [ responder ]
  143. Oponerse —Cwap verdadero. LilHelpa ( discusión ) 01:31 1 abr 2009 (UTC) [ responder ]
  144. Oponerse: los enlaces deberían llevar a los usuarios a contenido útil. Los enlaces de fecha no lo hacen. -- Ssilvers ( discusión ) 05:29 1 abr 2009 (UTC) [ responder ]
  145. Oposición —No sirve de nada el formato automático. No veo el problema aquí. -- Popiloll ( discusión ) 06:53 1 abr 2009 (UTC) [ responder ]
  146. Oponerse — Según WP:OVERLINK . Llenar las páginas con enlaces irrelevantes no sirve de nada. Sé que cuando era un usuario nuevo, a menudo hacía clic en estos enlaces de fechas esperando obtener información relevante, y siempre me decepcionaba no encontrar ninguna. Gatoclass ( discusión ) 07:28 1 abril 2009 (UTC) [ responder ]
  147. Oponerse —Anderson menciona arriba "dificultades gramaticales irresolubles", aquí hay otra. Tome la frase un cambio de formato de decisión del 7 de agosto y tendrá que tener una decisión del 7 de agosto . {{#formatdate:}} ni siquiera puede manejar rangos todavía; ¿podemos esperar que alguna vez pueda manejar esto? Pero supongamos por el momento que estos problemas se resuelven (... es el año 2187 ...) el formato automático trae consigo otro mal. Al mostrar las fechas en el formato preferido del usuario, la inconsistencia subyacente se puede ocultar a las mismas personas que de otra manera estarían solucionando tales problemas. Tal vez se podría implementar un sistema predeterminado página por página para evitar esto. Por lo tanto, el formato automático de WikiMedia tiene un largo camino por recorrer hasta que sea una solución viable de manera realista. ¿Vale la pena el problema? ¿Hay alguna gran diferencia entre mirar el formato de fecha de los otros lados en lugar de mirar su ortografía? El formato de fecha es solo un aspecto del dialecto, dejémoslo así bajo ENGVAR ... o al menos hasta que alguien se le ocurra una solución viable para eso. J IM p talk · cont 08:07, 1 abril 2009 (UTC) [ responder ] 
  148. En palabras de Donald Knuth, "la optimización prematura es la raíz de todos los males". Pero yo estaría totalmente a favor de una herramienta inteligente de formato automático de fechas del lado del cliente , por ejemplo, en forma de un complemento de Firefox. -- dab (𒁳) 08:34, 1 de abril de 2009 (UTC) [ responder ]
  149. Oponerse —No es un beneficio que los editores vean formatos de fecha distintos a los que ve el lector general. Todos somos lo suficientemente flexibles como para reconocer y comprender fechas en varios formatos. — Mattisse ( Discusión ) 11:43 1 abr 2009 (UTC) [ responder ]
  150. Me opongo . He pasado toda mi vida sin darme cuenta de que esto es un problema, o de que existen (supuestamente) preferencias específicas por país. Leo "1 de abril" y "1 de abril" con la misma facilidad; ni siquiera se nota la diferencia. Como muchos otros han dicho, no veo que haya un problema que resolver, y me opongo a la adición innecesaria de marcado que simplemente sirve para hacer que la edición sea más engorrosa, críptica, propensa a errores y lleve más tiempo. Mateo 11:55, 1 de abril de 2009 (UTC).
  151. Oponerme No le veo mucho sentido a esto VJ (discusión) 12:42 1 abr 2009 (UTC) [ responder ]
  152. Oposición : no hay muchas ventajas (¿hay alguna ventaja en absoluto?) y un coste enorme. Como editor, no quiero ver el código fuente de la página lleno de etiquetas aún más crípticas. Y soy un ingeniero de software que ha estado programando el manejo de fechas para bases de datos de vez en cuando desde 1994 (como mi trabajo diario remunerado), sé lo complejo que es manejar fechas. Los desarrolladores de MediaWiki deberían dedicar su tiempo a cuestiones más productivas. Ni siquiera han tenido tiempo de arreglar la función del analizador #time todavía, tiene errores conocidos. Pero no saben qué causa esos errores. ¿Y ahora quieren agregar un manejo complejo de fechas a MediaWiki? -- David Göthberg ( discusión ) 17:20, 1 abril 2009 (UTC) [ responder ]
  153. Oposición - El formato de fecha dificulta la edición de Wikipedia :^( Fightin' Phillie ( discusión ) 17:58 1 abr 2009 (UTC) [ responder ]
  154. Oposición : el formato automático añade complejidad y no resuelve ningún problema importante. EdJohnston ( discusión ) 19:39 1 abr 2009 (UTC) [ responder ]
  155. Oponerse – Quiero estar del lado ganador por una vez. Brianboulton ( discusión ) 23:47 1 abril 2009 (UTC) [ responder ]
  156. Oposición - ¿Qué será lo próximo, la "extensión de ortografía automática" que cambia el aluminio por aluminio o el ascensor por elevador según las preferencias del usuario? Burocracia innecesaria cuando no es necesaria. SFC9394 ( discusión ) 00:03 2 abr 2009 (UTC) [ responder ]
  157. Me opongo . Básicamente creo que es un desperdicio de mano de obra hacer la revisión. -- TonyTheTiger ( t / c / bio / WP:CHICAGO / WP:LOTM ) 00:12, 2 de abril de 2009 (UTC) [ responder ]
  158. Oposición : demasiado trabajo para el beneficio, aunque no estoy de acuerdo con aquellos que dicen que los formatos de fecha existentes no plantean ningún problema. Las fechas ISO son un fastidio y el problema de las fechas anteriores al día 12 del mes es real y los editores deben solucionarlo. Pero no veo que el formato automático sea una solución. hamiltonstone ( discusión ) 00:45 2 abril 2009 (UTC) [ responder ]
  159. Oposición : no hay ningún problema real que solucionar; la mayoría de las personas pueden entender ambas formas de fechas. Básicamente, parece mucho trabajo para casi ningún beneficio real. Ledgend Gamer 02:11, 2 de abril de 2009 (UTC) [ responder ]
  160. Oposición - En realidad no hay necesidad de ello. 2 de abril o 2 de abril, no es tan diferente a la diferencia entre color y color. Es una diferencia simple que depende de tu dialecto. No es un gran problema en mi opinión. -- Sable232 ( discusión ) 02:38 2 abril 2009 (UTC) [ responder ]
  161. El formato de fecha opuesto daría como resultado un wikitexto complejo con el único beneficio de que las personas sensibles acostumbradas al "1 de abril" podrían esperar no ver nunca el "1 de abril", y viceversa. El wikitexto complejo hace que sea más difícil centrarse en el contenido importante de un artículo. El formato de fecha sería una sobrecarga inútil para los servidores de WP y una pérdida de tiempo frívola para los editores. Johnuniq ( discusión ) 02:39 2 abril 2009 (UTC) [ responder ]
  162. Oponerse : la sintaxis de Wikitext debería mantenerse lo más simple posible para alentar las contribuciones de nuevos usuarios. Complicar la sintaxis para el beneficio exclusivo de los editores registrados es un anatema. AxelBoldt ( discusión ) 02:41 2 abril 2009 (UTC) [ responder ]
  163. Oponerme - Leo con mucha facilidad cualquier fecha en cualquier formato y creo que el formato de fecha es simplemente un trabajo innecesario Bob man801 ( discusión ) 04:28, 2 de abril de 2009 (UTC) [ responder ]
  164. En contra . Iba a "votar" neutral, pero cambié de opinión. En principio, me gusta la idea de dar a los usuarios la opción de mostrar las fechas de la manera que prefieran. Sin embargo, dudo que más de una fracción muy pequeña de usuarios de Wikipedia hayan aprovechado alguna vez esta característica (o lo hagan en el futuro). Para beneficiarse del formato de fecha, un usuario debe estar registrado y conectado, y debe haber establecido la preferencia para la visualización de la fecha. Sin embargo, supongo que la gran mayoría de los usuarios que acceden a Wikipedia mientras están conectados lo hacen principalmente para editar (no para leer artículos) y no les importa la visualización de la fecha (porque están en Wikipedia principalmente para editar, no para leer artículos). En consecuencia, estimo que muy pocos usuarios se benefician realmente del formato de fecha. El pequeño beneficio del formato automático no justifica los recursos que se gastarían para implementarlo (imagino que el formato automático consumiría tiempo y espacio de los voluntarios en los artículos, e intimidaría a una cierta fracción de posibles voluntarios, impidiéndoles ofrecerse como voluntarios). -- Orlady ( discusión ) 04:40 2 abr 2009 (UTC) [ responder ]
  165. Oponerse Cuando descubrí por primera vez que podía autoformatear fechas a través de mis preferencias de usuario, lo hice inmediatamente. Sin embargo, luego descubrí que lo que estaba viendo en un artículo no era lo que estaba viendo cuando editaba la página. Como editores, es nuestra responsabilidad optimizar la enciclopedia para los lectores, la gran mayoría de los cuales no tienen acceso al autoformato, porque no están registrados. El autoformato actúa como un impedimento para los editores, engañándolos en cuanto a lo que los lectores están viendo, y como tal es indeseable. -- Aervanath ( discusión ) 05:14 2 abr 2009 (UTC) [ responder ]
  166. Oposición (1) No hay ningún problema que resolver aquí (2) Ya tenemos demasiados elementos de marcado intimidantes para que los nuevos usuarios los puedan manejar, y el {{#formatdate|11 de marzo de 2009}} es simplemente inaceptable. (3) Los editores no deberían ver algo diferente de lo que verá la gran mayoría de los lectores. Shreevatsa ( discusión ) 05:28 2 abr 2009 (UTC) [ responder ]
  167. Oponerse por innecesario. Los distintos formatos de fecha son como variaciones regionales en la ortografía: es muy fácil acostumbrarse a ellos. ¿Qué sigue? ¿Formato automático para cambiar "color" por "color"? Rivertorch ( discusión ) 05:31 2 abr 2009 (UTC) [ responder ]
  168. Los editores de Oppose deberían tener la misma visión que los lectores en general. Taemyr ( discusión ) 05:55 2 abr 2009 (UTC) [ responder ]
  169. Oponerse a Per Sept, Sandy, Karanacs y otros.-- Yannismarou ( discusión ) 08:03 2 abr 2009 (UTC) [ responder ]
  170. Oposición . El formato automático requiere más trabajo y no veo ningún beneficio para los lectores. Todo el mundo entiende las fechas en ambos formatos comunes. Ya se requiere demasiada sintaxis para cumplir con los requisitos de MoS para los FA, y cualquiera que piense que la gente no discutirá sobre la eliminación/adición de formato tanto como sobre los formatos de fecha nacionales subestima el deseo de los editores de una guerra sin sentido. Simplemente tener reglas para las fechas como con Engvar es el camino a seguir. 134.169.58.89 ( discusión ) 09:12, 2 abril 2009 (UTC) [ responder ]
  171. Me opongo . No vale la pena el esfuerzo que se requiere. Hace que la edición sea más difícil y, como mucho, el beneficio para los lectores en general es dudoso. − Woodstone ( discusión ) 11:20 2 abr 2009 (UTC) [ responder ]
  172. Oposición . No. Ciertamente no quiero que mi marcado se aleje aún más del lenguaje natural, y la implementación inevitablemente limitada de las plantillas obligará a cualquier herramienta automatizada basada en fechas a analizar fechas que no estén basadas en plantillas. ¿Y qué haría una herramienta automatizada? Es poco probable que pueda determinar qué fechas están estrechamente vinculadas con el contenido del artículo y cuáles, por ejemplo, describen el proceso por el cual el tema del artículo se vuelve bien comprendido. Avram ( discusión ) 16:45, 2 de abril de 2009 (UTC) [ responder ]
  173. Oponerse , según Pmanderson, Karanacs y Gatoclass. -- Rosiestep ( discusión ) 17:32 2 abr 2009 (UTC) [ responder ]
  174. Oponerse No debería haber diferencia entre usuarios ocasionales y registrados. -- Shahab ( discusión ) 18:57 2 abr 2009 (UTC) [ responder ]
  175. Oponerse a ENGVAR es la mejor y más sencilla solución a este no-problema. -- Mattinbgn \ talk 20:46, 2 abril 2009 (UTC) [ responder ]
  176. El número 130 lo dice mejor y no veo que nadie comente el hecho de que los genealogistas en los EE. UU. utilicen el día/mes completo/año mucho más que el otro. Incluso FamilySearch lo utiliza en todas partes. Yo utilizo el sistema de datación europeo. Samuelsenwd ( discusión ) 21:49 2 abr 2009 (UTC) [ responder ]
  177. Oposición . Sospecho que a la mayoría de los lectores no les importa si un artículo dice 2 de abril o 2 de abril; el orden es lo suficientemente trivial como para no justificar la complejidad adicional de codificación. Steve T • C 22:02, 2 de abril de 2009 (UTC) [ responder ]
  178. Opóngase a esta innecesaria complejidad añadida. — S Marshall Talk / Cont 22:24, 2 abril 2009 (UTC) [ responder ]
  179. Oposición - Nuestro propio Director Técnico dice: "Mi recomendación personal sería eliminar todo el formato automático de fechas". Todo esto es complejo y laborioso y no aporta prácticamente ningún beneficio adicional. Mientras se indique una fecha, no me importa si está escrita el 2 de abril de 2009, el 2 de abril de 2009 o el segundo día del mes de abril del año 2009. Jd 027 ( discusión ) 23:22 2 abril 2009 (UTC) [ responder ]
  180. Me opongo . ¿Tengo que repetir los argumentos? -- Taku ( discusión ) 01:47 3 abr 2009 (UTC) [ responder ]
  181. Oponerse - No deberíamos manipular el texto de un artículo para favorecer la animosidad de ciertos grupos de usuarios, especialmente cuando no hay absolutamente ningún problema en entender ninguna variante de fecha. Cacycle ( discusión ) 02:50 3 abril 2009 (UTC) [ responder ]
  182. Oposición . Nunca vi ninguna ventaja en el formato automático y la implementación (hasta ahora) ha hecho más daño que bien. Yilloslime T C 04:33, 3 de abril de 2009 (UTC) [ responder ]
  183. Me opongo , si como usuario no registrado se me permite hacerlo. Esa es una de mis razones para objetar: la gente no debería perder el tiempo en esto cuando no beneficiará a usuarios como yo. Además, cualquier cantidad de marcado adicional en algo tan breve como una fecha es difícil de manejar. Y no es sólo una cuestión de traducir "3 de abril de 2009" o "3 de abril de 2009"; si esto aparece dentro de una oración, puede ser necesaria una segunda coma en el segundo formato, es decir, "3 de abril de 2009". Incluso si proporcionamos opciones para esto, muchas personas acostumbradas a otros formatos lo entenderán mal. -- 208.76.104.133 ( discusión ) 05:15, 3 abril 2009 (UTC) [ responder ]
  184. Me opongo . Varias de las razones que se han dado me parecen razonables, en particular la cuestión de que los usuarios de IP no ven la fecha formateada. Mike Christie (discusión) 10:57 3 abr 2009 (UTC) [ responder ]
  185. En contra . Aunque normalmente estoy a favor de soluciones técnicas complicadas para problemas que no son problemas (especialmente cuando se supone que debo estar haciendo algo productivo), esta va a causar más problemas de los que merece. Mientras no utilicemos fechas puramente numéricas, no hay ambigüedad y el orden (4 de enero frente a 4 de enero) no importa en absoluto. Sin embargo, hay una salvedad : si utilizamos fechas numéricas en algún lugar (infoboxes, por ejemplo), deberían estar en un formato de fecha razonable, ya sea YMD o DMY, con años de cuatro dígitos. Apoyaría el formato automático para hacer cumplir esto, pero hasta donde sé, la mayoría de las plantillas ya lo hacen. Orpheus ( discusión ) 11:00, 3 abril 2009 (UTC) [ responder ]
  186. En contra - No estoy muy convencido de esto, pero después de reflexionar sobre ello, es una decisión bastante clara. El formato automático es una buena idea en teoría, pero en la práctica ofrece un beneficio leve a un número muy pequeño de editores comprometidos e involucrados (que están lo suficientemente informados como para establecer preferencias), mientras que ofrece un detrimento igualmente leve a la gran mayoría de nuestros lectores. Es una buena idea, pero la implementación no estuvo a la altura de lo que esperábamos, y esperamos que seamos un proyecto lo suficientemente maduro como para poder descartar cosas que no nos ayuden. Shimgray | discusión | 15:17, 3 abril 2009 (UTC) [ responder ]
  187. Oposición : no tenemos ni queremos una ortografía automática del inglés británico o estadounidense. Esto es análogo. -- KelleyCook ( discusión )
  188. Oponerse : el Manual de estilo no permite ni recomienda formatos confusos como 03/04/2009, por lo que no debería haber confusión para los lectores humanos. Sólo los editores que hayan iniciado sesión y tengan las preferencias establecidas probablemente se confundan (o provoquen confusión) porque no verán lo que hace un lector que pase por allí. 21Bede (discusión) 15:51 3 abr 2009 (UTC) [ responder ]
  189. Me opongo, principalmente porque se trata de un simple caso de WP:ENGVAR . Los partidarios que dicen que Wikipedia debería presentar las fechas de forma coherente olvidan convenientemente que tampoco escribimos colour/color o meter/metre de forma coherente en toda la enciclopedia. El ejemplo de que Britannica utiliza formatos de fecha coherentes es simplemente una extensión del hecho de que utilizan la ortografía del inglés británico coherente. Lo que tenemos que hacer es tener formatos de fecha coherentes dentro de cada artículo y las fechas de texto simple pueden resolver eso sin necesidad de marcado adicional. -- seav ( discusión ) 16:38, 3 de abril de 2009 (UTC) [ responder ]
  190. Oposición : en base al principio KISS y debido a todos los problemas que enfrenta Wikipedia (que está pidiendo donaciones para seguir funcionando) y sus voluntarios, esto parece una prioridad muy baja. Además, si se necesita algo de los editores para atender este problema, no vale la pena. En otras palabras, no gastaría ningún tipo de recursos (incluso esta encuesta parece consumir mucho tiempo) y en mi opinión, como wikipedista relativamente nuevo, Wikipedia ya está empantanada en una enorme cantidad de este tipo de discusiones. El sistema actual funciona, todos los editores saben que se supone que deben ser coherentes en los artículos y, como miembro del equipo de edición de textos, hasta ahora rara vez encuentro que algún artículo sea inconsistente, pero si lo es, márcalo para edición de textos y déjalo pasar. No se debe agregar nada que requiera marcado adicional a Wikipedia hasta que un mayor número de personas estén familiarizadas con el marcado actual. Levalley ( discusión ) 18:20, 3 de abril de 2009 (UTC) [ responder ]
  191. Oponerse - Malik Shabazz  ( discusión  · contribuciones ) 19:41, 3 de abril de 2009 (UTC) [ respuesta ]
  192. Oponerse . Malinaccier ( discusión ) 19:47 3 abr 2009 (UTC) [ responder ]
  193. Oponerse a la molestia del formato automático no vale la pena el esfuerzo, por lo que algunos editores registrados solo pueden ver un tipo de formato de fecha. Todos los demás verán dos formatos según el artículo en el que se encuentren. Eso no es gran cosa. Deegee375 ( discusión ) 21:13, 3 de abril de 2009 (UTC) [ responder ]
  194. Oposición Por lo que he podido ver, solo los usuarios registrados podrían verlo. Si ese es el caso, simplemente no debería introducirse. Peanut4 ( discusión ) 21:52 3 abr 2009 (UTC) [ responder ]
  195. Oponerse , no es una adición útil. -- Peta ( discusión ) 08:15 4 abr 2009 (UTC) [ responder ]
  196. Oponerse -- Alex Holcombe ( discusión ) 08:43 4 abr 2009 (UTC) [ responder ]
  197. Me opongo firmemente : el formato automático es para los amantes del marcado. Las personas sensatas (y productivas) gastan su energía de manera mucho más inteligente. DCGeist ( discusión ) 09:01, 4 de abril de 2009 (UTC) [ responder ]
  198. Oponerse - ¡No, no, mil veces no! El autofotaje debe evitarse a toda costa. Además, es malo y debe desaparecer. — Comentario anterior sin firmar agregado por Snappy ( discusióncontribs )
  199. Oponerse al formato automático complicaría demasiado las cosas y los beneficios que obtendríamos de él son muy menores, en mi opinión. ¡Simplifiquemos el marcado tanto como sea posible y no al revés! Laurent ( discusión ) 12:24 4 abr 2009 (UTC) [ responder ]
  200. Me opongo , simplemente no veo cuál es el problema principal: soy del Reino Unido (y personalmente prefiero el formato de fecha del Reino Unido), pero puedo entender fácilmente el formato estadounidense (mes, día, año; tal vez no tanto MDY) o el formato ISO (AAAAMMDD). ~~ [ジャム] [ t  -  c ] 14:14, 4 de abril de 2009 (UTC) [ responder ]
  201. Oposición : El formato automático no hace nada por la gran mayoría de lectores de WP, sólo por aquellos que a) están conectados a cuentas reales aquí, y b) se han molestado en configurar las opciones de formato automático. La "función" de formato automático hace que los editores experimentados (es decir, aquellos que probablemente solucionen las inconsistencias de los artículos) rara vez noten fechas inconsistentes dentro de un artículo, incluyendo el formato ISO, que se presentan de manera inconsistente a la mayoría de los lectores. — SMcCandlish [ discusión ] [ cont ] ‹(-¿-)› 18:22, 4 de abril de 2009 (UTC) [ responder ]
  202. Oponerse Manténgalo simple, elija un formato apropiado para MOS:NUM y escríbalo de manera consistente. Podemos lidiar con WP:ENGVAR , no necesitamos una solución técnica para lidiar con el uso de un formato de fecha apropiado. Struway2 ( discusión ) 20:19 4 abr 2009 (UTC) [ responder ]
  203. Oponerse : no tiene sentido, causa problemas y no vale la pena el esfuerzo ni las disputas. Ottava Rima ( discusión ) 20:21 4 abr 2009 (UTC) [ responder ]
  204. Me opongo . No veo cómo el resultado vale el costo. bibliomaniac 1 5 23:45, 4 abril 2009 (UTC) [ responder ]
  205. Me opongo . Nunca le vi sentido. -- Moni3 ( discusión ) 03:18 5 abr 2009 (UTC) [ responder ]
  206. Oponerse : todo lo que requiera buscar entre las opciones de preferencias sólo será utilizado por un pequeño grupo de usuarios. Además, la gran mayoría de nuestros usuarios ni siquiera están registrados. Mucho trabajo, poco beneficio. Shoemaker's Holiday ( discusión ) 06:02 5 abr 2009 (UTC) [ responder ]
  207. Oponerse Esta es una solución en busca de un problema. Simplemente manténgalo consistente en cada artículo. Joshdboz ( discusión ) 07:13 5 abr 2009 (UTC) [ responder ]
  208. Oposición Dejemos que los editores que trabajan en un artículo se pongan de acuerdo sobre formatos coherentes. No hay necesidad de un proceso automático, que bien podría generar más problemas. Jezhotwells ( discusión ) 12:11 5 abr 2009 (UTC) [ responder ]
  209. Oponerse No agregue complejidad donde no es necesaria y es propensa a errores y malas interpretaciones.-- Avg ( discusión ) 15:41 5 abr 2009 (UTC) [ responder ]
  210. Oponerse Resuelve de manera poco elegante lo que no debería ser. -- Thomas Bdiscusión 16:53, 5 abril 2009 (UTC) [ responder ]
  211. Oponerse . Los argumentos en contra realmente lo resumen todo por completo. — Σ xplicit 19:02, 5 de abril de 2009 (UTC) [ responder ]
  212. Oposición: No creo que las fechas deban estar vinculadas, parece un caos. Ryan 4314 ( discusión ) 19:11 5 abr 2009 (UTC) [ responder ]
  213. Oponerme - Lo apoyé la primera vez, cuando se mencionó por primera vez, y lo apoyo ahora. --  ThinkBlue  (Hit BLUE ) 22:32, 5 de abril de 2009 (UTC) [ responder ]
  214. Me opongo a ello con argumentos excelentes. Como dijo Tony, la simplicidad sin sacrificar la calidad es la clave; lamentablemente, el formato automático tiene el potencial de violar ambas. — Deckill er 23:43, 5 de abril de 2009 (UTC) [ responder ]
  215. Oposición : Creo que deberíamos seguir estrictamente la norma ISO en todos y cada uno de los casos, no sólo en lo que respecta a las fechas, sino también a la hora, las unidades y todo lo demás. Si esto se pudiera lograr, el formato automático sería una tarea trivial de reconocimiento de patrones simple que incluso podría realizarse localmente con secuencias de comandos de Java; la única etiqueta especial necesaria es en el caso en que un formato no deba ser localizado. La razón por la que me opongo a esto es que creo que todas las formas de localización deberían estar en un formato general; implementar un caso especial para las fechas sería confuso e iría en contra de una norma uniforme en el formato de texto sin formato. Entiendo que "corregir" todo según la norma ISO es una tarea monumental, sin embargo, creo que el beneficio supera el costo y no nos falta la mano de obra para hacerlo. Brainz ( discusión ) 04:22, 6 de abril de 2009 (UTC) [ responder ]
  216. Oposición - Sólo un pequeño subconjunto de lectores de Wikipedia se beneficiará del formato automático y la sintaxis compleja disuade a los nuevos editores. -- SWTPC6800 ( discusión ) 04:27, 6 abril 2009 (UTC) Cada mes, Wikipedia tiene alrededor de 56 millones de visitantes únicos. Sólo hay 180 mil wikipedistas que establecen una preferencia de datos, por lo que, en el mejor de los casos, 1 de cada 300 visitantes (0,3 %) se beneficiará del formato automático de fechas. -- SWTPC6800 ( discusión ) 02:41, 12 abril 2009 (UTC) [ responder ]
  217. Oposición : no estoy de acuerdo con los distintos formatos para los registrados y los no registrados. WP:ENGVAR resuelve este problema sin fundamento a la perfección.-- 2008 Olym pian chit chat 04:57, 6 de abril de 2009 (UTC) [ responder ]
  218. Oposición : falta de impacto/beneficiarios en comparación con la cantidad de trabajo para implementar. Recuerde la relación costo/beneficio. Annihilatron ( discusión ) 13:28 6 abr 2009 (UTC) [ responder ]
  219. Oposición : vincular fechas con el fin de reformatear rompe el concepto típico de vinculación que tiene el usuario y, además, termina con toneladas de enlaces irrelevantes por toda la página. El reemplazo propuesto es igualmente malo. Las personas que necesitan absolutamente tener un formato de fecha, deberían hacerlo con un javascript personal o un complemento del navegador. -- Austin Murphy ( discusión ) 14:26, 6 de abril de 2009 (UTC) [ responder ]
  220. Oposición : No hay motivos para que el formato de fecha no se pueda aplicar de la misma manera que la ortografía y otras diferencias regionales. Richard New Forest ( discusión ) 14:52 6 abr 2009 (UTC) [ responder ]
  221. Oponerse al per #1 y per si se bloquea el servidor ... miranda 16:33, 6 abril 2009 (UTC) [ responder ]
  222. En el análisis de costo-beneficio, el pequeño costo de la complejidad añadida supera el beneficio posible, casi indistinguible de cero. Knepflerle ( discusión ) 16:37 6 abril 2009 (UTC) [ responder ]
  223. Oponerse Esto es un desperdicio de recursos en mi humilde opinión. R3ap3R.inc ( discusión ) 17:03 6 abr 2009 (UTC) [ responder ]
  224. Oponerse a KISS. Fredrik Johansson 17:28, 6 de abril de 2009 (UTC) [ respuesta ]
  225. Oponerse Cualquiera que sea lo suficientemente inteligente como para trabajar con las opciones de configuración no tendrá problemas para interpretar varios formatos de fecha. — Danorton  ( discusión ) 18:10 6 abril 2009 (UTC) [ responder ]
  226. Oponerse Ayuda a pocos, hace que sea menos probable que los editores experimentados noten los problemas de formato, la sintaxis confusa hace que la edición sea aún más difícil para los editores novatos. Calliopejen1 ( discusión ) 18:25 6 abr 2009 (UTC) [ responder ]
  227. Opóngase a la estandarización del lujo que aporta muy pocos beneficios. Peter Isotalo 18:33, 6 abril 2009 (UTC) [ responder ]
  228. ¿ Por qué todo tiene que estar estandarizado? No es necesario, no es necesario. Edmund Patrickconfer 19:01, 6 abril 2009 (UTC) [ responder ]
  229. Oponerse No hay problema, una fecha es una fecha. No importa dmy o ymd, a menos que seas de los que piensa que hablar más alto a alguien que no habla tu idioma hace que te entienda :>-- Mrboire ( discusión ) 19:47 6 abr 2009 (UTC) [ responder ]
  230. Oponerse a esto, la mayoría de los lectores no lo ven, es inútil en muchos/la mayoría de los casos -- KarlFrei ( discusión ) 20:18, 6 abril 2009 (UTC) [ responder ]
  231. Oponerse a una mejora muy marginal (ya que ambos formatos de fecha son perfectamente comprensibles y la mayoría de los lectores no utilizan cuentas) frente a una enorme dilución de la prominencia de los valiosos enlaces azules. Los artículos sobre días y años, si bien pueden tener algún propósito, NUNCA son un enlace útil en el contexto de ningún artículo. Creo que el consenso en contra de esto es fuerte, pero aún más fuerte cuando se examinan las opiniones de los usuarios que han escrito un artículo destacado o han trabajado como revisores en ese proceso. Savidan 20:58, 6 de abril de 2009 (UTC) [ responder ]
  232. Opónganse si no está roto, no lo arreglen. Dlabtot ( discusión ) 00:19 7 abr 2009 (UTC) [ responder ]
  233. Oponerse — Coste/beneficio negativo (coste en términos de molestia, esfuerzo y tiempo). Es una capacidad interesante, sin duda, pero es la respuesta a una pregunta que en realidad no es necesario plantear, como contratar a un traductor para que traduzca un discurso pronunciado por un australiano a una audiencia estadounidense o viceversa. El acceso de nadie a Wikipedia se ve obstaculizado por encontrar fechas en este formato en lugar de en aquel; centremos nuestros esfuerzos en implementar funciones para ampliar la accesibilidad allí donde dicha ampliación sea realmente necesaria. — Scheinwerfermann T · C 00:35, 7 de abril de 2009 (UTC)[ responder ]
  234. Oposición. La presión a favor del autoformato es una respuesta comprensible pero inapropiada a la complejidad inherente de Wikipedia y a la diversidad de sus lectores. Es un ejemplo de un enfoque tecnocrático insidioso, "de sumo sacerdote", que perjudica y desalienta a la gran mayoría de los editores ordinarios. Los supuestos beneficios no justifican la concesión que exige, a una minoría ruidosa que no entiende el lado humano de la participación en Wikipedia. Tal vez en el futuro el proyecto se apoye en fundamentos técnicos más racionales; hasta entonces, hay que resistirse a este tipo de iniciativas por considerarlas inviables. Tanto para los usuarios como para los editores, tenemos que mantener las cosas sencillas y comprensibles. – ⊥ ¡ɐɔıʇǝo N oetica! T – 07:19, 7 de abril de 2009 (UTC) [ responder ]
  235. Oponerse , es bastante innecesario. PluniAlmoni ( discusión ) 09:43 7 abr 2009 (UTC) [ responder ]
  236. "Me opongo", supongo. En realidad, no me opongo en absoluto al concepto general de autoformateo de fechas, a diferencia, por ejemplo, de Noetica, según interpreto su respuesta más arriba. Sin embargo, en efecto, no se nos pide nuestra opinión sobre el concepto general , sino sobre la implementación que probablemente obtendremos. Me opongo a esta implicación que probablemente obtendremos , por las razones señaladas por Jimp en la votación (o si lo prefieres, "!vote") alrededor de la 146 anterior. Por supuesto, se podría dedicar más trabajo a perfeccionar un algoritmo sensible al contexto, y esto podría incluso funcionar, eventualmente; pero eso parecería un gasto extraño de tiempo, esfuerzo y quizás también de potencia de procesamiento, como explicó Largo Plazo en la votación alrededor de la 56 anterior. (NB: mi voto no tiene nada que ver con la vinculación de fechas, que por supuesto (a) apesta, pero (b) no viene al caso aquí.) -- Hoary ( discusión ) 09:52, 7 de abril de 2009 (UTC) [ responder ]
  237. Me opongo . Apoyo a Jimp (147). Las razones del "a favor" son muy débiles. Platia ( discusión ) 14:06 7 abr 2009 (UTC) [ responder ]
  238. Oponerse Parece demasiado esfuerzo y riesgo para algo tan trivial. Si se implementa, podría ir seguido de propuestas para autoformatear la ortografía británica frente a la estadounidense, etc. Qué aburrido. Uno de los atractivos de Wikipedia es su heterogeneidad: también es la naturaleza del idioma inglés. ¿Por qué intentar meter esa heterogeneidad en una caja uniforme? Pinkville ( discusión ) 14:56 7 abr 2009 (UTC) [ responder ]
  239. Oposición Por sí sola, la función de formato automático es potencialmente interesante, pero si se la compara con sus desventajas, se queda corta. Las pequeñas ventajas no compensan todo el esfuerzo. -- Cyde Weys 15:39, 7 de abril de 2009 (UTC) [ responder ]
  240. Oponerse Parece mucho esfuerzo para resolver un problema menor y otro paso en la curva de aprendizaje para los nuevos editores. ¿Qué será lo próximo, un corrector ENGVAR? Acroterion (discusión) 18:31 7 abr 2009 (UTC) [ responder ]
  241. Oposición . Se supone que esta es la enciclopedia que cualquiera puede editar , no la enciclopedia que cualquiera que esté dispuesto a aprender reglas esotéricas de marcado puede editar . Creo que ya hemos bajado demasiado por esta pendiente resbaladiza. Jgm ( discusión ) 20:45 7 abr 2009 (UTC) [ responder ]
  242. Oposición por Awadewit. Nev1 ( discusión ) 21:33 7 abr 2009 (UTC) [ responder ]
  243. Oponerse como Jgm arriba -- Doug ( discusión ) 09:05 8 abr 2009 (UTC) [ responder ]
  244. Mi postura sigue siendo contraria al formato automático de fechas en general; nada ha cambiado realmente con el sistema "sin enlaces" propuesto y no estoy convencido de que cualquier sistema sugerido pueda resolver los problemas inherentes a este tipo de tratamiento.
    1. Uno de los argumentos a favor del formato automático es que proporcionaría un estilo uniforme de fechas que muchos editores desean. Sin embargo, no puedo entender qué sentido tendría eso cuando muchos otros aspectos de un artículo seguirían claramente las convenciones de un dialecto diferente del idioma inglés; este sistema crearía conflictos dentro de los artículos y, a menos que estemos discutiendo la adopción de un formato de fecha único en todas partes, hablar de uniformidad en este contexto sugiere una visión de túnel.
    2. Otro argumento es que DA evita las discusiones mezquinas. Se supone que estamos escribiendo una enciclopedia para el mundo en general, no sólo para los editores. Todos estamos trabajando en un proyecto, así que deberíamos ver las mismas cosas que ven nuestros lectores. Una cosa es personalizar cosas como la zona horaria en las páginas de discusión y de proyectos, pero en el espacio principal, considero que esto es un principio no negociable.
    Podría decir mucho más sobre DA, pero la conclusión es: no lo necesitamos y estaremos mejor sin él. Waltham , The Duke of 14:41, 8 de abril de 2009 (UTC) [ responder ]
  245. Oppose Kennedy (discusión) 15:08 8 abr 2009 (UTC) [ responder ]
  246. En contra: me parece útil ver el formato de fecha que utiliza un editor para tener una idea aproximada de qué lado del charco está. Además, la autoconfiguración de fechas es algo realmente muy secundario. -- Armchair info guy ( discusión ) 15:11 8 abr 2009 (UTC) [ responder ]
  247. Oponerse Mantengamos Wikipedia tan simple y directa como sea posible. Apuldram ( discusión ) 17:32 8 abr 2009 (UTC) [ responder ]
  248. Oponerse El cuadro de oposición lo resume todo a la perfección para mí. Simplemente no lo considero necesario y puede resultar complicado y confuso para los recién llegados. -- Ged UK  19:10, 8 de abril de 2009 (UTC) [ responder ]
  249. Me opongo , no veo por qué es necesario y puedo ver cómo perjudica a los recién llegados. Zerter ( discusión ) 19:19 8 abr 2009 (UTC) [ responder ]
  250. Vota por esto (oponerse a una posición contraria es una tontería). Por favor, dejad de discutir y votar sin parar sobre algo de tan poca importancia. La solución de Brion Vibber me parece bien, al igual que cualquier otra variante. Por muy buena que sea, no necesitamos el formato automático de las fechas y, al parecer, no hay consenso para hacerlo. Seguramente no habría consenso para el formato automático de la ortografía. No hay más que decir, fin de la historia. Geometry guy 20:57, 8 de abril de 2009 (UTC) [ responder ]
  251. Opóngase a la confusión y a lo innecesario. Wikipedia es una cosa en sí misma. Si quiere una enciclopedia completamente coherente, haga lo que hacen los libros de referencia habituales: designe un grupo de editores que la editen por completo y abandone la idea de una obra que cualquiera pueda editar. Wikipedia tiene demasiadas reglas de edición tal y como está. Fijagdh ( discusión ) 21:10 8 abr 2009 (UTC) [ responder ]
  252. Oposición Todo el mundo debería utilizar el formato AAAA-mm-dd. Huevos de Python ( discusión ) 04:39 9 abr 2009 (UTC) [ responder ]
  253. Oposición Además de las muchas otras razones mencionadas, creo que afecta negativamente a la legibilidad. Hohenloh + 19:45, 9 de abril de 2009 (UTC) [ responder ]
  254. Me opongo. Reconozco que esto puede ser beneficioso para algunos, pero en general probablemente traerá más mal que bien. Hús ö nd 20:39, 9 de abril de 2009 (UTC) [ responder ]
  255. Me imagino que después de un esfuerzo tremendo y de la carga de un costo continuo para muchos editores y el departamento de TI, la enciclopedia entera, desde el punto de vista de los lectores, si todo lo demás se mantiene igual, prácticamente no sufrirá cambios. Sólo los editores con experiencias negativas y frustraciones continuas se darán cuenta de ello un mes o más después de su presentación. -- Karbinski ( discusión ) 20:45 9 abr 2009 (UTC) [ responder ]
  256. Me opongo a haberme acostumbrado a las fechas sin formato automático; las ventajas de vincular fechas a artículos de fechas se ven compensadas por la apariencia más limpia sin enlaces azules triviales para fechas sin importancia. Nunca he establecido las preferencias, ya que siempre es mejor, en mi opinión, ver las fechas formateadas según las preferencias del país relevante, como ocurre con la ortografía. Demasiado esfuerzo y trucos para solucionar un problema que no es el de las fechas en dos disposiciones comúnmente reconocibles. . dave souza , discusión 21:57, 9 de abril de 2009 (UTC) [ responder ]
  257. Fuerte Oposición Un detalle trivial. ¿Debería haber plantillas como {{British|color|color}}? -- NipplesMeCool ( discusión ) 23:38 9 abr 2009 (UTC) [ responder ]
  258. Oponerse Innecesario, trivial. No veo ningún beneficio por el esfuerzo que implica. Hohum ( discusión ) 17:19 10 abr 2009 (UTC) [ responder ]
  259. Oponerse Las soluciones son más molestas que el problema. No hay una necesidad imperiosa de autoformateo. -- GGG65 ( discusión ) 18:34 10 abr 2009 (UTC) [ responder ]
  260. Oponerse Si esto supone una de las siguientes consecuencias: un milisegundo más de tiempo de carga, si añade enlaces wiki adicionales a una página, si añade problemas a los navegadores antiguos, nuevos o alternativos, si supone una exigencia para los servidores wiki, que a veces ya están sobrecargados, si confunde la edición añadiendo más de 1 o 2 signos adicionales (es decir, algo como #autoformat), esta opción me parece inaceptable. Como no veo el problema, sólo aceptaré una probabilidad de 1 entre mil millones de que esto tenga efectos negativos. No creo que se pueda garantizar, por lo que me opongo. Arnoutf ( discusión ) 19:41 10 abr 2009 (UTC) [ responder ]
  261. Oponerse al formato automático de fechas puede acabar fácilmente siendo una excusa para que los editores impongan formatos difíciles de entender en el texto normal, justificándolo diciendo "si no te gusta, simplemente configura tus preferencias de formato automático de fechas". Las páginas de Wikipedia deberían estar escritas de forma que la gente normal pueda entenderlas; no deberían necesitar ser miembros registrados con varias preferencias configuradas solo para Wikipedia. -- Toddy1 ( discusión ) 21:07 10 abr 2009 (UTC) [ responder ]
  262. Oponerse a vincular fechas es una tontería sin sentido que transmite un mensaje equivocado y es feo. 2005 ( discusión ) 23:01 10 abril 2009 (UTC) [ responder ]
  263. Oponerse... EN GRAN MEDIDA Nos encanta complicar demasiado las cosas, ¿no? ¿Lo sabes? Sí... o no 01:28, 11 de abril de 2009 (UTC) [ responder ]
  264. Oponerse Una pérdida de tiempo para los editores con muy poco beneficio para cualquiera. McKay ( discusión ) 01:57 11 abr 2009 (UTC) [ responder ]
  265. Oppose Just no funciona y no es necesario. -- Itub ( discusión ) 02:37 11 abr 2009 (UTC) [ responder ]
  266. Oposición Es una pérdida de tiempo incluso discutir esto. (1) Wikipedia puede vivir sin estándares absolutos cuando existe tal variedad de usos reales. (2) Los usuarios son lo suficientemente inteligentes como para manejar esto por sí mismos. (3) Además, en las citas exactas, el formato debería ser exactamente el que aparece en el material citado. (4) Finalmente, todo este esfuerzo debería dedicarse a mejorar numerosos artículos en los que un lector no experto se pierde inmediatamente, como muchos sobre productos farmacéuticos, leyendas chinas, historia de la India, enfermedades, clima, etc. Zaslav ( discusión ) 06:23 11 abr 2009 (UTC) [ responder ]
  267. Me opongo , pero realmente creo que se debería llegar a un consenso adecuado sobre qué formato de fecha usamos en prosa, referencias, etc. Corn.u. co.piaDisc.u s.sion 07:32, 11 de abril de 2009 (UTC) [ responder ]
  268. En mi opinión, los diferentes formatos de fecha son mucho menos perceptibles que los diferentes sistemas ortográficos con los que podemos vivir. No hay nada malo en cierta diversidad. Esta no es la wiki de Simple English. -- Charles ( discusión ) 10:28 11 abr 2009 (UTC) [ responder ]
  269. En contra Estoy de acuerdo en que no hace ninguna diferencia real, lo único que hace es agregar formato extraño o enlaces molestos en todas partes. - J .Logan` t : 11:17, 11 de abril de 2009 (UTC) [ responder ]
  270. Oposición Es demasiado esfuerzo para algo trivial. De todas las quejas que he oído sobre Wikipedia, nunca ha habido una que diga "La fecha está al revés". MortimerCat ( discusión ) 11:23 11 abr 2009 (UTC) [ responder ]
  271. Oposición : por las mismas razones que señalé la última vez, el formato automático de fechas suele dar lugar a artículos con un aspecto descuidado si tenemos en cuenta la necesidad de intervalos de fechas. Por lo tanto, deberíamos formatear las fechas en función del tema, como en WP:ENGVAR . Sentido común. ل enna vecia 15:22, 11 de abril de 2009 (UTC) [ responder ]
  272. Oponerse a   la “personalización de la interfaz” es una pista falsa que induce a error: las preferencias de su sistema operativo no reescriben las páginas web y los artículos por usted. Los editores escriben el texto, los lectores lo leen. El editor utiliza el wikitexto para controlar el resultado, y una máquina no debería intentar mejorarlo reescribiéndolo basándose en ilusiones. La GPL que firmé no le da a una máquina el derecho de corregir mi contribución, ni siquiera un poco. ¿Qué sigue, incorporar un filtro de lenguaje pirata para dar a los “usuarios” más “control personal”?  Michael  Z.  2009-04-11 16:11 z
  273. Oponerse   Esto se complicará más, consumirá nuestro tiempo y atención, con poco o ningún beneficio. He visto guerras de edición como resultado de "arreglar" rangos de fechas debido al formato automático de las fechas. Tenemos cosas más importantes que hacer. -- AD Monroe III ( discusión ) 18:47 11 abr 2009 (UTC) [ responder ]
  274. Oposición – El principal problema que he encontrado con el formato automático es que es imposible formatear rangos de fechas dentro de un mes de manera que se muestren de manera legible sin importar la preferencia establecida. El formato automático solo causa problemas y no tiene ventajas, debería estar completamente deshabilitado. MTC ( discusión ) 19:43, 11 de abril de 2009 (UTC) [ responder ]
  275. Oponerse : hay demasiada confusión sobre algo que aporta un valor insignificante a los usuarios. GunnarHj ( discusión ) 23:51 11 abr 2009 (UTC) [ responder ]
  276. Me opongo por muchas de las razones expuestas anteriormente. Ti-30X ( discusión ) 01:32 12 abr 2009 (UTC) [ responder ]
  277. Oponerse -- Juliaaltagracia ( discusión ) 06:47 12 abr 2009 (UTC) [ responder ]
  278. Oposición No formateamos automáticamente cuestiones como el uso estadounidense/británico, así que ¿por qué hacer este problema? El 11 de abril de 2009 y el 11 de abril de 2009 son ambos inequívocos, y mientras un artículo sea coherente internamente , no hay necesidad de que toda la Wikipedia lo sea. Sería exactamente como formatear automáticamente a los usuarios británicos para que lean "color" donde los usuarios estadounidenses escriben "color". Parece bastante inútil. Si el software pudiera modificarse para reconocer y formatear automáticamente las fechas sin ninguna acción por parte de los usuarios (como agregar enlaces wiki o encabezados de plantilla o palabras mágicas o CUALQUIER COSA), esa PUEDE ser una buena idea. Pero la noción de que los editores deberían tener que agregar corchetes o, peor aún, una plantilla completa, a cada fecha solo para que podamos elegir si queremos que el nombre del mes aparezca primero o segundo parece más que inútil. -- Jayron32 . discusión . contribuciones 14:54, 12 de abril de 2009 (UTC) [ responder ]
  279. Oponerse por los argumentos anteriores. NSR 77 T 15:52, 12 de abril de 2009 (UTC) [ responder ]
  280. Oponerse ¿Qué necesidad hay de una característica así? No se trata de una pregunta retórica; la respuesta es ninguna. Innecesaria y trivial, básicamente como se dijo anteriormente. Andre666 ( discusión ) 17:15 12 abr 2009 (UTC) [ responder ]
  281. Opóngase como lo hicieron Scheinwerfermann (#233) y Waltham (#244). Además, el valor de ayudar a los quisquillosos editores de WordPress a ver las fechas siempre en el formato en el que están acostumbrados a verlas no compensa las molestias que esto implica. Nadie se confunde con las fechas y los editores deben ser tolerantes con el estilo. Reconsideración ( discusión ) 18:20, 12 de abril de 2009 (UTC) [ responder ]
  282. Oponerse ; demasiado esfuerzo para muy poco resultado. Hacerlo verdaderamente automático (no requiere formato especial) u olvidarlo. -- Spangineer ws  (háblame) 19:57, 12 de abril de 2009 (UTC) [ responder ]
  283. Por todos los argumentos anteriores y porque es necesaria una decisión. Hiding T 21:11, 12 de abril de 2009 (UTC) [ responder ]
  284. - Jake Wartenberg 23:49, 12 de abril de 2009 (UTC) [ respuesta ]
  285. (Aviso: me contactaron en forma privada para que contribuyera después de expresar una opinión el año pasado, y de otra manera no habría visto esta discusión) - En contra - ¿Cuál será el formato predeterminado? Si obliga a todos los artículos a usar el mismo formato, será malo: los artículos del Reino Unido deberían usar el formato del Reino Unido por defecto y los artículos de los EE. UU. deberían usar el formato de los EE. UU. por defecto. Por lo tanto, la única forma de que funcione es tener dos declaraciones de formato (una para el formato de los EE. UU. y otra para el del Reino Unido), y no vale la pena por algo tan insignificante. Agrega demasiada complejidad a la edición sin ninguna buena razón. Peter Ballard ( discusión ) 11:10, 13 de abril de 2009 (UTC) [ responder ]
  286. Oposición . No hay ningún beneficio (y sólo problemas) para la wiki. Además, los argumentos a favor no son convincentes.
    #1 Los defensores del formato de fecha alegan que el formato de fecha es necesario para extraer metadatos. Eso es falso.
    • Los metadatos no tienen nada que ver con el formato de fecha.
    • Los metadatos no son una propiedad del marcado. Si las fechas con marcado tienen metadatos y, como se deduce de ello, las fechas sin marcado no tienen metadatos, entonces (se deduce que) los metadatos deben ser una propiedad del marcado. La capacidad implícita de generar automáticamente contenido significativo a partir del marcado sería, eh, bastante milagrosa.
    • Los metadatos intrínsecos a las fechas no tienen nada que ver con la forma en que se escriben o se formatean las fechas. Independientemente de si una fecha se formateó a mano, con [[ ]] o {{#formatdate}}, la información que se puede extraer de esa fecha siempre será la misma. Por ejemplo, que "12 de abril de 2009" es un domingo, que es el día 102 del año, etc.
    #2 Los defensores del formato de fecha alegan que "el marcado de fecha ha sido identificado" (?) "como central para el desarrollo de nuevas funciones".
    • Esas "características" aún no se han desarrollado. No se puede esperar que votemos sobre software improvisado.
    • Wikipedia no es un sandbox gigante. Si los proponentes quieren desarrollar nuevas funciones, pueden hacerlo primero en otro lugar y luego volver aquí para recibir comentarios.
    • El marcado de fechas existe desde hace "casi seis años". Durante ese tiempo no se ha hecho nada al respecto.
    #3 Los defensores del formato de fechas presuponen que la automatización depende de que las fechas estén marcadas. Esto es falso.
    • No es difícil encontrar todas las apariciones de una fecha determinada. De esos 80 millones de resultados, de los cuales sólo una mínima fracción está marcada, debería resultar obvio que no es necesario marcar una fecha para encontrar referencias a ella.
    • No resulta nada difícil para un software "encontrar" fechas en un texto. No es necesario ni deseable utilizar un marcado especial. Cualquier programador razonablemente competente puede crear una rutina para analizar un texto en busca de fechas. Una rutina de este tipo no es significativamente más compleja que una rutina que busque cualquier otra combinación de palabras.
    #4 Los defensores han alegado que el formato automático de fecha (del lado del servidor) "permite una mayor coherencia". Esto es falso.
    • El formato de fecha automático como [[ ]] o {{#formatdate}} no facilita una mayor consistencia que la que se puede lograr si los editores escribieran las fechas a mano.
    • Los artículos presentan toda una gama de problemas de coherencia. La coherencia no se limita únicamente al estilo de formato de fecha, sino que también incluye el estilo de cita, el estilo ndash/mdash, el estilo de era y el estilo ENGVAR.
      MOS tiene directrices para todos estos problemas y no hay razón alguna por la que el formato de fecha deba merecer un tratamiento especial.
    • Los editores están obligados a trabajar en equipo. Esto significa que, antes de comenzar a editar un artículo, también se toman el tiempo de determinar dónde debe ir el contenido que desean agregar. Esto significa que también respetan el estilo que ya se usa en un artículo. No solo el estilo de cita, el estilo de guiones, el estilo de era y el estilo ENGVAR, etc., sino también el estilo de fecha.
    • No es tarea de los servidores garantizar la coherencia de los artículos. Lo que hace la automatización del formato de fecha del lado del servidor es permitir a los editores ignorar las convenciones de formato de fecha existentes. Los defensores del marcado de fecha venden esto como un argumento a favor de "más opciones". Pero lo que realmente quieren es una licencia para decir "¿qué me importa qué formato de fecha, engvar, era, estilo de citación se utilice? Voy a utilizar mi preferido y la tecnología debería solucionarlo". No hace falta decir que eso es escandalosamente desconsiderado y, desde un punto de vista técnico, miope.
    Resumen: No hay ningún "problema". Por lo tanto, tampoco hay nada que requiera una "solución". La solución original para el formato de fecha (DateFormatter.php) se implementó para acabar con las guerras de edición sobre el estilo de fecha. Mientras tanto, hemos obtenido unas directrices MOS bastante sólidas para ese y otros problemas de estilo, y DateFormatter.php ya no es necesario. No necesitamos otro truco para reemplazar el primero. Necesitamos que los editores cumplan con MOS, que es un "estándar de todo el sitio" ya en vigor. Si los anónimos o los novatos no cumplen con ese "estándar de todo el sitio", podemos hacer que un bot limpie sus errores. Si los editores establecidos se niegan persistentemente a cumplir con ese "estándar de todo el sitio", entonces deberíamos bloquearlos como comunidad (las decisiones de Arbcom sobre las guerras de estilo son un precedente). MOS es lo que manda, y la comunidad no necesita un drama interminable por problemas que no son importantes. -- Fullstop ( discusión ) 13:30 13 abr 2009 (UTC) [ responder ]
  287. Débil en contra. Originalmente voté "apoyo" porque creo que una mayor personalización es generalmente mejor, y porque el formato de fecha predominante "MMM DD, AAAA" parece un caso de estándares culturales estadounidenses impuestos al resto del mundo, y eso me hace sentir incómodo. Phil Bridger  ( discusión  · contribuciones ) y otros me convencieron de que ese no es realmente el caso, y que, en todo caso, este cambio atrae principalmente a los estadounidenses que no pueden lidiar con las convenciones de fecha continentales. También estoy convencido de que usar incluso un marcado ligero para embellecer algo tan fundamental como una fecha de calendario es en última instancia confuso para los nuevos editores, y no deberíamos tomar la enciclopedia de esa manera. En este punto, creo que si bien un poco de marcado de fecha como {{date|2009|04|07}} aún podría ser útil para tareas como construir tablas ordenables, no debería convertirse en la forma estándar de expresar fechas en toda la enciclopedia. Tim Pierce ( discusión ) 14:33, 13 de abril de 2009 (UTC) [ responder ]
Soy neutral en el concepto general de formato automático.
  1. Aunque no me opongo a la idea del formato automático (siempre que los editores tengan la opción de ver las fechas tal como se ingresan en la fuente y siempre que se utilice una sintaxis simple, algo como [{30 March 2008}]estaría bien, {{#formatdate:|30 March 2008}}no), me opongo al sistema actual y a la implementación de cualquier sistema en Wikipedia hasta que se demuestre que maneja correctamente los rangos de fechas, las comas después del año en MYD, etc. Tampoco quiero que se inicie una pendiente resbaladiza hacia el formato automático de palabras y similares (al menos hasta que implementemos una IA capaz de decidir qué significado de "ass" se utiliza al traducir un artículo del inglés americano al inglés de la Commonwealth, claro está). -- A. di M. ( discusión ) 06:18, 30 de marzo de 2009 (UTC) [ responder ]
  2. No apoyo la adición de metadatos en este caso. No me puedo enojar lo suficiente como para llamar a mi "no apoyo" un "me opongo". En mi opinión, no es realmente un problema. Cnilep ( discusión ) 14:28 30 mar 2009 (UTC) [ responder ]
  3. Aunque veo las ventajas del formato automático, me opongo estéticamente a ver etiquetas de enlaces por toda la página. Más allá de ese conflicto entre dos opiniones poco firmes, realmente no me preocupa el tema. -- llywrch ( discusión ) 16:22 30 mar 2009 (UTC) [ responder ]
  4. Teniendo en cuenta la cantidad de calor y luz que esto ha atraído, realmente no me importa el resultado, sólo que se resuelva de manera concluyente, de una manera u otra. Jclemens ( discusión ) 16:26 30 mar 2009 (UTC) [ responder ]
  5. Suena útil, pero ya tenemos demasiado marcado wiki en nuestros artículos, hasta el punto de que un usuario inexperto no puede editar páginas debido a los cuadros de información y las referencias. Cuando salga la nueva interfaz gráfica de usuario el año que viene, entonces puede que sea aceptable añadir formato automático. - Peregrine Fisher ( discusión ) ( contribuciones ) 18:08, 30 de marzo de 2009 (UTC) [ responder ]
  6. Estoy harto de este estúpido debate sobre las fechas. Volvamos a escribir artículos y a mejorar la sustancia del contenido. Aboutmovies ( discusión ) 21:28 30 mar 2009 (UTC) [ responder ]
  7. ¿Qué, esto todavía no se ha resuelto? Espera, no es ninguna sorpresa. Lo que necesita este problema es alguien competente en PHP y muy familiarizado con MediaWiki que pase alrededor de un mes trabajando en código que cubra tantos casos como sea posible, y luego regrese y presente su modelo + casos de prueba. Mientras tanto, no me importa nada, y tengo mejores usos de mi tiempo que discutir sobre algo tan absolutamente trivial. 「ダイノガイ千?!」(Dinoguy1000) 22:16, 30 de marzo de 2009 (UTC) [ responder ]
  8. Enlazarlos, no enlazarlos, ¿qué importancia tiene eso? Una vez descubrí que me gusta que las fechas estén en bonitos enlaces azules, pero la mayoría de las veces no sirven para nada. Terminemos con esta discusión para que podamos seguir escribiendo nuestros artículos sin enlazar o desvincular fechas una y otra vez. -- クラウド668 07:24, 31 de marzo de 2009 (UTC) [ responder ]
  9. Mucho ruido y pocas nueces J04n ( página de discusión ) 01:13 1 abril 2009 (UTC) [ responder ]
  10. Según A. di M. arriba. Ruslik ( discusión ) 07:17 1 abr 2009 (UTC) [ responder ]
  11. En realidad, me gusta la idea del formato automático y estoy de acuerdo en que es una buena manera de avanzar (y sí, creo que podría eventualmente afectar a BC/BCE y otros gustos personales de formato para crear una enciclopedia más consistente y profesional. Las preocupaciones sobre "demasiado trabajo" son ridículas - obviamente hay alguien por ahí a quien le gustaría hacer esto, la mayoría de las fechas están envueltas en plantillas y las que no lo están podrían etiquetarse fácilmente con AWB , he realizado varias ediciones similares aplicando {{ convert }} a múltiples artículos con pocos errores que tenían más que ver con mis propias deficiencias. Sin embargo, no parece que haya ningún uso demostrado de esto y preferiría verlo hackeado en wikilabs o en algún otro lugar primero antes de aceptar tener esto. -  ΖαππερΝαππερ  Babel Alexandria 08:08, 1 de abril de 2009 (UTC) [ responder ]
  12. En principio, me gusta la idea, pero cuanto más plantillas añadimos a los artículos, más saturan las ventanas de edición con el marcado wiki y más intimidante resulta incluso la edición simple de Wikipedia para los principiantes. Profesor marginalia ( discusión ) 16:54 1 abril 2009 (UTC) [ responder ]
  13. I'd don't mind either way whether dates have autoformatting options providing it doesn't rely on date linking. --Phil Holmes (talk) 08:21, 2 April 2009 (UTC)[reply]
  14. I have no objection to allowing use of the {{#formatdate}} function, as long as it is not mandatory. Using it doesn't seem to do any harm, since unregistered users will see the same thing they would see if the date were not formatted at all, and registered users can use the preference setting if they wish. It also has the minor benefit (apparently, based on limited testing) of properly formatting at least some mis-formatted dates (like changing "April 2 2009" to "April 2, 2009"). Just don't go around berating editors who type in dates in plain text! --R'n'B (call me Russ) 13:26, 2 April 2009 (UTC)[reply]
  15. Provided the date is specified as 7 March, 1997 or March 7, 1997 rather than 7-3-97 or 3-7-97 then there is no major problem. PRL42 (talk) 16:10, 2 April 2009 (UTC)[reply]
  16. Voting Breeds Sock Puppets. — Preceding unsigned comment added by Gsonnenf (talk • contribs)
  17. I am neutral in that ultimately I do not really care. However, I am leaning towards oppose because autoformatting is only useful to registered editors, not the general reader. Bendono (talk) 18:09, 3 April 2009 (UTC)[reply]
  18. I am neutral because I see a balance of competing valid interests and can go along with whichever prevails. However I am strongly opposed to the notion in evidence in the subtext of many of the responses that elimination of date formatting eliminates the need for special markup for some dates. Used in narrow contexts such as with infoboxes, there is a family of templates whose only purpose currently is to emit microformat information. There have been a great deal of erroneous remarks that use the term metadata to associate this information with search and the like. Wikipedia also emits coordinate microformat data, and in the same way that it allows interaction with internet map applications, date/time templates allow interaction with internet applications that understand time data. With that said, I share the opinion of Professor marginalia and Peregrine Fisher expressed above and believe that edit text should not be needlessly cluttered with templates or other complicated markup. Even plain wikitext is a significant barrier and stands in the way of the core principle that everyone is an editor.-J JMesserly (talk) 16:37, 4 April 2009 (UTC)[reply]
    Neutral, per J JMesserly who makes excellent points just above. I don't really mind either way, but I agree that Wikipedia articles are getting too complicated when viewed in an edit box. Hiding T 14:02, 5 April 2009 (UTC)*Addendum. Just looked at the talk page and seen all the inane arguments over what consensus is. Please add my vote to whichever side gets the biggest pile in the hope it settles this once and for all and all parties accept it with good grace. Hiding T 10:14, 6 April 2009 (UTC)[reply]
  19. My, my. Count me among the don't care crowd. I will never link another date again, regardless of the outcome of this debate. I've spent many tedious moments on WP linking dates for autoformatting at the demands of review processes within WP. I am sure if it ends up being policy, someone else will be happy to waste their time doing it. Me, not so much. Glad I got to opine though.--IvoShandor (talk) 06:24, 6 April 2009 (UTC)[reply]
    What I am saying is, as long as I don't have to do anything I don't care what we do. Thus, the neutral.--IvoShandor (talk) 13:20, 6 April 2009 (UTC)[reply]
  20. Neutral - I barely understand how it works. Deb (talk) 18:05, 6 April 2009 (UTC)[reply]
  21. Neutral - I find this a bit unnecessary (for myself to get involved in, ie.). prashanthns (talk) 06:00, 8 April 2009 (UTC)[reply]
  22. As long as months are spelled out and not abbreviated as numbers (which autoformatting can't separate anyway), there is no real risk of confusion. At the same time, giving people display options is not a bad thing, so long as it does not place an undue burden on the site. Ham Pastrami (talk) 05:57, 10 April 2009 (UTC)[reply]
  23. Most readers aren't going to be logged in so there isn't much point in going out of our way to get the dates to be autoformatted. However, a lot of people won't really notice the difference between 1 January 2009 and January 1 2009 and I don't mind if some pages use this syntax. Tra (Talk) 10:37, 11 April 2009 (UTC)[reply]
  24. I tend to favor adopting ISO 8601 (yyyy-mm-dd) which could be autoformatted according to the user's preference. Though not widely used in prose (and recommended against, I believe) it's intuitive and easy to type. I oppose making the editor master a template just to write a date. I strongly oppose bluelinked dates, which are trivia. Thus, I'm not sure whether I should support or oppose autoformatting, as I'm not sure if my preference is on the table. Fletcher (talk) 14:21, 11 April 2009 (UTC)[reply]
  25. In principle, I would tend to support autoformatting if it did not include autolinking (as it has heretofore) and the option is extended to all readers. Since this debate resurrected itself last summer, the two main reasons for deprecating datelinking have been the “sea of blue” and, more particularly, the fact that only a tiny percentage of readers – those who are registered users – even have the option of viewing dates in their preferred format; furthermore, the use of this option prevented registered users (who comprise a significant portion of the most active editors) from realizing what a mess the date formats in a given article are – which is what the great majority of readers actually see. There was always considerable support for a developer-created solution that would permit all readers to be able to set a preference; this would, of course, not remedy the mixed-format mess, but would at least allow readers to choose to not have to view these problems. To the extent that autoformatting of dates is not available to all readers, then it behooves editors to rely on the raw text format to know what may need cleaning up. The crux of the problem, then, is how resolvable the coding of such an autoformatting parser or template function is. Folk more knowledgeable than myself seem to be falling out on both sides of that issue, so until there’s a specific proposal on how to accomplish that, this whole poll is moot. Askari Mark (Talk) 00:50, 12 April 2009 (UTC)[reply]
Comments regarding autoformatting
  • No-one above appears to have conflated the two. Ohconfucius (talk) 01:56, 30 March 2009 (UTC)[reply]
  • A majority of the "oppose" !votes appear to have conflated the two. — Arthur Rubin (talk) 02:07, 30 March 2009 (UTC)[reply]
  • To quote someone I know: "I wasn't going to reply unless an idiotic argument was presented by someone. Congratulations." Ohconfucius (talk) 03:21, 30 March 2009 (UTC)[reply]
  • Wow. I am currently seeing 3 who mention linking in the rationale as if it was implied by autoformatting, but also give unrelated reasons (Awadewit, Bishonen, Bzuk), 3 who give no rationale (Donald Albury, Juliancolton, Chrishomingtang), and 29 who give a rationale that doesn't suggest they are confused about this. Since when is 3:29 a majority? Perhaps you are confused and think that this is about autoformatting without markup? Then read above under "What is date autoformatting?" It is not presented as an option. --Hans Adler (talk) 08:26, 30 March 2009 (UTC)[reply]
  • Arthur Rubin is a mathematician, so I'm sure he knows what "majority" means.--otherlleftNo, really, other way . . . 03:38, 31 March 2009 (UTC)[reply]
  • And why must I give yet another rationale when so many have already been given. This is not something like AfD, where the weight of arguments invoking policy should be decisive, this is a preference poll. -- Donald Albury 12:34, 30 March 2009 (UTC)[reply]
  • I've stated my opinion several times in the past, so I feel there's no need to provide a rationale. This is, as the title suggests, a poll. –Juliancolton | Talk 19:22, 30 March 2009 (UTC)[reply]
  • Agree that this is a poll and tons of reasons have been given by others already.—Chris! ct 20:24, 30 March 2009 (UTC)[reply]
  • Sorry, I meant no offence and no rationale is of course perfectly OK. The only problem is that in a situation where some editors give rationales that prove they are confused ("I hate autoformatting because I hate the sea of irrelevant blue links") with no clue how they would have voted if they were not, every vote without a rationale will potentially be discarded by those who don't like the result of the poll.
  • Ah, ye of little (good) faith. -- Donald Albury 16:11, 31 March 2009 (UTC)[reply]
  • GrahamColm (talk · contribs), above, seems to have just mistaken the two as intertwined. —Locke Cole • t • c 13:19, 30 March 2009 (UTC)[reply]
  • I'm concerned about this too. If the proposal is defeated, so be it, but it would be a real shame if it were defeated because a large number of editors were still under a wrong impression of the implementation details. Tim Pierce (talk) 13:13, 30 March 2009 (UTC)[reply]
  • Bots can easily recognise and remove double-square brackets around dates. Adding date coding (especially complex coding) must be done contextually (instance-by-instance).  HWV258  01:53, 30 March 2009 (UTC)[reply]
Actually, I'd bet that a lot of the basic markup could be done by bots, if all they have to do is recognize dates and enclose them in something trivial. The actual choice of what format to use would need human intervention, but that could be separated from the markup around particular dates. Gavia immer (talk) 02:53, 30 March 2009 (UTC)[reply]
Agreeing with the above. Bots should be able to easily recognize dates, marked up or not, through the use of regular expressions.-Jeff (talk) 03:13, 30 March 2009 (UTC)[reply]
(To the above two posts) The edit comment of "Most of the work could be bot-accomplished" is the key. How is most defined? Also, "The actual choice of what format to use would need human intervention" is a whopper in terms of slowing down the process. Anyhow, doesn't change the basic point that bot-removal of date formatting is trivial (to get back to the original post).  HWV258  03:23, 30 March 2009 (UTC)[reply]
If you separate the recognition of formattable dates from the format control, it's no big deal - just add a {{DEFAULTDATEFORMAT}} (or whatever name) parameter that works like {{DEFAULTSORT}}, appearing once per article to control the default date display format. Then you can add separate markup to actually set off dates, with an option to set the default display format for that one date. The sticky bit is that dates in direct quotations shouldn't be autoformatted, so a bot solution would have to recognize when to skip marking those up. A bot that got this even 90% right would leave very little work for human editors to slog through. Gavia immer (talk) 04:20, 30 March 2009 (UTC)[reply]
With your response above, you've confirmed the validity of my initial response to the original question (you do remember the original question?). Please take this up on a talk page somewhere—we've been discussing these sort of issues for months now. Thanks.  HWV258  06:10, 30 March 2009 (UTC)[reply]
  • Isn't that an argument for auto formatting? Here we have a system that removes the need to argue (ever!) over which format to use, and it's a simple software solution. —Locke Cole • t • c 13:44, 30 March 2009 (UTC)[reply]
  • No it is not. If IPs—the majority of Wikipedia readers—cannot choose their preference then autoformatting is not a good option. The only way to prevent IPs from getting a horrible mess of different formats is to choose what they see. If we do that, we might as well choose the style for everyone or completely standardise all dates into one format. Rambo's Revenge (How am I doing?) 14:23, 30 March 2009 (UTC)[reply]
  • Part of the current proposal is that there would be a Wikipedia-wide default format setting (most likely DMY) for everyone who has not set a preference, including IP users, and a magic word so a particular article can change the default (i.e. to MDY) when that is appropriate per WP:ENGVAR. Then user preferences override the default for that user. This has been said time and time again, which is why can't in good faith understand why opposers keep claiming IP users will see some sort of mish-mash. I also find a claim that every IP user has to be able to set a date preference spurious, as we have an easy way for anyone to set any preference: register an account. Anomie⚔ 15:05, 30 March 2009 (UTC)[reply]
  • But the point you are missing is that in order to maintain consistency for all users, every date on a page needs to be coded (in order to be rendered properly based on various preferences). The problem with "every date" is that it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP. Date ranges and slashed-dates are just two examples, but also difficult is to precisely detect the comma in US date formats. These issues remain unaddressed—after months of debate, and lots of examples demonstrating the problems can easily be found. Many people voting "support" are unaware of the technical issues involved. (Incidentally, I don't blame them so much as these issues are not easily grasped by people who have not been involved with the debate for some time.)  HWV258  00:46, 31 March 2009 (UTC)[reply]
  • Hi, I'm a computer programmer. Are you? The reason I ask is that you assert that "it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP", which strikes me as a statement that would be made by someone who doesn't actually know what they're talking about. There is no real "detecting" necessary; someone just needs to come up with a syntax for specifying date ranges, slashed dates, trailing commas, and the like. For example, {{#formatdate:1 January 2009/2 January 2009}} could be the format for a slashed date, and output as "1/2 January 2009", "January 1/2, 2009", and so on based on the active format; {{#formatdate:1 January 2009–10 January 2009}} or {{#formatdate:1 January 2009|10 January 2009}} could be the format for entering a date range, and output appropriately (there could even be a preference for "1 January 2009 – 10 January 2009" versus "1–10 January 2009" style output, if people wanted it). With a little more effort, any of the (unambiguous) output formats could also be accepted as input. The need for the trailing commas could easily enough be specified as {{#formatdate:1 January 2009|,}} or {{#formatdate:January 1, 2009,}}. Something else that I personally would like to see is a "{{#formattabulardate}}" function, so people who would prefer to see dates in tables and lists as 2009-01-01 versus 1 Jan 2009 versus the full 1 January 2009 could set a preference for that. It's not particularly hard to do any of that, but why should someone bother when the discussion is full of people (not necessarily you, don't take this personally) who will oppose everything without end, drowning out any other discussion, to the point of WP:POINT? Anomie⚔ 12:26, 31 March 2009 (UTC)[reply]
  • Actually, I am a programmer (and your question indicates to everyone that you haven't been following the debate over the previous few months). I was the only one who actively push to get a specification for auto-formatting established (here), however nothing came of it (despite a myriad of suggestions in various locations—similar to yours above). You do understand that all your examples above simply will be thrown into a pot—a pot that is already full to the overflowing with similar suggestions—however a pot that has so far failed to provide anything nutritious (or in the least bit edible) for the community. As you have not responded to my point "every date on a page needs to be coded" I'll assume that you have understood that, and are in favour of it. Please consider a page such as this one that has over 700 dates (in many different formats), so to apply formatting to all dates (similar to {{#formatdate:8 January 1705}}) is quite an undertaking (an undertaking that has had no analysis in terms of viability). The people you mention "who will oppose everything without end" are actually people who have thought through all these issues and have come to the considered conclusion that simply entering dates using plain text solves all significant issues, and has no syntactical complexity for the wider editing community. In addition, I belong to the group of programmers who believe it is inappropriate (and downright unprofessional) to commence coding without (at least a functional) specification. A large part of the reason for the mess we are currently in is the (well-intentioned) introduction of code that had no specification, let alone community consensus.  HWV258  23:19, 31 March 2009 (UTC)[reply]
  • Of course I haven't followed the debate, certain people have made the situation akin to diving for pearls in a cesspool. I don't understand how you can claim it's so difficult for code to solve the problems you raised in your paragraph above, though, since you state that you are familiar with programming. I also don't see any particular problem with List of compositions by George Frideric Handel; sure, it might need a bit of human attention to get everything marked up, but I see nothing in there that would cause any trouble for a well-written formatter; or is the whole of your concern there that someone would have to do a little bit of formatting work? As for those "who will oppose everything without end", either we're talking about different people or our views are so opposed that we will never reach an agreement on the matter. Anomie⚔ 02:10, 1 April 2009 (UTC)[reply]
  • I didnt' claim "it's so difficult for code to solve the problems"—rather it is looking increasingly likely that it is impossible to specify the problem in the first place.  HWV258  04:18, 1 April 2009 (UTC)[reply]
  • How is it impossible to specify what the a bot would do? The bot would find plain dates, pre-existing or entered by new users, and convert them to a standard form inside an autoformat bracket. Regular expressions already exist for finding dates in widely used forms. If the date was ambiguous, such as 07-03-02, it could inform wikignomes via wiki: page or any other method, who could manually fix it, helping in the already existing task of removing ambiguity from Wikipedia. The scope of the bot and implementation seem completely clear, maybe 5 hours coding tops on an existing framework.Gsonnenf (talk)
I think the bot would have to be quite conservative. Spend an hour or so trying to devise a syntax for date formats. After doing so, how to work out ambiguous dates— or at least discover that they are ambiguous and mark them so. Then partial dates such as "April 2009" or "2009". (oh, whoops, it 2,009 kilometres (1,248 mi)). Then quoted dates which must be left alone. Then perhaps the French Revolutionary Calendar. It is *not* trivial. I am in support but I think it is best left to human markup rather than a bot. For sure, have a bot gather the info after it's been marked up, I'm all for that. But not guess what is, or is not, a date. SimonTrew (talk) 03:41, 8 April 2009 (UTC)[reply]
I agree the bot would need to be conservative. As I understand it partial dates aren't used with date autoformat, please correct me if I'm wrong. When you say "Spend an hour or so trying to devise a syntax for date formats." do you mean thinking of how to have the parser recognize them? If so, this problem has already has a published solution. Nested quotation recognition is also a solved parser problem. The logic code for determining ambiguity of format in recognized dates is simple as a couple if/then/and statements. This still looks like a simple task, I'm uncertain as to what you mean by "trivial" as it has different meanings in different science fields. I could see how a new coder or one without exposure to modern parsing libraries or parsing exposure may see this problem as complex. With proper knowledge, which I'm sure many coders on Wikipedia have, the solution is simple to implement. I would prefer conservative date changes by bots with human confirmation. This would ease the burden and time constraint on humans. Manually verifying a date on a page would probably take 5-10 seconds, where in going through the sequence of changing them could take about 5 to 10 times as long (depending on server conditions).Gsonnenf (talk)
  • "How is it impossible to specify what the a bot would do?"—this is wandering from the original point (i.e. I didn't mention bots). Please re-read my points.  HWV258  02:00, 9 April 2009 (UTC)[reply]
  • I re-read your points and find them moot. The vast majority of date forms can be easily recognized. I disagree with your statement that "every date on a page needs to be coded". Date forms that are intentionally abiguious or not well formed (e.g. year 197x ) should either be clarified manually or left alone. Autoformatting would only need to be applied to well formed dates. Any date that can be recognized unambiguously, (jan 16, 1973, 10/22/1001) could be easily recognized by both humans and parsers. So in this case it is not longer "extremely difficult to define rules needed in order to detect all the different types". The comment "Date ranges and slashed-dates are just two examples, but also difficult is to precisely detect the comma in US date formats" is not correct, these can be easily identified using a parser and regular expressions. The above comment is also very suggestive of a bot, which contradicts your statement "I didn't mention bots". Unless of course you meant that humans would have a hard time "detecting the comma in US date formats", which is complete nonsense. So as it turns out my above argument does not wander from the original point. Unless of course you wandered from the original point in your above statements. If that is the case, please present your original point and present an argument that does not "wander from the original point".Gsonnenf (talk)
  • "I disagree with your statement that "every date on a page needs to be coded"" leads me to believe that we are talking about different things (and your disagreement probably indicates you have not been following the debate over the previous number of months). The point about coding all dates is that it is impossible to guarantee date rendering consistency in an article that contains at least one coded date—but with not all dates being coded in the article. It has been clearly understood by all that you either code all dates in an article, or you code none. If you are suggesting that coding isn't necessary because a page pre-processor can parse (and reformat) all dates in real time—then you are probably the first to do so. These current RfCs are not to do with bot activity (that debate will come after these RfCs are complete).  HWV258  00:16, 12 April 2009 (UTC)[reply]
  • It sounds like your suggesting that "It has been clearly understood by all" that dates containing (in no particular order) Months/day/year and month/day and all other forms, must be subject to autoformating. This is not consistent with the autoformating Background statement that addresses only MDY/DMY format under its definition "What is a date format?". The entire primary statements of Summary and Pro's only mentions "DMY/MDY" format. The con's section specifies incomplete dates forms of type MD as a possible extension to the proposal, "(double the number of keystrokes—even more if |dmy/md is added)", demonstrating its not part of the initial scope. So when you say "its clearly understood by all that you ... code 'all' dates", you are contradicting the primary background statement if you include partial dates in your definition of dates. It appears you are constructing an argument via false dilemma by asserting all people recognize that ALL dates, included partial dates must be encoded or none at all. This of course is not true as demonstrated by the primary statements on autoformatting.Gsonnenf (talk)
  • Please read the history of the debate (over the previous many months). You are "arguing" in isolation and clearly don't have all the background information at your fingertips. All this has been covered, and I have no appetite for repeating here what has been covered (to death) many, many times before. If you need more help to understand the background of the debate, please take it up in a different forum—I'll be more than happy to attempt to bring you up to speed on the salient points. Cheers.  HWV258  22:56, 13 April 2009 (UTC)[reply]
  • The IPs would not get a bunch of different styles since the feature would provide a standard default for them. Also, developers have mentioned using Javascript to allow IPs to set a preference, though no developer has yet worked on that solution.—Ost (talk) 15:06, 30 March 2009 (UTC)[reply]
  • *sigh* If you actually read my last post I never claimed IPs will get a mish-mash of styles. I said that the only way to prevent them getting that is to choose their preference for them. I then said that there is no point in choosing a standard style for them, because it would need to be agreed upon. If we can agree a choice for that, we should just implement that choice as the date style across Wikipedia without autoformatting, because that would give real consistency. I am well aware of what is going on and am not fond of other users trying to twist my words towards their !vote. Rambo's Revenge (How am I doing?) 16:55, 30 March 2009 (UTC)[reply]
  • You have presented a false dichotomy in assuming that we would have to pick one format for all of Wikipedia for IP users, with no possibility of overriding that where WP:ENGVAR calls for another format. So yes, you're not quite claiming "IP users will get a mish-mash of styles"; you're claiming "IP users will get a mish-mash of styles unless we get rid of WP:ENGVAR on this issue". Anomie⚔ 22:19, 30 March 2009 (UTC)[reply]


I'm with you. I think the server should do all the work, recognizing dates for what they are and regurgitating them for viewers to match their preferences. Editors should only have to make sure that dates are consistent throughout the article. I'm against using some kind of template or marker or formatting. Binksternet (talk) 06:01, 3 April 2009 (UTC)[reply]
That is impossible: It would result in changing of dates in exact quotes which contained dates by default. You should never change an exact quote, but no software is clever enough to unambiguously spot a quote, even if put in by a newbie that formats it in a slightly unexpected way. Creating a way to bypass this is not a solution, because the mechanism to do so is going to be obscure, and most editors won't know it. It ruins usablity for editors, in order to allow a tiny minority of people to select which of two date formats they like. Shoemaker's Holiday (talk) 06:57, 5 April 2009 (UTC)[reply]
why are you interpreting Oppose #3 and #73 as "think[ing] that it's talking about linking"? i agree that there are a couple of !voters who appear to be confusing the two issues and a couple of "hanging chad !votes", but both Oppose #3 and Oppose #73 appear cognizant that linking and autoformatting are two different issues.
either way it's not a high rate of confusion - that's good! and the "hanging chad !voters" still have time to clarify their views if they care to.
meanwhile, it's right that some !voters are saying they don't want logged-in editors to see different content than unlogged-in users. you disagree with that viewpoint, but that doesn't mean their !votes "don't count". Sssoul (talk) 07:21, 31 March 2009 (UTC)[reply]
Sorry; either I made a mistake; they changed their !votes, or the !votes got renumbered. Still, the purpose of this poll is to find WP:CONSENSUS, and I don't see even a clear supermajority for oppose (yet). As not wanting logged-in editors to see different content than unlogged in users, one might argue that it's a reason contrary to policy as defined by the developers. We would need to remove the gadgets and javascript customization. I'll post more on the talk page. — Arthur Rubin (talk) 16:06, 1 April 2009 (UTC)[reply]

Good grief! how hard can it be?. The whole formatting thing is a no-brainer. Simple fact is, if functionality is provided for autoformatting it can be provided to most IP users too with simple preferences option for them via cookie system or countless other ways. Search engines, most news sources and millions of commercial sites have been doing it since Jesus was a small boy. Come down to it, autoformatting also allows the potential to do away with the linking argument completely because it can be controlled by a users preferences as well. Want to link dates? switch it on via preferences. don't want them linked? leave it off. And don't bore me with the non-logged in users rubbish - most of them a: don't care, b: have cookies turned on (or are unaware of their presence) or c: know how to allow for cookies by site. BOTs to do the bulk conversions to simple syntax (say YYYY-MM-DD or #dYYYY-MM-DD) and wikignomes will make short work of the rest. Default presentation for those who haven't set it (maybe with a bit of fancy footwork detecting where they are accessing from to feed them American or ISO format by default). Doing something is unlikely to make it more inconsistent than it currently is.--ClubOranjeT 08:08, 3 April 2009 (UTC)[reply]

I think it is accepted on all sides that there will be bots and templates to assist (and hopefully not to destroy). If it is relatively relaxed and gets it right most of the time, like Template:Coord or Template:Convert, I don't see it being a big problem. But like those, you don't *have* to use them, hence my support; they are nice things to have. In a way I can't see why this even goes to a vote since I can't think of much of a reason, beyond finding user preferences, why this can't all be done in a template. SimonTrew (talk) 01:46, 7 April 2009 (UTC)[reply]
Actually now I am wondering whether this is in the purvue of Template:Convert. A date is only a measure after all, and its means of expression is its unit of measure. That's probably outside the scope of this vote, though. It's an interesting question to ask those in the "Oppose" camp; do you want to get rid of Template:Convert, even if you don't use it on every single measure you write? SimonTrew (talk) 01:50, 7 April 2009 (UTC)[reply]
SimonTrew, this hasn't gone to a vote. We don't vote here. See the "!vote" terminology people are using? That's why. Also, I don't agree with your comparison of this present issue to Template:convert. The similarities are superficial and few, as it seems to me. —Scheinwerfermann T·C02:32, 7 April 2009 (UTC)[reply]
OK, so I suppose that's why it says at the VERY TOP of the article Please indicate your vote under ONE option. I never claimed it was a formal, binding, vote.
The similarities are superficial and few precisely because time is just another dimension that can be relatively easily incorporated into the Convert template, or if not, another template can be made analagous to it. And I have worked designing and implementing very complicated units of measure conversion systems, and I know they are not easy. SimonTrew (talk) 02:51, 7 April 2009 (UTC)[reply]

All Support entries that are founded on reader choice should be disregarded when finalizing the findings of this RfC. What reader choice? The reader gets the site default, or the contributing editor's choice. Remember that registered users = subset of editors, and in turn editors are a tiny subset of readers. All Support users who clamor that the reader need only edit a setting should be deliberateley ignored by the rest of the community for a period no shorter than the time it takes defeat any and all proposals in support for auto-formatting. --Karbinski (talk) 21:38, 9 April 2009 (UTC)[reply]

Sorry, but that's not valid. There is no requirement that you must edit if you register; anyone - anyone - can register an account, and if they choose to use that account to read only, so be it. Accounts can be useful to readers who wish to use the gadgets, the watchlist, different skins, and so on. --Ckatzchatspy 21:49, 9 April 2009 (UTC)[reply]
Sorry about that, but if we leave out the middle, it is correct: Remember registered users are a tiny subset of readers. Not that it has bearing, but registered users are also a subset of editors. Karbinski (talk) 21:57, 9 April 2009 (UTC)[reply]

Many of the contra arguments speak to the issue that most readers are anons. I know from experience that people assume the only reason to register for an account is to make edits. If there were tangible benefits (like getting standardized dates, watchlists, and so on) and those benefits were promoted to readers, we might get more editors. And once they have an account, they might be more obliged to make an occasional edit. And that could lead to editing as a hobby, until they are fully assimilated into the collective. (Oops! Been watching too much Star Trek perhaps?). The point is, anything that is good for editors is ultimately good for the readers, too. --Willscrlt (→“¡¿Talk?!”) 14:14, 13 April 2009 (UTC)[reply]

Responses
  • I think you've misunderstood me (or I've not been clear) - my thinking is that by using a template for dates it will discourage the entry of dates as DD/MM or MM/YY, not that dates will no longer be displayed as DD/MM or MM/YY. I agree that this problem isn't going to go away completely, but it should be alleviated as editors get into the habit of specifying dates in terms of {{... day=2|month=3| ...}}, instead of just typing "2/3/09" and hoping that whoever cleans up after them magically knows whether the date is DD/MM or MM/DD. Cheers, This flag once was redpropagandadeeds 12:53, 31 March 2009 (UTC)[reply]
Other than imposing a site-wide single format, as the developers have suggested, how do you propose to ensure all articles are consistent with one another? Either we go to a single standard, or we persist with the first-past-the-post "this is American no it's international" methodology. If the latter is the case, it is only prudent to provide some method of presenting a uniform, consistent look. --Ckatzchatspy 02:28, 31 March 2009 (UTC)[reply]
Sorry, I'll be more clear. I edited my above post. Dabomb87 (talk) 12:47, 31 March 2009 (UTC)[reply]


Most of the arguments against autoformatting seem to boil down to "this would be a lot of work, and there is no advantage in it for me". I fail to see how this is an argument for forbidding those who do care about consistency from doing the work. Why does this have to be framed in terms of either "everybody must use this markup" or "nobody is allowed to use this markup"? That's not the wiki way. The wiki tradition would be to encourage people to contribute even if they can't be bothered to use the more complex markups, and then let others insert advanced markup if they care to.

What active harm do all of you opposers suffer because someone else adds autoformatting? It won't require you to lift a finger either way. –Henning Makholm (talk) 11:20, 31 March 2009 (UTC)[reply]

This is an important point. Why cant autoformatting be implemented and later have a discussion about whether the MOS should encourage its use? The first section to this poll should have been left until after implementation when users can see what it actually involves. I seem to remember that {{cite...}} came about this way, and is probably more difficult for unregistered users to edit and breaks up the text far more than this proposal. |→ Spaully† 12:49, 31 March 2009 (GMT)
Yes but {{cite...}} provides an important - one might even say essential - feature for an encyclopedia. This more than justifies the cost in terms of difficulty of use and so on that the markup introduces. Date autoformatting on the other hand provides at best an extremely minor cosmetic tweak. Most people don't care what formats their dates are written in. They will even use a variety of formats in their own writing or speech without a second thought. The number of people who are actually annoyed by reading a date in a format they don't like must be extraordinarily small. These pedants are considerably outnumbered by those like myself who find needlessly complicated markup annoying, or who are annoyed by the excessive linking and sometimes anomalous results created by poorly implemented date autoformatting. Hawthorn (talk) 23:38, 31 March 2009 (UTC)[reply]
The number of people who are actually annoyed by other editors inserting date markeup must be even extraordinarily smaller. Even if you yourself find it annoying to enter such markup, I don't see how it can conceivably annoy you to let other people do it. Nobody is proposing to say that you should enter the formatting yourself if you don't feel like it, but how can it possibly disturb you if other people do so? Again, the proposal is about NON-LINKING autoformatting, so there will be no excessive linking to annoy you. –Henning Makholm (talk) 14:35, 1 April 2009 (UTC)[reply]
Henning Makholm seems to be overlooking the fact that anyone who wants to edit an article has to deal with the markup other people have inserted - even if "deal with it" only means "figure out how to edit 'around' it". it can be extremely daunting. many people are saying that date-format preferences are not important enough to justify even the double-bracket markup it now uses, let alone adding even more markup (a la {{formatdate|12 December 1981}} to every date in the encyclopedia.) Sssoul (talk) 07:08, 2 April 2009 (UTC)[reply]
Once the formatting is there, it is not daunting at all. On the contrary, it is extremely self-documenting how the markup you quote works, and I cannot imagine anybody using more than a quarter second thinking "hm, it says formatdate, wonder what that means ... ah, flash of brilliance, it probably is something about formatting the date that comes after.". Now, I can understand not wanting to go around remembering how the markup works, and thus not wanting to enter it from scratch, but really, anybody who have trouble noticing and editing around a markup as clear and unambiguous as the one you show probably wouldn't be able to stitch together a coherent sentence for the encyclopedia in plain prose.
The double-bracketing is annoying because it creates needless bluelinks in the output that are hardly ever relevant in context. That is annoying. But a small bit of really, easily, self-documenting markup to make live easier for the (perhaps few) people who care about it? Not at all. –Henning Makholm (talk) 11:32, 2 April 2009 (UTC)[reply]
okay, so you don't find it daunting or annoying to have to wade through markup that you perceive as unnecessary; other people do find it daunting and/or annoying. it's one of those "different opinion" things, and saying "no it isn't" doesn't change that. peace Sssoul (talk) 07:37, 3 April 2009 (UTC)[reply]

(In response to support vote # 82) Sorry UC_Bill, but you can't have it both ways. You removed the demo page that could have shown the community how date ranges (and hopefully date slashes) would have worked, and then you claim the programming is easy ("10 hours"?). Please re-establish the demo page if you really have got it going, otherwise you'll have to understand why I'm entitled to treat your claims above with a healthy dose of scepticism. To other voting parties, please note that what is proposed is far more than "four brackets ([[ ]]) around dates" (as even the post before UC_Bill's indicates). I'm not suggesting that you (are you back?) or perhaps other programmers couldn't get something going to handle individual cases, however as has been demonstrated over more than three years, it is increasingly difficult to not only get the basics of auto-formatting right, but seemingly impossible to specify how auto-formatting should work for the many ways that dates are represented on WP.  HWV258  21:57, 31 March 2009 (UTC)[reply]

(In response to oppose vote # 138) "I have never come across a web information source or news provider that worries about this enough to give readers an option as to how to display the date"—well spotted; a very good point. In terms of "MMM DD, YYYY all round", there is no need to be so dictatorial, as very often an article will lend itself to "DD MMM YYYY", in which case, that can simply be the format of choice for the page in question. Is it that much of a worry to see dates in the "DD MMM YYYY" format in the England article and at the same time to see dates in the "MMM DD, YYYY" format in the USA article?  HWV258  23:33, 31 March 2009 (UTC)[reply]

It's no worry at all to me, as I am from a country (the UK) where both formats are used interchangeably. If you reread my post above (oppose 138) you'll see that The Times, regarded for a long time (at least before Rupert Murdoch bought it) as the UK's newspaper of record, uses MMM DD, YYYY, so why does the Wikipedia article about England lend itself any less to that format than the other? It's a myth that there is any consistent standard outside the United States, so why not just follow the standard that is used exclusively in civilian life there, and used interchangeably with DD MMM YYYY everywhere else where English is used? Phil Bridger (talk) 00:24, 1 April 2009 (UTC)[reply]
I'm not sure if I'm following any more (my confusion above started with the word "there" in "so why not just follow the standard that is used exclusively in civilian life there"—where is "there"?). Are you suggesting that the England article should use "MMM DD, YYYY" date formatting? If you are, you should be aware that that's far more radical than anyone else has dared suggest in this debate? As an aside, if a global format is being suggested, I'd lean towards using the less syntactically complicated "DD MMM YYYY" (you know, the one that is used at the end of each of these posts).  HWV258  01:04, 1 April 2009 (UTC)[reply]
Sorry if I was unclear, by the word "there" I meant the United States. And once again, what is radical about using MMM DD, YYYY for the England article, when both formats are used interchangeably in England? Everyone seems to be assuming that there is a strong preference for DD MMM YYYY outside the United States, but, as I demonstrated with my links above (oppose 138), this is not true. Phil Bridger (talk) 08:54, 1 April 2009 (UTC)[reply]
It's simply not true that they are used interchangeably. If you ever have to fill a form in the UK, it's quite possible that you have to enter a date into fields that look like this, __/__/____. In my experience they will always expect you to use DMY format, even though in some cases they may not mention it because it really goes without saying. This is because DMY format is much more common in general, including when the month is spelled out. --Hans Adler (talk) 15:13, 1 April 2009 (UTC)[reply]
In forms the date is usually entered in all numeric format, so there obviously has to be a standard, and, yes, that standard is different in the UK and the US, but in other contexts where the month is spelt out both formats are common. Do you seriously think that people have difficulty understanding the date, or get any sense that there's something wrong with it, when thay read it in The Times[11] or The Financial Times[12] or The Daily Mail[13] or The Sun[14]], or The Daily Star[15], all of which say that it's "April 1, 2009", not "1 April 2009"? That's five of the ten national daily newspapers, so you couldn't get a much more even split. And I have given similar references above to show that both formats are used in several other countries where English is widely used. It's no good saying that it's "simply not true" that both formats are used when the evidence says that they are. And why is it, when we are supposed to base this encyclopedia on reliable sources, that I am the only one of the 248 people who have voted here so far who has bothered to provide any evidence? Phil Bridger (talk) 15:45, 1 April 2009 (UTC)[reply]
Sorry for absurdly lecturing you without seeing that you are actually from the UK. I agree that standardising on MDY would be an option. However, this is very similar to standardising on Oxford style "ize" spellings for verbs in British English, and it seems that we haven't adopted this either. Therefore it seems unlikely that your argument will convince many in this poll. I think it should really be discussed separately. --Hans Adler (talk) 16:05, 1 April 2009 (UTC)[reply]
I'd just like to concur with this point - whenever I see this debate crop up, I honestly find it hard to remember which variant I'm supposed to prefer, or which one I'm supposed to object to. Written numerically, there's a standard, but written textually then "1st February" or "February 1st" are pretty much interchangeable to a British reader, and I'll often use the two in the same piece of writing, or use one one day and the other the next. Shimgray | talk | 15:29, 3 April 2009 (UTC)[reply]
A few of the above UK newspaper examples don't use American date format consistently when digging into the news articles. While the top banner of The Sun may show MDY, DMY-based content such as "Published: 04 Apr 2009" appear in articles before the current date [16]; here's a "13th April 2009" from The Daily Star, and another 13th April from The Daily Mail. Such commercial websites may not be reliable indicators for date format anyway as these can sometimes be skewed by software defaults, often biased towards US usage.
Government standards and practice would seem more reliable to consider for this discussion. UK government usage consistently uses DMY and rejects US/MDY format. There are moot differences as to whether ordinal letters (12th vs 12) are used on day numbers, but there is no interchangeability of ordering on official UK levels e.g. TDA, Cabinet Office, Hants, Mansfield District Council.
Furthermore, DMY is generally used by international bodies such as the UN [17], OECD [18], ITU [19], ICRC [20]. That's compelling evidence of what date format is considered the norm on an international scale and where a global project such as WP should be headed. But if we can't get there in the short term, we should make good use of the autoformatting capability (already developed for the most part) for the benefit of the various audiences. Dl2000 (talk) 16:41, 13 April 2009 (UTC)[reply]

Silly autoformatting: Uladzimir Katkouski, a well-known and award-winning Belarusian blogger, editor of several Belarusian websites and activist for the usage of the Belarusian language on the Internet. He made 1343 contributions to the English Wikipedia and 1286 contributions to nine other Wikimedia projects.[1] Katkouski mostly edited articles about his country and his language. He was hit by a fire truck in 2006 and, after being in a coma for about a year, he died on May 25, 2007.

Context on link misconception

Only a few of these comments make arguments against based on issues other than linking. The vast majority of the ones I've cited base their given explanation soley on the linking proposal. Shadowjams (talk) 01:20, 2 April 2009 (UTC)[reply]
(1) Voters are under no obligation to provide all of their inner reasoning. Are you objecting to those who provided no comment? (2) It is no surprise that many people still refer to the concept of date autoformatting at "linking"—that has been the vernacular term for the concept for some five years. (2) There is reference to "the links" in the Statement for the concept of autoformatting, and to "new features" such as "database dumps" that would, of course, require a feature for editors to identify autoformatted dates as links. Why wouldn't some voters use the common synonym "linking" to refer to the concept of autoformatting. Tony (talk) 09:58, 2 April 2009 (UTC)[reply]
Because it's a poll and not a vote, reasoning is instructive as to the actual proposal's support. Even the most adamant opponent should not want people to be misinformed about the nature of the proposal (or if they did, they could never vocalize it), and should be disturbed when there's evidence a number of users are confused.
The "linking" shorthand is interesting and something I hadn't heard before. You could be right and some users are using the old terminology out of habit. But certainly some users, the one that mention "blue links", or describe it, believe the proposal will lead to date linking again.
Of my original list (I'm working off the original numbering) numbers 13, 22, 42, 49, 73, 93, 101, 108, 109, 110, 116, 135, 137, 145, 147, either make the distinction themselves, or indicate it by referring to the particular properties of links (blue, they go somewhere, etc.).
Your point also suggests that perhaps some users who call things autoformatting, without mentioning linking, are thinking of linking. Maybe my original census undercounted the number of misinformed editors. Shadowjams (talk) 18:05, 2 April 2009 (UTC)[reply]

Vote by User:NeurolysisI note that User:neuro returned and added:

That looks to me like a retraction. Lightmouse (talk) 18:06, 1 April 2009 (UTC)[reply]

Yes, it was. — neuro(talk)(review) 23:48, 1 April 2009 (UTC)[reply]

Make the server do it while assembling the page. Why are human editors concerned with this question? Why can't we make the server search for dates in the text and then reformat them for the viewer based on their preference? The server already changes <br>, </br> and <br/> to <br /> without anyone ever noticing. I think dates should be the same; that editors should just type a date and the server will handle how it's served up. There's no reason why bots or humans should have to go through articles and apply templates or formatting. Binksternet (talk) 15:39, 3 April 2009 (UTC)[reply]

The problem here is that we don't want to reformat a lot of dates - in direct quotations, for example, or in the titles of cited works, both of which are places where we leave even broken spelling intact. Were we to let this sort of autoformatter loose, we'd need to have a simple way of marking those as not-to-be-changed... Shimgray | talk | 19:53, 3 April 2009 (UTC)[reply]
There is a simple way to say to the server "don't touch this particular date"... we can use the nowiki tag. Binksternet (talk) 13:12, 4 April 2009 (UTC)[reply]
Or indeed any other tag or template to be defined. But while I support autoformatting, it seems to me to be better that tags/templates are used to included it (i.e. an optional extra) rather than exclude it. That way, it's not a breaking change. Of course, editors or those who look after particular projects might choose to run a bot to automate "upgrades" to use the new autofomatting, but it should not be the default behavior of the server.
Perhaps I have got Binksternet's comment wrong, but if the suggestion is that the server should be able to parse text and work out that a particular piece of text is a date, that is a very hard task. I'd suggest that some markup is inevitable. Also, I am not sure if the server understands different languages? Parsing language-specific text surely is the job of a particular Wiki's template not the server core. SimonTrew (talk) 16:14, 6 April 2009 (UTC)[reply]
Perhaps I've also misunderstood the original comment, but just in case the suggestion is to parse dates that don't have some sort of mark-up wrapped around them, have a look at the following example: "On Jan 1, 2000 Wikipedians went crazy". Is that: all Wikipedians going crazy on 1 Jan 2000, or is that 2000 Wikipedians going crazy on 1 Jan?  HWV258  22:42, 8 April 2009 (UTC)[reply]
What about adding a freakin' comma after the year if the first of those two meaning is the intended one? --A. di M. (formerly Army1987) — Deeds, not words. 00:31, 9 April 2009 (UTC)[reply]
Will you make a list of poorly formatted sentences on WP, or shall I? :-)  HWV258  01:10, 9 April 2009 (UTC)[reply]

Autoformatting into ISO dates

One comment I see recurring among the opposes is that autoformatting is analogous to automatically handling US/Commonwealth spelling, and that we don't want that. Leaving aside whether we do want that (I don't), this argument misses another possibility - the ability to autoformat dates into ISO format. Very few human readers would want that (I would, but I'm a techy geek) but it could be extremely useful to automated parsers, particularly in, say, infoboxes. Cheers, This flag once was redpropagandadeeds 16:04, 3 April 2009 (UTC)[reply]

Autoformatting for non-registered users

The statement (Wikipedia:Date formatting and linking poll#Background statement) suggests that autoformatting is only useful to registered editors: "Autoformatting is a way of marking up dates to allow registered users to choose their preferred display format". However, is there any reason why autoformatting couldn't be performed for non-registered users? The user's locale could easily be inferred from the HTTP headers ("Accept-Language" in particular) and a suitable date-format used. Cheers, This flag once was redpropagandadeeds 18:17, 3 April 2009 (UTC)[reply]

But how can we infer from the header what format the reader prefers? I have shown elsewhere in this discussion that "April 3, 2009" and "3 April 2009" are equally acceptable formats in the English language in the United Kingdom, India, Australia and Canada, and, if you really insist I'll link you to major English language media sources in Pakistan, Ireland, New Zealand, Bangladesh, South Africa, Sri Lanka, Nigeria and anywhere else that will show that it is a myth that "3 April 2009" is a nationally preferred format anywhere that English is widely used. The only country where there is a preferred format is the United States, so why not just knock this whole silly discussion on the head and use the format (April 3, 2009) that is acceptable everywhere that English is widely used. Phil Bridger (talk) 19:18, 3 April 2009 (UTC)[reply]
With respect, you've shown elsewhere that both formats are used, not that both formats are equally acceptable. The Times may use MMM DD, YYYY but that doesn't mean that that format is equally acceptable within the Times' constituency.
And of course we can't infer from the header the reader prefers - "The user's locale could easily be inferred from the HTTP headers ("Accept-Language" in particular) and a suitable date-format used." We can infer the locale; the date-format then used is based on the usual date-format for the locale - no second-guessing whether the unregistered editor is a Times reader or a regular en-gb DD MMM YYYY person.
My point was that auto-formatting can - contrary to the suggestions above - be of benefit to unregistered editors: anonymous IPs with en-us in their HTTP header won't get DD MMM YYYY dates, for example, and only Times-readers are disappointed when their en-gb header results in them avoiding MMM DD, YYYY dates.
Cheers, This flag once was redpropagandadeeds 19:33, 3 April 2009 (UTC)[reply]
But it's not just The Times. In another post here I showed that five of the ten national daily newspapers in the United Kingdom use "April 3, 2009", rather than "3 April 2009". Where is the evidence that one format is preferred over the other in the UK? And the same goes for every other country where English is used to a significant extent except for the United States - I've given examples for India, Canada, and Australia, and would urge you and anyone else to provide such evidence if you are claiming that there is any country that uses English to a significant extent where "April 3, 2009" is not a perfectly acceptable format. Once again, why am I the only one of the hundreds of people commenting here to provide any evidence for their position? Phil Bridger (talk) 21:05, 3 April 2009 (UTC)[reply]
  • In New Zealand (where I am) there is also no preferred format for dates. Individual publications may have a chosen style, but only someone writing for that publication would be aware of that. Nobody gives a toss what format you write dates in. Indeed it is hard for me to understand that this is even an issue. There is a DD/MM/YYYY convention for date abbreviations which differs from the US one, but non-abbreviated dates can be, and are, written and understood in any format. I don't mind writing dates in the US style. Indeed I do so anyway about half the time. However I would be opposed to wikipedia mandating that dates always be written in the US style. That sounds to me like a charter for date nazis. It is a big world with lots of cultures rubbing up against each other. Wikipedia is an international collaboration where people from all sorts of backgrounds contribute. Tolerance and understanding of differences is needed to make this work. Anyone who is so intolerant that they let the style that other people write their dates annoy them needs to be told to lighten up and get a life. Hawthorn (talk) 08:31, 4 April 2009 (UTC)[reply]
  • My original point was that "auto-formatting can - contrary to the suggestions above - be of benefit to unregistered editors"; nothing said to date has changed that. It may well be that, as a community, we decide that unregistered readers see date as unformatted - that, then, will be our choice. My point is that autoformatting does give us that choice, despite claims to the contrary. Turning to your evidence, in Scotland one newspaper uses DD MMM YYYY and the other uses MMM DD YYYY (with no comma - first time I've seen that): I don't believe that this - or that the evidence you've presented - says anything other than newspapers use a variety of different styles. Surely the key thing here is what people are taught at school, use in their daily lives, and recognise in correspondence from government? If you wish, I'll try and dig our references supporting my belief that DD MMM YYYY is taught in schools in the UK, New Zealand and Singapore (countries in which I experienced education at some level) in preference over MMM DD, YYYY, that this format is used by the governments of those countries, and that people tend to use that format more as a result - and I dare-say that other editors can provide references for other countries. However you're asking for evidence that MMM DD, YYYY is not a perfectly acceptable format - which no one, so far as I can see, is suggesting. Of course people more familiar with DD MMM YYYY recognise and understand MMM DD, YYYY, and it's ludicrous to suggest otherwise. This is about preference, not about acceptability. My preference is for YYYY-MM-DD, and I'd like a system where that preference can be catered for. My preference in no way affects my ability to accept or understand MMM DD, YYYY or DD MMM YYYY. Your evidence shows that people can accept or understand MMM DD, YYYY simultaneously with DD MMM YYYY - which comes as no surprise to me - however I do not believe it shows anything beyond that. Cheers, This flag once was redpropagandadeeds 11:02, 4 April 2009 (UTC)[reply]

(In response to neutral vote # 14) Actually, there lies a significant problem: a not-inconsiderable proportion of dates are wrongly input (Sept 4, for example, or your example), and the proposed system would need to be programmed to fix each individual possibility. Another reason, I believe, that we should not mess with editors' control over simple fixed-text dates. Tony (talk) 06:43, 4 April 2009 (UTC)[reply]

{{#formatdate:Sept 4, 2007|dmy}} produces "Sept 4, 2007". I don't see how that makes anything worse than it would be if an editor simply typed in an incorrectly written date without the autoformatting code. I voted "neutral" because it seems to me that the autoformatting question really contains two hidden subquestions: (1) should we permit use of #formatdate, and (2) should we require (or encourage or recommend, etc.) its use? I would vote "yes" to the first and "no" to the second; therefore neutral on the combined question. I do recognize that some people complain about having to wade through additional markup code when editing, but I personally don't see that as a big problem. And, on the other side, I recognize that some people seem to think it is important that every date in every article be viewable in the same format, but again I don't see that as a huge problem when we allow (and affirmatively endorse) such inconsistencies as American and British spellings and some other usages that vary from one article to the next. --R'n'B (call me Russ) 12:17, 4 April 2009 (UTC)[reply]
  • R'n'B, I agree about your point with American regarding British spellings. As an American, encountering “I realise that…” interrupts my train of thought whereas encountering either “4 April” or April 4” causes me no interruption in my train of thought—and certainly no confusion.

    The trouble is, “autoformatting” is nothing of the sort for 99.9% of our readership. For I.P. users, all it would do in any given article is default to one format or another. And that is no better than just writing out the date in fixed text. The real *benefit* of autormatting (presenting a date in accordance with a preferences setting) works only for registered editors. It’s not worth so much fuss to benefit so few users to address a purely stylistic issue over which no confusion arrises.

    For some editors, this is just a big fuss to never see a date style that isn’t their way. Indeed, I just don’t “get it” because I can handle seeing either date format and have no patience for those who insist that everyone else jump through hoops for their viewing pleasure. For the programmers, its about cool code. But they’re trying to sell refrigerators to Eskimos. Greg L (talk) 02:23, 5 April 2009 (UTC)[reply]


Frankly, the whole thing seems foolish to me: All autoformatting does is hide inconsistencies, make atrocities like "Sir William Schwenck Gilbert (1836-11-18–1911-05-29)" invisible - for those with it turned on, that read: (1836-11-18–1911-05-29), and mean that, in situations where there's good reason to use a non-standard format, such as "Accessed 2009-05-04" in a footnote, where compactness is advantageous, it'll be replaced with a less appropriate one. What's the point? What next? Will we make it so that readers in Greece have Macedonia direct to the Greek region, but readers in the country of Macedonia have it redirect to the country? It's just not worth it: A solution searching for a problem.

Furthermore, autoformatting dates must require some sort of markup, because of the problem of dates in exact quotes, and other issues. A quote from a ship's log might begin "13-01-1897: Land spotted. Have adjusted course..." If text was automatically changed, and the user didn't know the obscure methods for turning off date formatting, then, for the convenience of a few pedants who insist on consistent formatting when they browse, we've managed to hurt usability of our editing interface in a non-trivial way. So we have to mark up dates. Can dates be marked up autonmatically? No, that hits direct quotes too, in a hard to spot way. So we're now lookign at manual markup of dates on millions of articles. Bugger that! You'll learn to live with occasionally being faced with the dreaded "March 3" or "3 March". Like normal people. Shoemaker's Holiday (talk) 06:31, 5 April 2009 (UTC)[reply]

That about Macedonia would be a great idea, provided that Italian readers have it direct to the dessert. :-) A. di M. (formerly Army1987) — Deeds, not words. 19:03, 5 April 2009 (UTC)[reply]

Statement for is biased and fallacious: creative content is not a “user interface”#Statement for betrays the wrong attitude that readers and editors are “users”, and that my creative contribution, protected by the GPL GFDL, is a “user interface” which should be rewritten by a machine to support “user preferences”. “Personalized date formats in operating systems” don't rewrite the books you are reading or correct the language in music you listen to. This explanation is biased and fallacious, and is misleading editors who read it and vote. Michael Z. 2009-04-11 16:41 z

"If you don't want your writing to be edited mercilessly or redistributed for profit by others, do not submit it." No mention of "machines" being excluded from the aforementioned editing is there? --WebHamster 17:11, 11 April 2009 (UTC)[reply]
Also note content here is under the GFDL, not the GPL. Fletcher (talk) 17:14, 11 April 2009 (UTC)[reply]
You're wrong. The GFDL requires anyone who alters my text to do it under the GFDL. There's no GFDL attached to preferences which rewrite page content, and there's no credit for the alteration placed into the article's edit history. The site can change the style using a skin, but if it edits my text then it is infringing on my copyright, according to my GFDL release terms. Michael Z. 2009-04-11 17:45 z
See WP:GFDL#4._MODIFICATIONS for the obligations of distributing modified versions of documents. Michael Z. 2009-04-11 17:54 z
IANAL, but alteration of mere date strings is likely de minimus. Your phrasing that it "rewrite[s] page content" is vastly weaker when one keeps in mind it is just date strings, which are not copyrightable works by themselves. One should also consider the implementation: if you use a template or other wiki-markup, you have consented to the autoformatting (else you would not have used that syntax); alternatively if you don't use any special markup, it's likely a bot or human will have to go make a change to the article which will be reflected in the edit history. Fletcher (talk) 19:58, 11 April 2009 (UTC)[reply]
Templates may present letter-of-the-law licensing problems, but at least they are placed by humans and altered by humans, whose actions all appear in edit summaries, and thus are governed by the GFDL.
But allowing a preference for registered or non-registered users to start rewriting the text opens a different can of worms – next it will be blind spell-checking, pirate-talk filters, and who knows what next? Shall we auto-load up machine-translated versions of foreign-language articles, without any local editor in the credits? Do you want your name to be the last one in the credits of an article machine-translated into Chinese? No, thanks.
De minimus is a legal concept, but we are talking about the substance of people's writing; remember the substance of eats, shoots & leaves is a lowly comma. You can put all of the human editors and proofreaders you want on my writing, but I won't entrust it to a machine which is not being supervised by a responsible editor under GFDL. A spell-checker won't replace an editor, neither to produce a professional-quality document, nor to take legal responsibility for modifying and republishing my work. Michael Z. 2009-04-11 23:28 z
I'm concerned that you are claiming WP:Ownership over articles, or parts thereof, to which you contribute on WP. Is it OK if I read them in a different font from you? Or perhaps I prefer to use a speech reader, or read them in French using machine translation. One of us is missing the point; if you think you have ultimate control over the form in which "your" work, creative contribution, text is "republished", don't put it on WP; if not, what's the difference between the examples I gave and changing (manually or automatically) a date format? I can't see any voting stance that implies, as you seem to, that nobody should ever touch "your" text the way you have written it. Have I completely misunderstood? Best wishes SimonTrew (talk) 04:26, 12 April 2009 (UTC)[reply]
I'd say you have. WP:OWN is about editing disputes and has nothing to do with this.
You are welcome to transform the article any way you like for your private use. But when Wikipedia distributes articles by publicly displaying them on its website, it is bound by the licence. Read WP:COPYRIGHT, which says “the text of the Wikipedia is copyrighted . . . by Wikipedia editors and contributors and is formally licensed to the public under the GNU Free Documentation License”. Under the GFDL, if the article has been modified from the editors' version, then Wikipedia must not display it without taking credit for modifications. Wikipedia:GFDL:
  • “§ 0. PREAMBLE: . . . this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. . . .
  • § “1. APPLICABILITY AND DEFINITIONS: . . . A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. . . .
  • § “2. VERBATIM COPYING: . . . you may publicly display copies. . . .
  • § “4. MODIFICATIONS: . . . you must do these things in the Modified Version:
    • “A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions . . .
    • “B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications . . .
    • “E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. . . .
    • “I. Preserve the section Entitled "History", . . . and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version . . .”
I didn't make this up. You and I are bound by the licence, and so is the Wikimedia Foundation. The licence says that any modifications made must be acknowledged in distributed copies. Michael Z. 2009-04-12 16:04 z
You didn't have to quote chapter and verse, I am capable of looking up a reference. Anyway, I really think this is a dead end to this particular discussion. Nothing says the republishing agent has to be a natural person, the Wikipedia page rendering engine could just thwack a copyright notice at the bottom of the page saying "go see the original text"-- in fact, since the rendered version is ipso facto different from the edited text (assuming even the most minimal markup) I could argue it already should-- if it reduces a picture to a thumbnail, for example. These clauses are intended to stop people not crediting Wikipedia and its contributors a whole, not to stop minor changes for rendering purposes. I have started doing some translation and have to credit the original under GFDL, but that doesn't mean I can't change the article, in fact it's encouraged where appropriate The aim of the GFDL is to protect the Commons and Wikipedia etc and to ensure fair use etc. It does not mean, however you would like it to mean, that pages cannot be rendered in a different way by different engines, be they the server or client, or my own blurry eyes when I remove my glasses. I am not going to quote all kinds of references here but the whole Look and Feel argument of the early 80's (Lotus 1-2-3 vs Borlland Quattro) established that, in law in the US, but in practice everywhere. SimonTrew (talk) 22:08, 12 April 2009 (UTC)[reply]
A school of red herrings (my favourite is “the discussion is now over, and here's 200 words explaining why...”).
Yes, editing is encouraged, but only allowed under the GFDL. I'm not claiming copyright over my “look and feel,” but over the words I've written. What do your blurry eyes have to do with rewriting some of these words without respecting the explicit terms of the licence? Nothing.
The GFDL does say that whoever the republishing agent is, individual or corporation, they have to take credit for their modification. And you're quite right, thwacking a copyright notice, along with the required change of title and the acceptance of credit could well be enough – but the foundation doesn't. The copyright notice linked from every article says explicitly that copyright is held by the editors, and not by the foundation. Michael Z. 2009-04-13 20:25 z
So argue for them to put a copyright notice on. That's irrelevant to the discussion. It's also slightly ingenuous of you to start with that quote when I never said anything of the sort; I know you will say neither did you, but to head the reply that way implies that. I know... let's suggest that every phrase, word or quote used in wikipedia should have markup and copyright references. So if I quote Churchill I better make sure I have a good source (History of the Engish-Speaking Peoples, perhaps) and make sure that I check whether it is in or out of copyright. What nonsense. The copyright issue is completely irrelevant, and whatever red herrings there were, you didn't point them out. Discussion is over, in fewer than 200 words. SimonTrew (talk) 23:14, 13 April 2009 (UTC)[reply]
To answer Martindelaware's question (support 189)

No date autoformatting (DA) system will cope with reformatting these fragments (from Charles Darwin) "On 28 September 1838 he noted this insight." to "On September 28, 1838, he noted this insight." as well as reformatting "He died on 19 April 1882." to "He died on April 19, 1882." without complicating the syntax of the markup or making mistakes when the year is followed by a period (or other punctuation characters like parentheses or ndashes). The present, deprecated, system of DA fails to supply the required second comma to produce apposition. I have seen no suggestion that any "Son of DA" will fare any better. In fact, any proposed DA will increase errors by hiding the missing second comma from many editors who do not have that preference set. --RexxS (talk) 00:25, 12 April 2009 (UTC)[reply]

Month-day linking

Background statement

Month-day linking is the use of linking markup (double square brackets) on a day and month combination (e.g. [[March 24]]), which creates a link to a specific date article (March 24). Month-day linking has been used by editors to create links to such articles, and (from 2003 to 2008) to autoformat dates (see above).

Advantages of month-day linking
  1. Provides easy access to date articles.
  2. Populates "what links here" pages with possibly relevant data.
  3. Offers editors direct links to destination compared to the less precise "search" function.
  4. Uses a syntax that is logical, easily understood, and has been in widespread use since 2003 by the editing community.
  5. Provides links on occasions in which readers may reasonably wish to see the article on the date, including birth and death dates, dates of celebration (March 17 from Saint Patrick; 5 November from Guy Fawkes) or conventional names (e.g. 10 August 1792 links to 18 Brumaire).
Disadvantages of month-day linking
  1. Provides little or no relevance to an article's topic. These include, in almost all instances, links to:
  2. Dilutes high-value links (overlinking). When a link to a month-day page might be of potential interest to readers, it is better displayed in the See also section rather than in the main body of the article.
  3. Month-day linking does not provide an explanation as to why a reader should follow a link. The use of the See also section for such links can provide explanatory text.
  4. "What links here" for dates typically generates many results of questionable utility or relevance. There are already powerful tools for searching these items, including the precise "search" function and by adding "site:wikipedia.en" to a Google search for dates.
Advantages of month-day markup (whether or not it entails linking)
  1. Clearly marks out date strings for recognition by bots/scripts, which simplifies the automated processing of article text and the gathering of metadata.
Disadvantages of month-day markup
  1. Complicates the editing process with confusing syntax and additional keystrokes.
  2. Possible "metadata" add no value to those from existing tools, so it is unclear whether/why they warrant the use of special markup.
Advantages of removing guidance on month-day links
  1. Any specific guidelines on month-day links that do not apply to all links are instruction creep.
Disadvantages of removing guidance on month-day links
  1. The linking of date articles needs special guidance in our style guide because they are not like ‘normal’ articles—almost all date articles are lists of events, related only by the coincidence of occurring on the same date. Such lists almost never provide a context that helps in the understanding of an article that links to them, and therefore should not be linked to. If date articles are ever improved to the point where they do indeed provide historical context, this guidance may need to be reviewed.


If supported through consensus, one of the following four proposed guidelines (Options 1, 2, 3 or 4) would be added to Wikipedia:Manual of Style (dates and numbers)#Linking and autoformatting of dates and Wikipedia:Linking#Chronological items. Please respond below to the four options.

Month-day articles (February 24 and 10 July) should not be linked unless their content is germane and topical to the subject. Such links should share an important connection with that subject other than that the events occurred on the same date. For example, editors should not link the date (or year) in a sentence such as (from Sydney Opera House): "The Sydney Opera House was made a UNESCO World Heritage Site on 28 June 2007", because little, if any, of the contents of either June 28 or 2007 are germane to either UNESCO, a World Heritage Site, or the Sydney Opera House.
References to commemorative days (Saint Patrick's Day) are treated as for any other link. Intrinsically chronological articles (1789, January, and 1940s) may themselves contain linked chronological items.

Month-day articles (February 24 and 10 July) should not be linked unless the article is about (or includes, as primary article) a commemoration which usually occurs on that date. For example, Christmas might link to December 25, or Saint Patrick's Day (but not Saint Patrick) might link to March 17 (even though it is occasionally celebrated on a different day due to Lent).

Month-day articles may be linked on their first occurrence in an article, regardless of how relevant the two articles are to each other.

Month-day: Option #4 (removal of guidance)

All specific language dealing with month-day links will be removed from the Manual of Style and related pages. This will have the effect of treating month-day links like any other potential link. (This need not include mentions of linking in the context of autoformatting; whether these are current guidance or a historic note depends on the question on autoformatting above.)


Month-day responses

Please indicate your support vote under ONE option, accompanied by a concise explanation for your choice. Your explanation is important in determining the community consensus.
  1. Seems the best option of the four. Steve Crossin Talk/24 23:15, 29 March 2009 (UTC)[reply]
  2. To reduce link density, I believe in general only the relevant information should be linked, and this should be no different for dates. Rambo's Revenge (How am I doing?) 23:20, 29 March 2009 (UTC)[reply]
  3. Please, let common sense prevail. Links are hardly relevant and seldom help deepen understanding of the subject. Ohconfucius (talk) 23:23, 29 March 2009 (UTC)[reply]
  4. Per WP:OVERLINK. --John (talk) 23:36, 29 March 2009 (UTC)[reply]
  5. Support, the links are almost never relevant. Remember, dates may be relevant, but the date articles that are being linked to almost always aren't. Dabomb87 (talk) 23:49, 29 March 2009 (UTC)[reply]
  6. Absolutely. Even when a date is notable in its own right, e.g. Christmas Day, it may be irrelevant to the passage in which it occurs. --Philcha (talk)
  7. Support: The date links are almost never relevant, so this shouldn't need to be done too often. seicer | talk | contribs 23:56, 29 March 2009 (UTC)[reply]
  8. Support. I hope this provision will be construed fairly narrowly. -- Donald Albury 23:58, 29 March 2009 (UTC)[reply]
  9. Support, common sense. All links, including links to dates, should only exist when they further the understanding of an article's subject. Raven1977Talk to meMy edits 00:01, 30 March 2009 (UTC)[reply]
    Support Though I have a fairly high standard for relevance. I would rank the options 1,4,2,3. Eluchil404 (talk) 00:05, 30 March 2009 (UTC)[reply]
  10. Support. Common sense suggests to me that option 4 should have almost exactly the same effect. But since not everybody agrees, this is much better, as it settles the question. --Hans Adler (talk) 00:08, 30 March 2009 (UTC) In fact, option 4 is the worst one because there is no chance it will end the fighting. --Hans Adler (talk) 10:24, 31 March 2009 (UTC)[reply]
  11. Support Dates should be linked like anything else - they should enhance the reader's understanding of the article's topic.Awadewit (talk) 00:09, 30 March 2009 (UTC)[reply]
  12. Support This pretty much covers the rare circumstances when dates should be linked. The proposed wording says it all: dates “should not be linked unless their content is germane and topical to the subject.” Enough said. Greg L (talk) 00:30, 30 March 2009 (UTC)[reply]
  13. Support Reduces pointless links, allows the odd occasion where strictly useful. Dates need treating separately from "normal links" due to the controversial issues surrounding date linking and autoformatting.—MDCollins (talk) 00:40, 30 March 2009 (UTC)[reply]
  14. Support I would tend to support the remove guidance option, but I suspect that past tendencies to link all dates would lead to continued overlinking. Guidance is needed to limit date links to those of notable historical significance. -- Tcncv (talk) 00:46, 30 March 2009 (UTC)[reply]
  15. Per pretty much all supporters above. NuclearWarfare (Talk) 00:48, 30 March 2009 (UTC)[reply]
  16. Support I too pondered on the remove guidance option, but I think it is disparity on this issue that got us here in the first place. Casliber (talk · contribs) 01:03, 30 March 2009 (UTC)[reply]
  17. Support This is a helpful elaboration of the general guidance on wikilinks. Eubulides (talk) 01:29, 30 March 2009 (UTC)[reply]
  18. Support I prefer as few links as possible, and find date links rarely relevant. Ealdgyth - Talk 01:48, 30 March 2009 (UTC)[reply]
  19. Support: reckless linking of dates only serve to disrupt the reading experience; a date clicked about a medieval battle should point to relevant details in that time, rather than showing the day Titanic won record Oscars or such. Jappalang (talk) 01:53, 30 March 2009 (UTC)[reply]
  20. Support : I get tired of seeing blue links in articles that take me to date articles that have absolutely no relevance to what I'm reading.SteveB67 (talk) 02:13, 30 March 2009 (UTC)[reply]
  21. Per Seicer. –Juliancolton | Talk 02:15, 30 March 2009 (UTC)[reply]
  22. Actually, I most support Option 4 - no guidance means nothing to edit war over, and the practical result would be identical to this guideline. Since the poll format ostensibly won't allow supporting multiple options (Why? Seriously, why?) I support this one on the basis already stated - it is identical to option 4 in practice, and more likely to be supported by others in practice. However, your poll format is broken in any case. Gavia immer (talk) 03:08, 30 March 2009 (UTC)[reply]
  23. Support.-gadfium 03:23, 30 March 2009 (UTC)[reply]
  24. Support—This conservative guidance on when to link month-day items (like, very rarely) is already established on WP. The project is now maturing in its use of wikilinking, from the original undisciplined scattergun to a more selective approach—smart linking, if you like—that avoids diluting high-value links. It's about time. Nothing turns readers off more than a sea of blue, and they will tend to click on nothing. Tony (talk) 03:45, 30 March 2009 (UTC)[reply]
  25. Support Like others, I find date linking unnecessary and dislike the extra blue. bridies (talk) 04:39, 30 March 2009 (UTC)[reply]
  26. Support. if the now-deprecated autoformatting system had not incidentally created links, we wouldn't need any extra guidance about linking dates - but it did, and we do. links should be made on the basis of the relevance of the articles they lead to. squillions of unwarranted links need to be removed. i'd also support changing the names of most month-day pages to something like List of Events on Month-Day Throughout History. Sssoul (talk) 04:46, 30 March 2009 (UTC)[reply]
  27. Support. Seems like the most sensible text. While the treatment is not really different from other links (link only if relevant) date links require special guidance because they are so often made inappropriately.--Srleffler (talk) 04:51, 30 March 2009 (UTC)[reply]
  28. SupportChris! ct 05:03, 30 March 2009 (UTC)[reply]
  29. Support. Rare links are of course okay. What we don't need is routine linking. Fut.Perf. ☼ 06:00, 30 March 2009 (UTC)[reply]
  30. Support. Date linking is a clunky solution in search of a problem. Bishonen | talk 06:44, 30 March 2009 (UTC).[reply]
  31. Support as second option (Please see comment under option 4). I prefer option 4, for much the same reason as I do not accept that this poll is best served by supporting only a single selection :-) AKAF (talk) 07:01, 30 March 2009 (UTC)[reply]
  32. Support If date links won't format, what the hell is the point of linking unrelated dates? Oren0 (talk) 07:15, 30 March 2009 (UTC)[reply]
  33. Support Links should only be made to dates in exceptional circumstances where they are clearly relevant and needed to explain the context. Dougweller (talk) 08:06, 30 March 2009 (UTC)[reply]
  34. Support. This is the only option that explicitly states that each date link must be relevant. No more, no less. That is the same with non-date links but after a long period of overlinking, editors need explicit guidance. Lightmouse (talk) 08:23, 30 March 2009 (UTC)[reply]
  35. Support, with caveat that dates aren't ever per se "relevant". Bongomatic 09:02, 30 March 2009 (UTC)[reply]
  36. Support. Would be blessed to get rid of all the irrelevant date links that confuses articles now.--HJensen, talk 09:06, 30 March 2009 (UTC)[reply]
  37. Support. We do need a rule, for consistency's sake (so no to Option 4). Dates just aren't normal links (so no to Option 3). I don't see a risk of orphaning date articles (so no to Option 2); if they are relevant to a given article they'll be linked to (so yes to Option 1). YLee (talk) 09:21, 30 March 2009 (UTC)[reply]
  38. Support as per above comments. Extremepro (talk) 09:26, 30 March 2009 (UTC)[reply]
  39. Support. I need say no more. This, that and the other [talk] 09:28, 30 March 2009 (UTC)[reply]
  40. Support. Links should always be judged based on relevancy and value to the reader. — TKD::{talk} 11:09, 30 March 2009 (UTC)[reply]
  41. Support (this or option 2; I'm not sure what the difference is in practice, the wording probably needs tightening in either case).--Kotniski (talk) 11:21, 30 March 2009 (UTC)[reply]
  42. Support Links are almost never relevant. Articles and the edit window looks cleaner without all the wikilinks and markup. - kollision (talk) 11:45, 30 March 2009 (UTC)[reply]
  43. Support It makes the most sense - you don't want to link to days that are just "days" (birthdays etc.), but it would be rather weird to have a page on a holiday or a world event that didn't link to what was going on on that day... Bangdrum (talk) 11:55, 30 March 2009 (UTC)[reply]
  44. Support per TKD. Peridon (talk) 12:19, 30 March 2009 (UTC)[reply]
  45. Support rʨanaɢ talk/contribs 13:12, 30 March 2009 (UTC)[reply]
  46. Support - Only when relevant makes the most sense to me. Camw (talk) 13:39, 30 March 2009 (UTC)[reply]
  47. Support - this is what I've gotten used to in the past months, and it works just like any other links. This is equivalent to #4, but special guidance is necessary because of the history here. --NE2 13:40, 30 March 2009 (UTC)[reply]
  48. Support. This is what WP:OVERLINK says, no reason why dates should be any different. — Emil J. 13:42, 30 March 2009 (UTC)[reply]
  49. Reluctant support', I guess this is the best choice, but they are almost never relevant. SandyGeorgia (Talk) 13:43, 30 March 2009 (UTC)[reply]
  50. Support but we should be stronger and say that such links are almost never relevant in the guidance. GRBerry 14:04, 30 March 2009 (UTC)[reply]
  51. Support I hate seeing links to articles with no content related to what I am reading, they are pointless - Dumelow (talk) 14:17, 30 March 2009 (UTC)[reply]
  52. Strong support. Date links are almost never relevant; if and when they are, this seems the best solution. Cnilep (talk) 14:34, 30 March 2009 (UTC)[reply]
  53. Support. I might have chosen remove guidance, but the dust won't settle for months or years yet. Light our path, and we may avoid some bumps along the way. — the Sidhekin (talk) 14:58, 30 March 2009 (UTC)[reply]
  54. SupportBellhalla (talk) 15:08, 30 March 2009 (UTC)[reply]
  55. Support that dates are linked for chronological articles, but not for any other purpose. I strongly oppose the other options. Karanacs (talk) 15:28, 30 March 2009 (UTC)[reply]
  56. Support Unless specifically germane to the article or context, date links are almost always empty links. The prime example of a wikilink which illuminates little or nothing in the original article. Pigman☿/talk 15:35, 30 March 2009 (UTC)[reply]
  57. Reluctant Support per User:SandyGeorgia. I struggle to think of any circumstances in which these links should be included in articles, so I don't think this is strong enough - but it's the best choice of the four. Pfainuk talk 15:37, 30 March 2009 (UTC)[reply]
  58. Support Perhaps in the future formal guidance on this issue can be removed. Since it's been a back and forth issue for a while, we need it for now, I think. --TreyGeek (talk) 15:48, 30 March 2009 (UTC)[reply]
  59. Support The vast majority of date links have no relevance to the article and should only be used when there is a meaning specific to the article. --Captain-tucker (talk) 15:52, 30 March 2009 (UTC)[reply]
  60. Strong support per most of the above arguments Johnny Au (talk/contributions) 15:55, 30 March 2009 (UTC)[reply]
  61. Strong Support 61 other people have said it. Read above. Alan16 talk 15:56, 30 March 2009 (UTC)[reply]
  62. Support although should not be overused - should be used for articles about the date itself, or linking to very very particular and well recognised uses eg July 4. Orderinchaos 16:02, 30 March 2009 (UTC)[reply]
  63. Support sparingly --Dweller (talk) 16:04, 30 March 2009 (UTC)[reply]
  64. Support, mainly for use in "what links here". I rate the options: 1,2,4,3. Let's get rid of the useless links to lists of irrelevant trivia that happened to occur a whole number of years later. Certes (talk) 16:06, 30 March 2009 (UTC)[reply]
  65. Support, there is no need to needlessly overlink articles. Plastikspork (talk) 16:23, 30 March 2009 (UTC)[reply]
  66. Support. Rettetast (talk) 16:25, 30 March 2009 (UTC)[reply]
  67. Weak support. Seems the most logical to me, but implementing it will take careful work. Greggers (t • c) 16:28, 30 March 2009 (UTC)[reply]
  68. Support. My preference would be to eliminate all linked dates, but this option is the best of the bunch. It avoids overlinking, unless there is some particular relevance to the date. --Skeezix1000 (talk) 16:31, 30 March 2009 (UTC)[reply]
  69. Support. This is concurrent with the general guideline to make onlyrelevant links. Debresser (talk) 16:54, 30 March 2009 (UTC)[reply]
  70. Support. There are some rare links that are useful so this would seem to cover them. -- Banjeboi 16:56, 30 March 2009 (UTC)[reply]
  71. Support. The history of this debate shows that guidance is necessary, so option 4 is not sufficient. There is little reason to treat links to month-day articles differently from links to any article, so only those which are clearly relevant should be linked. --RexxS (talk) 16:59, 30 March 2009 (UTC)[reply]
  72. When we link to articles whose content is not relevant to the context, we do our readers a disservice by distracting them from links to relevant articles. In the absolute majority of cases, month-day links are irrelevant to the context of the article from which they are being linked. –Black Falcon (Talk) 17:21, 30 March 2009 (UTC)[reply]
  73. Support Links are pointless and detrimental unless they are of semantic value. OrangeDog (talk • edits) 17:24, 30 March 2009 (UTC)[reply]
  74. Support These must comprise the overwhelming majority of pointless blue links! These articles are just big, useless lists of events, births and deaths-who clicks on them? RupertMillard (Talk) 17:38, 30 March 2009 (UTC)[reply]
  75. Support: I don't find the actual day-month articles pointless as RupertMillard suggests (I rather like them!), but I don't think they should be linked to in the manner that they have been. I also think Option #4 is scary and will only lead to incessant edit-warring (which has already been happening, and we really don't need any more of that!). I think that some guide, somewhere, should state the accepted instances for date links (rare) and keep the issue quite simple and defined. Maedin\talk 18:16, 30 March 2009 (UTC)[reply]
  76. Support. This should be the "common sense" option as I don't see any reason for it to be otherwise. Dates should be linked under the same rules as anything else - if relevant. |→ Spaully† 18:19, 30 March 2009 (GMT)
  77. Support. Links are useful mainly to define or further explain specific terms in an article. Nobody needs to look up the meaning of a date such as March 30. Dirac66 (talk) 18:23, 30 March 2009 (UTC)[reply]
  78. Support, allowing linking to Dec. 25 in the Christmas article. Frankly these links are almost never useful in the wider encyclopedia, but do have occasional value. --Philosopher Let us reason together. 18:25, 30 March 2009 (UTC)[reply]
  79. Pro --Morten (talk) 18:26, 30 March 2009 (UTC)[reply]
  80. Support options 1 and 2. Note: marking in both lists for clarity. davidwr/(talk)/(contribs)/(e-mail) 18:33, 30 March 2009 (UTC)[reply]
  81. Support per above, only link when needed. TheAE talk/sign 18:38, 30 March 2009 (UTC)[reply]
  82. Support per all the above. Alarics (talk) 18:40, 30 March 2009 (UTC)[reply]
  83. Support per Casliber above. We need to reach something definitive and hopefully put this issue to rest.
    ⋙–Berean–Hunter—► ((⊕)) 18:59, 30 March 2009 (UTC)[reply]
  84. Support linking if relevant, but not linked if not relevant. User preference issue can be dealt with in other ways if that is the consensus. Mjroots (talk) 19:14, 30 March 2009 (UTC)[reply]
  85. Support. In my opinion the most useful option. Liffey (talk) 19:26, 30 March 2009 (UTC)[reply]
  86. Support In general, links to dates take the reader nowhere worthwhile. Mr Stephen (talk) 19:54, 30 March 2009 (UTC)[reply]
  87. Support Most logical. KellenT 20:19, 30 March 2009 (UTC)[reply]
  88. Support This is the clearest option, and the most in keeping with existing policies about overlinking. Anaxial (talk) 20:48, 30 March 2009 (UTC)[reply]
  89. Support It is the most logical and practical option. ~EdGl ★ 20:57, 30 March 2009 (UTC)[reply]
  90. Support Agree with comments 2,3,5,6, etc, etc, etc. CS46 21:11, 30 March 2009 (UTC)[reply]
  91. Support Date-linking in Wikipedia articles was a poor idea to begin, and the less of it, the better.  JGHowes  talk 21:20, 30 March 2009 (UTC)[reply]
  92. Support. Would remove irrelevant links while still keeping ones that had value. – Joe N 21:30, 30 March 2009 (UTC)[reply]
  93. Support. Seems obviously correct to me. Gareth McCaughan (talk) 21:34, 30 March 2009 (UTC)[reply]
  94. Support. Although in an ideal world, option #4 would be sufficient, in practice I think that the clarity of option #1 will be the most effective. —Josiah Rowe (talk • contribs) 21:45, 30 March 2009 (UTC)[reply]
  95. Support This is the only option that makes sense - new readers are constantly confused by date links to articles that have no relation to the original subject being read. - Ahunt (talk) 22:07, 30 March 2009 (UTC)[reply]
  96. Support. Although I've long been a proponent of date autoformatting, I've always believed that most date links were irrelevant and wished I could have separate autoformatting and linking. RossPatterson (talk) 22:13, 30 March 2009 (UTC)[reply]
  97. Support. The best of the four options by a country mile. There's little on Wikipedia that's less useful than these month-day links. Julianhall (talk) 22:22, 30 March 2009 (UTC)[reply]
  98. Support faithless (speak) 22:53, 30 March 2009 (UTC)[reply]
  99. Support per common sense: only relevant words get linked, so it should be with dates. -M.Nelson (talk) 23:08, 30 March 2009 (UTC)[reply]
  100. Support. If it's relevant, then it is potentially useful to the reader and linking it would increase simplicity in the reader's point of view. Useight (talk) 23:52, 30 March 2009 (UTC)[reply]
  101. Support - dates should only be linked if the link makes sense, rather than every time. --PresN 23:58, 30 March 2009 (UTC)[reply]
  102. Support - There have been many articles I frequent that have had links removed from them. To say I haven't missed them would be the understatement of the year. Giants2008 (17-14) 00:18, 31 March 2009 (UTC)[reply]
  103. Support this follows existing guidelines and just makes sense; don't link it if it isn't relevant -- Collectonian (talk · contribs) 01:58, 31 March 2009 (UTC)[reply]
  104. Support. Reasonable sense to link to only relevant dates otherwise it's unnecessary. ddima.talk 02:07, 31 March 2009 (UTC)[reply]
  105. Suppport. Wikipedia does not exist for numerologists alone. VikSol 02:39, 31 March 2009 (UTC)[reply]
  106. Support, Option 1 not only means that date links will be treated like other links, but there will also be a guideline to put an end to revert wars. We need a guideline because linking has already been done and de-linking means a change: imagine if the word imagine had been linked every time, then suddenly it wasn't. A guideline will prevent any short term confusion. Sillyfolkboy (talk) 02:48, 31 March 2009 (UTC)[reply]
  107. support and also support mass delinking of all such dates to get to where we should be: few links Hmains (talk) 03:06, 31 March 2009 (UTC)[reply]
  108. Support. 99% of date links are irrelevant to the article content. RainbowOfLight Talk 03:26, 31 March 2009 (UTC)[reply]
  109. First choice. shoy (reactions) 03:35, 31 March 2009 (UTC)[reply]
  110. Support - This is the goldilocks option (not too hard, not too soft, but JUST RIGHT). There should be very few links to dates, but every once in a while, a link may be relevant. --Orlady (talk) 03:53, 31 March 2009 (UTC)[reply]
  111. Support - I see no reason to treat dates like this any differently than other word. Links should be employed only where relevant in any case. --Clay Collier (talk) 05:07, 31 March 2009 (UTC)[reply]
  112. Support - However, I think the mark up should be there, even if it is not rendered as a link. Nicolas1981 (talk) 06:19, 31 March 2009 (UTC)[reply]
  113. Support. Makes complete sense. I remember I was confused as a new user when I clicked on these links and expected to go somewhere relevant, but didn't in most cases. If you have any questions, please contact me at my talk page. Ian Manka 06:21, 31 March 2009 (UTC)[reply]
  114. Support: This option seems the most consistent with Wikipedia's existing linking policy. Regarding option four, I think that it's not unreasonable to state this in the MoS. — D. Wo. 06:46, 31 March 2009 (UTC)[reply]
  115. Support: As with other links, date links should have a good reason. Most of the month-day articles do not provide useful context, and this are simply extraneous links within articles. NJGW (talk) 07:46, 31 March 2009 (UTC)[reply]
  116. Support: Seems obvious to me. Link only if a link makes sense. -- WORMMЯOW  08:19, 31 March 2009 (UTC)[reply]
  117. Support The best option for reducing unnecessary links. --JD554 (talk) 11:41, 31 March 2009 (UTC)[reply]
  118. Common sense, really. Why on earth do I need to know, in a random article mentioning a random date, whatever else happened on the same random date?  Sandstein  11:48, 31 March 2009 (UTC)[reply]
  119. Support. Newbies need guidance not to "improve" an article with irrelevant links. Spike-from-NH (talk) 11:52, 31 March 2009 (UTC)[reply]
  120. Support but option # gives no examples for link to something like March 24 and I can' think of any reason myself, or any reason to read March 24. Such articles are 100% trivia. Colin°Talk 12:43, 31 March 2009 (UTC)[reply]
  121. Support - date linking almost never adds to an article, and in fact is essentially WP:OVERLINKing.  Frank  |  talk  13:49, 31 March 2009 (UTC)[reply]
  122. Support --Apoc2400 (talk) 15:06, 31 March 2009 (UTC)[reply]
  123. Support - link only a few relevant dates such as July 4, 1776 and July 20, 1969. Bubba73 (talk), 15:54, 31 March 2009 (UTC)[reply]
  124. Support = This is the best of the four choices. --Jc3s5h (talk) 16:37, 31 March 2009 (UTC)[reply]
  125. Support, given most date links would otherwise be unhelpful happenstance and clutter. Gwen Gale (talk) 16:42, 31 March 2009 (UTC)[reply]
  126. Support, indiscriminate linking of dates is pointless. noq (talk) 17:03, 31 March 2009 (UTC)[reply]
  127. Support. Will reduce link density. SlimVirgin talk|contribs 17:33, 31 March 2009 (UTC)[reply]
  128. Support, but I was almost tempted to option 2. The use of the word "relevant" will lead to edit wars down the road, but what's new about that? David Brooks (talk) 17:45, 31 March 2009 (UTC)[reply]
  129. Support the proposal meets my expectations of linking only articles which are directly relevant, not those which will lead to a sea of blue irrelevance. The Rambling Man (talk) 18:12, 31 March 2009 (UTC)[reply]
  130. Support As most logical. Option 4 doesn't seem to preclude the re-creation of mosdate guidelines after they are removed. -- Quiddity (talk) 18:14, 31 March 2009 (UTC)[reply]
  131. Support, they are certainly ugly and apparently unnecessary. --Aqwis (talk) 18:36, 31 March 2009 (UTC)[reply]
  132. Support. I think the date policy at WP:OVERLINK justifies itself. Daniel J Simanek (talk) 18:44, 31 March 2009 (UTC)[reply]
  133. Support - Seems the most sensible solution. Just like with every other possible internal link, we encourage only linking relevant terms that provide addtional context to the reader. Otherwise nearly every word in an article would be linked, which wouldn't help anyone. It's the same for dates. Why there is such an obsession with linking dates all the time, even when such links aren't relevant in any way, is beyond me. --IllaZilla (talk) 19:09, 31 March 2009 (UTC)[reply]
  134. Support. This is common sense. Moreover, I'll propose something that may trigger reactions: Let a bot run and remove ALL month-day links and then re-add the relevant ones. From my experience, the relevant ones are very few. -- Magioladitis (talk) 19:55, 31 March 2009 (UTC)[reply]
  135. Strong support: rarely relevant, and irrelevant links impose a mental cost on readers. Also gives pages a cluttered appearance. Making the links less common would make the remaining dates stand out more, which is probably a good thing in those limited circumstances where they are relevant. CRGreathouse (t | c) 19:57, 31 March 2009 (UTC)[reply]
  136. Support, month-day linking is rarely relevant. — Xavier, 21:17, 31 March 2009 (UTC)[reply]
  137. Support, month-day linking is rarely relevant. — MarkyMarkD (talk) 21:47, 31 March 2009 (UTC)[reply]
  138. Support, month-day linking is rarely relevant, and mainly adds visual clutter. Ground Zero | t 23:39, 31 March 2009 (UTC)[reply]
  139. Support. It's rarely relevant, and this way seems good. Wise dude321 (talk) 01:08, 1 April 2009 (UTC)[reply]
  140. Support. Avoid overload. --Kbh3rdtalk 01:27, 1 April 2009 (UTC)[reply]
  141. Support. Me, too. LilHelpa (talk) 01:42, 1 April 2009 (UTC)[reply]
  142. Support. Very few dates really need to be linked and we do not need an article for every date. --Bduke (Discussion) 02:36, 1 April 2009 (UTC)[reply]
  143. Support. This type of linking clearly amounts to gross over linking of information that does not add to article content. The only issue I have here is that interpretation of what is a relevant date may well be a cause for edit warring in the future. So if this passes, guidance should be to avoid unless it is clear that the link adds to the article and is really, really needed. Vegaswikian (talk) 03:50, 1 April 2009 (UTC)[reply]
  144. Definitely the best option of the bunch. — BQZip01 — talk 05:11, 1 April 2009 (UTC)[reply]
  145. Not sure when a link to a date has helped someone. –thedemonhog talk • edits 06:52, 1 April 2009 (UTC)[reply]
  146. Support. Common sense!! --Popiloll (talk) 07:12, 1 April 2009 (UTC)[reply]
  147. Support. Ruslik (talk) 07:20, 1 April 2009 (UTC)[reply]
  148. Support - Seems the most sensible and efficient way to go about it. Colds7ream (talk) 07:27, 1 April 2009 (UTC)[reply]
  149. Support—Day-month links should be treated like any other potential link but instead of simply removing any mention (option 4) explicit guidance not to link unless the content is germane and topical to the subject should act as a catalyst in turning back the tide and repairing the damage. There is still a fair bit of inertia to link dates out there; we some extra force to help the decelerating won't go astray. However, option 4 could be worth considering in a few years' time. JIMp talk·cont 08:32, 1 April 2009 (UTC)[reply]
  150. Support. A date can be a meaningful link. Where a link is useful it makes sense to do it. SilkTork *YES! 11:06, 1 April 2009 (UTC)[reply]
  151. Weak support—If used properly, this use would be a rare occurrence. Usually the information on the date pages is over weighted toward certain types of events and not evenly weighted globally (battles in the Western world, English language literature etc.). As long as the editor carefully considers whether the info on the date page is relevant to the article, then I would support a limited use of this option. I personally have never found a date link meaningful and find it annoying when I accidently click on a date page. —Mattisse (Talk) 12:43, 1 April 2009 (UTC)[reply]
  152. Support Pointless date links are annoying. Ditto above comment. CheesyBiscuit (talk) 12:47, 1 April 2009 (UTC)[reply]
  153. Support I think that this is probably the best option VJ (talk) 12:59, 1 April 2009 (UTC)[reply]
  154. Support. I understand this to more-or-less mean that date links should be treated like any other (link when non-trivially relevant, otherwise don't), but I oppose #4 because I think that after all this fuss we need some specific guidance on this. Saying nothing just opens the door to endless further disputes. Matt 13:05, 1 April 2009 (UTC).
  155. Support I'm struggling to think of any reason to link month-day, except for the curiosity value of finding out what happened on your birthday - and that's not what an encyclopaedia is for. Any metadata these links provide is so vague as to be worthless. It's not helpful to anyone to know that some unspecified event, related to the subject of the article in some unknown way, happened on that day of the year. Colonies Chris (talk) 13:17, 1 April 2009 (UTC)[reply]
  156. Strong support Linking of irrelevant dates leads to overlinking and dilutes the quality links in an artcle Rubisco (talk) 13:33, 1 April 2009 (UTC)[reply]
  157. Support This sort of linking is clearly over-linking. --Phil Holmes (talk) 15:15, 1 April 2009 (UTC)[reply]
  158. Support, although I recommend much more basic, easy-for-beginners examples of good candidate for date linking and bad candidate for date linking than that given. Professor marginalia (talk) 16:38, 1 April 2009 (UTC)[reply]
  159. - I Oppose all day and month linking; day and month articles are nothing but glorified dab pages. Fightin' Phillie (talk) 18:32, 1 April 2009 (UTC)[reply]
  160. Support - The reader's time is too valuable to divert it onto a topic unrelated to the one they have chosen to read about. EdJohnston (talk) 19:45, 1 April 2009 (UTC)[reply]
  161. Support, this kind of internal wiki-linking adds NO value to an article at all because the date is often IRRELEVANT to the context. It often gives historical information which just isnt needed, if people want it they can search for that particular date (Lil-unique1 (talk) 22:37, 1 April 2009 (UTC))[reply]
  162. Support. Link relevant dates only. Powers T 23:43, 1 April 2009 (UTC)[reply]
  163. Support - guidance is needed at present, although some years from now, option #4 may end up being okay. hamiltonstone (talk) 00:50, 2 April 2009 (UTC)[reply]
  164. Support I would like WP:Popups or some other script to allow me to go to a date page for any date (which would be easier if there was the autoformatting meta data present), but in general excessive irrelevant visible links is bad. Mark Hurd (talk) 02:43, 2 April 2009 (UTC)[reply]
  165. Support Pointless links dilute the value of useful links. Links from an article should only be used to provide further information about the topic (or related topics). Overlinking is distracting to the reader ("what am I missing by not clicking that link?"). Johnuniq (talk) 02:55, 2 April 2009 (UTC)[reply]
  166. Support In nearly all cases, date links are irrelevant and distracting. Exceptions can be made for the few that aren't. Rivertorch (talk) 05:34, 2 April 2009 (UTC)[reply]
  167. Support per Rivertorch.--Aervanath (talk) 05:35, 2 April 2009 (UTC)[reply]
  168. Support When relevant we should link. Taemyr (talk) 05:59, 2 April 2009 (UTC)[reply]
  169. Very reluctant Support because I see no better alternative. In the past I'd be closer to option 4, but now it seems too vague to me.--Yannismarou (talk) 08:09, 2 April 2009 (UTC)[reply]
  170. Support. I've never followed a date link and found anything of relevance or interest, so they are a waste of time to putin, and dilute hight value links. A few relevant dates may benefit from linking.YobMod 09:02, 2 April 2009 (UTC)[reply]
  171. Support This option improves on the amount of relevant links. (with the understanding that overlinking repeated cases of the same link is already discouraged by existing policy) - Mgm|(talk) 10:04, 2 April 2009 (UTC)[reply]
  172. Support Relevance should always be the operative factor in any link. Ed Fitzgerald t / c 13:06, 2 April 2009 (UTC)[reply]
  173. Support as this proposal is consistent with our general approach to linking, and avoidance of overlinking. --R'n'B (call me Russ) 13:31, 2 April 2009 (UTC)[reply]
  174. Support overlinking is distracting. --NullSpace (talk) 15:07, 2 April 2009 (UTC)[reply]
  175. Support. Only link relevant dates; month-day linking is rarely relevant. --Rosiestep (talk) 17:58, 2 April 2009 (UTC)[reply]
  176. Support. Commemorative days are the obvious need for a link, but limiting it to ONLY that is too restrictive. --Alvestrand (talk) 18:46, 2 April 2009 (UTC)[reply]
  177. Support. Date links were generally irrelevant and just added to link overload, and I think they should be generally avoided. However, if the author thinks that a specific date is truly relevant, then they should be allowed to link. Esobocinski (talk) 19:58, 2 April 2009 (UTC)[reply]
  178. Support. Linking dates only adds to the "sea of blue" problem; only when strictly necessary should a date article be linked to, as we do for every other article. Steve T • C 22:06, 2 April 2009 (UTC)[reply]
  179. Support – While some editors might interpret this rule more loosely than others (such as using various "rationals" to support the linking of all months/days in an article), a formatting change is needed to reduce link density and irrelevance. momoricks (make my day) 01:12, 3 April 2009 (UTC)[reply]
  180. Support - Overlinking is something good to avoid - if a date link is there, then it should be there for relevance. Enforcing the rule will be time consuming though, so as long as there's a vigilant network for doing so, I'm in favour of Option 1 Australian Matt (talk) 02:10, 3 April 2009 (UTC)[reply]
  181. Support - Date links are usually irrelevant for readers. Cacycle (talk) 02:31, 3 April 2009 (UTC)[reply]
  182. Support This is the only option of the four that makes any sense to me.Yilloslime TC 04:35, 3 April 2009 (UTC)[reply]
  183. User:MC10/S - seems like the best option of the 4 and prevents overlinking. MathCool10 Sign here! 04:36, 3 April 2009 (UTC)[reply]
  184. Support I think users should have the option of seeing all dates linked, by means of improved date autoformatting/autolinking software — but I think the default should be something along the lines of option 1. --Sapphic (talk) 06:11, 3 April 2009 (UTC)[reply]
  185. Pile on support per Duh. Wikilinks are there for a reason, when the reason is there, so should the wikilink.Headbomb {ταλκκοντριβς – WP Physics} 06:55, 3 April 2009 (UTC)[reply]
  186. Me too--ClubOranjeT 07:37, 3 April 2009 (UTC)[reply]
  187. Support despite the destructive impact on Wikington Crescent. Orpheus (talk) 10:53, 3 April 2009 (UTC)[reply]
  188. Support. I thought about the "remove guidance" option but that seems likely to lead to more arguments; guidance is just what is needed. Mike Christie (talk) 11:02, 3 April 2009 (UTC)[reply]
  189. Why would people use these links? Probably not to find a definition of April 14, so we don't need a lot of linking to dates and years. Samulili (talk) 12:40, 3 April 2009 (UTC)[reply]
  190. Support linking in only relevant cases. It is pointless to link to every date, or even every date that is distantly related to the article in which they appear. Linking these dates should only be used when obviously relevant. The Seeker 4 Talk 16:00, 3 April 2009 (UTC)[reply]
  191. Support. This option just emphasizes the idea against overlinking for which dates have traditionally been overlinked too much. --seav (talk) 16:51, 3 April 2009 (UTC)[reply]
  192. Support per relevance and populating What links here, which is often quite useful. Bendono (talk) 18:15, 3 April 2009 (UTC)[reply]
  193. Support I never understood why there were links to those articles. Deegee375 (talk) 21:16, 3 April 2009 (UTC)[reply]
  194. Support. Relevance should be the reason for a link, whether a date or otherwise. —ADavidB 06:04, 4 April 2009 (UTC)[reply]
  195. Support Reduce unnecessary and unhelpful links. Date-month link will almost always be pointless. PamD (talk) 10:19, 4 April 2009 (UTC)[reply]
  196. .Support Best option. Will prevent needless wikilinking.Mosedschurte (talk) 11:46, 4 April 2009 (UTC)[reply]
  197. Support Seems like the best way of doing it, and (off hand) follows existing guidelines on when to wikilink. ~~ [ジャム][t - c] 14:18, 4 April 2009 (UTC)[reply]
  198. Support Best of all four options. --Patar knight - chat/contributions 18:32, 4 April 2009 (UTC)[reply]
  199. Support Treat month-day like anything else: link only if relevant, which they rarely are. Struway2 (talk) 20:01, 4 April 2009 (UTC)[reply]
  200. Support Linking every date is obnoxious and contributes to information pollution, clouding the reader's ability to get to the meat of the topic and sort out relevant and interesting links from date links which contribute nothing to the article, nor do they contribute to anyone's ability to find information relevant to a specific date. There are too many such date links to be useful. Nuke all of 'em but the most specifically relevant to a topic. -- btphelps (talk) (contribs) 01:25, 5 April 2009 (UTC)[reply]
  201. Support, second choice (#2 is my first choice.) – Quadell (talk) 01:31, 5 April 2009 (UTC)[reply]
  202. Support Shoemaker's Holiday (talk) 06:08, 5 April 2009 (UTC)[reply]
  203. Support, have never seen the need for date linking. Can't actually think of any case where it is necessary. Jezhotwells (talk) 12:18, 5 April 2009 (UTC)[reply]
  204. Support. Per Btphelps. — Σxplicit 19:05, 5 April 2009 (UTC)[reply]
  205. Support Removes unnecessary links and makes it easier to to read Hohohob (talk) 01:17, 6 April 2009 (UTC)[reply]
  206. Support I see no need for any bare date links. Ever.--2008Olympianchitchat 05:03, 6 April 2009 (UTC)[reply]
  207. Support -- Same principle as for all links. KISS! -- William Allen Simpson (talk) 14:25, 6 April 2009 (UTC)[reply]
  208. Support Linking useful if there is a genuine connection, but not otherwise. More general linking leads to the ludicrous and overwhelming situation where trivial dates are linked, such as the date a web page was accessed (I've seen this more than once!). Richard New Forest (talk) 14:58, 6 April 2009 (UTC)[reply]
  209. Support add practically nothing constructive whilst diluting usefulness of What Links Here, Related Changes, etc. No need to link to lists which are trivially bound by astronomical constants, except in the rarest of occasions. Knepflerle (talk) 16:42, 6 April 2009 (UTC)[reply]
  210. Support This option provides a clear and consistent recommendation, allows for consistent appropriate linking, and will help minimize overlinking. —Danorton (talk) 18:16, 6 April 2009 (UTC)[reply]
  211. Support Least complicated and most common sense option. Peter Isotalo 18:40, 6 April 2009 (UTC)[reply]
  212. Support, Why does everything turn into such a debate. This makes sense, the others do not.--Mrboire (talk) 20:01, 6 April 2009 (UTC)[reply]
  213. Support — Coherent, consistent, common-sense link policy calls for treating dates the same as we treat any other potentially linkable word, phrase, or number: we link them only if they are really relevant to the article at hand. We don't link words just on speculation that the reader might happen to find the link target interesting, or because we happen to be using a linkable word as part of the article text. —Scheinwerfermann T·C00:44, 7 April 2009 (UTC)[reply]
  214. Support -- Eliminates a lot of unnecessary link clutter, while still keeping the option available for cases where the links would actually be relevant. Brian Powell (talk) 03:37, 7 April 2009 (UTC)[reply]
  215. Support All links should be included only if relevant, right? Why should dates be any different? The Grand Rans (talk) 03:51, 7 April 2009 (UTC)[reply]
  216. Support. It is unconscionable to adopt a policy by which supplying irrelevant links is a feature of the default practice. Most occurrences of dates, in most contexts, are simple markers on a timeline; they are not gateways to any sort of rich and relevant background. In most cases, therefore, a link would make a false promise, and distract from the force and immediacy of the text.–¡ɐɔıʇǝoNoetica!T– 07:36, 7 April 2009 (UTC)[reply]
  217. Not sure if I understand the difference between this and Option #2, though. (It seems like such an edge case.) --Cyde Weys 15:44, 7 April 2009 (UTC)[reply]
  218. Support - guides the reader to other articles only when valuable to do so. --4wajzkd02 (talk) 17:58, 7 April 2009 (UTC)[reply]
  219. Support Treat it like any other link; we deplore overlinking, and mindless policy-driven month/day linking has long been an egregious example. Acroterion (talk) 18:57, 7 April 2009 (UTC)[reply]
  220. Support Date links are rarely relevant IMHO, but I wouldn't object to there being language to allow linking them in certain cases or when there is a concensus. dissolvetalk 19:55, 7 April 2009 (UTC)[reply]
  221. Support -- Acroterion said it best...Treat it like any other link. Link when relevant. Farmercarlos (talk) 20:14, 7 April 2009 (UTC)[reply]
  222. Support...whatever the hundred or so people said before me. But really, this is better than either alternative (link all, or link none: either hampers usability). ~user:orngjce223 how am I typing? 20:15, 7 April 2009 (UTC)[reply]
  223. Support - yup. Xenus (talk) 09:56, 8 April 2009 (UTC)[reply]
  224. Support there's no need to link dates except in rare circumstances. Guidance is needed to prevent edit wars over this, and this seems the best option. Nick-D (talk) 11:19, 8 April 2009 (UTC)[reply]
  225. Support Does this section read "use resonable judgement." I'm a fan of that! Hipocrite (talk) 14:12, 8 April 2009 (UTC)[reply]
  226. Support best option --Armchair info guy (talk) 15:00, 8 April 2009 (UTC)[reply]
  227. Support Date links are almost always irrelevant. Link when relevant only, it's a far simpler rule to work with. --GedUK  20:09, 8 April 2009 (UTC)[reply]
  228. Support Let the writer decide and others edit what is relevant. We'll end up with completely blue pages if we start down this path! Wikipeterproject (talk) 21:23, 8 April 2009 (UTC)[reply]
  229. Support. Seems appropriate to link only relevant dates, no context for dates, i.e. WP:OVERLINK. Rehevkor 01:35, 9 April 2009 (UTC)[reply]
  230. Support. If a link adds value to an article, include it. If not, don't. EyeSerenetalk 09:55, 9 April 2009 (UTC)[reply]
  231. Support. I see this problem as one pertaining to relevancy, and option 1 seems to solve this problem just perfectly. --A.K.R. (talk) 16:21, 9 April 2009 (UTC)[reply]
  232. Support I only wish to see links relevant to an article. Finavon (talk) 19:03, 9 April 2009 (UTC)[reply]
  233. Support I find irrelevant links reduce readability. It's like all the linked dates are read by Billy Mays in my head. Cstaffa (talk) 23:58, 9 April 2009 (UTC)[reply]
  234. Support Events that simply happened on any given month-day combination is not an encyclopedic grouping, it's just trivia. Deep down the community recognizes this; that's why we don't have Category:March 24. Arbitrarily connecting two topics because the Earth happened to be in the same position relative to the sun is not at all link-worthy, it is utterly trivial. These month-day combinations are only encyclopedic when the date itself is representative of a specific event: July 4 and September 11 are common names for Independence Day and the destruction of the Twin Towers, respectively; by contrast, Dec 7, however infamous, is not generally used as a synonym for the bombing of Pearl Harbor. Ham Pastrami (talk) 06:15, 10 April 2009 (UTC)[reply]
  235. Support to avoid overlinking. Fletcher (talk) 19:25, 10 April 2009 (UTC)[reply]
  236. Support Put an end to this silly overlinking.EEng (talk) 19:28, 10 April 2009 (UTC)[reply]
  237. Support, linking dates provides no relevant information in the majority of cases. Corn.u.co.piaDisc.us.sion 00:14, 11 April 2009 (UTC)[reply]
  238. Support, linking to a date usually adds nothing to an article. Do U(knome)? yes...or no 01:23, 11 April 2009 (UTC)[reply]
  239. Support. Linking of dates other than according to this principle is just annoying visual noise. Removing guidance altogether is a recipe for future conflict. The best option is a simple guideline like this one. McKay (talk) 02:04, 11 April 2009 (UTC)[reply]
  240. Support  Like any other term, a date should be linked only when appropriate, according to the editors' judgment. Michael Z. 2009-04-11 16:15 z
  241. Support I think that this is the best option as long as "relevant" is defined liberally. I think that too many links is better than too few. Captain panda 17:09, 11 April 2009 (UTC)[reply]
  242. Although I'd prefer option #3, this seems like an adequate compromise. Titoxd(?!? - cool stuff) 18:25, 11 April 2009 (UTC)[reply]
  243. Support. My heart says remove all guidance, but my editorial head says we've got many beginners who love to make a sea of blue links, so let's tell them no. Jim.henderson (talk) 20:49, 11 April 2009 (UTC)[reply]
  244. Support, erring on the side of not linking (if some other autoformat option is available).--Fabrictramp | talk to me 23:19, 11 April 2009 (UTC)[reply]
  245. Support - Option 1 seems to make the most sense as links should only really be provided if they would be helpful for the reader on the topic they are reading. Removing all guidance would just be unhelpful and would cause future conflicts. Camaron | Chris (talk) 14:01, 12 April 2009 (UTC)[reply]
  246. Support This seems to make the most sense—only links that are relevant, and all links that are relevant. It's worth having policy on dates as well as other links.—Jchthys 14:36, 12 April 2009 (UTC)[reply]
  247. Support This is the only option that makes sense. -- M2Ys4U (talk) 15:57, 12 April 2009 (UTC)[reply]
  248. Support We should be strict about this. Such links should share an important connection with that subject Let relevancy rule, with a tight interpretation of "relevancy". Reconsideration (talk) 18:27, 12 April 2009 (UTC)[reply]
  249. Support; these links are usually unnecessary. Option 4 would be fine too. --Spangineerws (háblame) 19:52, 12 April 2009 (UTC)[reply]
  250. Support - I expect that hardly ever would these links be appropriate. —Mattisse (Talk) 22:35, 12 April 2009 (UTC)[reply]
  251. Support This strikes me as the best option of the four. Removing all date linking is too harsh, offering no guidance is a mess, and allowing the first date reference to be linked is useful for years but not full dates. --Perry Middlemiss (talk) 00:31, 13 April 2009 (UTC)[reply]
  252. I find this the most reasonable option: it avoids undue rigidity, but offers, at the same time, simple guidance based on established linking practice. Waltham, The Duke of 01:07, 13 April 2009 (UTC)[reply]
  253. Support The most appropriate balance between an absolute ban and overlinking. Dl2000 (talk) 01:34, 13 April 2009 (UTC)[reply]
  254. Support Links should always be relevant, and dates should be no exception. In addition, if the resolution of the autoformatting question is that autoformatting is not desired by the community, or if autoformatting is desired and the eventual implementation of it does not rely on linked dates, links that were solely for the purpose of autoformatting will need to be removed. Two important points related to this, however. First, no links should be removed until the question of autoformatting is decided. Second, the most efficient method of removing these links is through automated and semi-automated methods. However, since it is impossible for bots and scripts to determine relevancy. a method must first be created to identify and protect links that are determined by editors to be relevant — this, for me, is the main issue related to the current arbitration. Mlaffs (talk) 12:20, 13 April 2009 (UTC)[reply]
  255. Support Articles that have dozens of dates, all linked, simply look cluttered. This indicates that some editors are not thinking about what will help the reader, but are just following a formula. Chris the speller (talk) 14:14, 13 April 2009 (UTC)[reply]
  256. Support. This proposed standard relies upon editors' discretion, but that's not unusual for an MOS item. In this case, although that means that there isn't a simple algorithm that covers all possible instances (relevance is context-dependent), the likelihood is high that the end result will be broadly acceptable to the users of the encyclopedia. TheFeds 16:30, 13 April 2009 (UTC)[reply]
  1. Seems a reasonable solution to allow the month-day articles not to become orphaned. My preference for options is in the order 2,4,1,3. — Arthur Rubin (talk) 23:44, 29 March 2009 (UTC)[reply]
  2. Support options 1 and 2, except "only" part in option 2. Note: marking in both lists for clarity. davidwr/(talk)/(contribs)/(e-mail) 18:33, 30 March 2009 (UTC)[reply]
  3. Support although this is very similar to option 1 - commemorative dates probably do count as relevant dates - so I would be happy with either. Perhaps date articles should be treated as lists, and linked to from "see also" where appropriate? Mike Peel (talk) 18:58, 30 March 2009 (UTC)[reply]
  4. Support Option 2 is clearer than option 1, since it is not clear what would be "relevant" for option 1 purposes, but option 2 is clearly defined. I agree we don't want to orphan the date articles, and this seems like the way avoid that. Option 4 is ridiculous. Richard75 (talk) 17:19, 31 March 2009 (UTC)[reply]
  5. Support - Option #1 is too broad. --David Göthberg (talk) 16:39, 1 April 2009 (UTC)[reply]
  6. Support. Option 2 is stricter than 1. If option 2 fails to win, count my vote to support option 1. −Woodstone (talk) 11:30, 2 April 2009 (UTC)[reply]
  7. Support, I want the strictest avoidance of overlinking. Tempshill (talk) 18:57, 2 April 2009 (UTC)[reply]
  8. Support, though only very marginally over option 1 - they both make sense. Shimgray | talk | 13:57, 3 April 2009 (UTC)[reply]
  9. Support, Option 1 leaves too many pointless links. -- KelleyCook (talk) 15:51, 3 April 2009 (UTC)[reply]
  10. Support — Malik Shabazz (talk · contribs) 19:45, 3 April 2009 (UTC)[reply]
  11. Support, first choice. – Quadell (talk) 01:31, 5 April 2009 (UTC)[reply]
  12. Support Of lack of an option that simply eliminates all possible date linking, this will provide the least blue. Date links have no function and reduce readability significantly. Dates are the worst—they look hideous, and serve no practical function for the reader. Arsenikk (talk) 19:14, 6 April 2009 (UTC)[reply]
  13. Support - I think month-day links should generally be avoided, but that they would be acceptable in articles referring to a holiday or other event that is intrinsically linked with a particular date. Robofish (talk) 23:56, 7 April 2009 (UTC)[reply]
  14. Support Option 1 leaves too many pointless links. Kennedy (talk) 15:10, 8 April 2009 (UTC)[reply]
  15. Support: I prefer this as it is stricter than option 1, but otherwise count this as secondary support for option 1. Option 3 is boneheaded; it misapprehends why we link first occurrences of many things ("albinism", "rugby union", etc.), but do not at all link other things ("woman", "night", etc.) except in very particular and peculiar contexts. Option 4 is simply pointless, since as disputations over linking dates re-arise, the necessity to add guidance on the matter to the MOS will automatically also re-arise. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:57, 9 April 2009 (UTC)[reply]
  16. Support. Options 1 and 3 are overlinking. Option 4 is the road to inconsistency and edit wars. This is a good compromise. – IbLeo (talk) 05:22, 10 April 2009 (UTC)[reply]
  17. Support Second choice would be #1 Agathoclea (talk) 14:45, 12 April 2009 (UTC)[reply]
  18. Support - Followed (in order) by #1, #4, and #3. Automated or default removal of dates should not be implemented, however. I would like to see date linking die in a mostly natural way, but I would like to see it die. IF the date is significant to the article, that's one thing. But linking every date is a waste of the reader's time. --Willscrlt (→“¡¿Talk?!”) 13:21, 13 April 2009 (UTC)[reply]
  1. This is how everything else is linked, I don't see why dates should be treated any differently.-Jeff (talk) 00:10, 30 March 2009 (UTC)[reply]
    Not too bothered really, but I think it is better when the days & months are linked. Unsigned contribution struck out,  Sandstein  20:38, 31 March 2009 (UTC)[reply]
  2. Support, But only for certain dates (like birth and death) I am going to be the apparent oddball here and say that I think that overlinking is bad but there is nothing wrong with linking the dates the first time, or maybe even twice if one is an infobox and 1 is in the article itself. We have to remember that WP is not a paper encyclopedia, it is a 4 dimensional online encylclopedia that allows pages to be "linked" to other pages. I alot of folks have argued that it adds little value to them, but if I am reading an article and want to look at the date why should I have to type it in to go see it. Also, if we are going to remove links to dates then should we also consider deleting the date articles themselves, we are going to get quite a few orphaned date articles of we remove all links.--Kumioko (talk) 20:18, 30 March 2009 (UTC)[reply]
  3. Support, Personally I love links, it is the whole reason why WP > paper encyclopedia, will the data necessarily point to something germane to the article at hand? Perhaps not, but that doesn't mean that the reader won't find whatever it links to interesting. We might as well take out 'random page'. I would have voted for 4. But worried that it will simply be used to removed linking, not further it. Unomi (talk) 16:44, 31 March 2009 (UTC)[reply]
  4. I guess I'm rooting for the underdog here, but I feel that linking dates adds an inherent depth to wikipedia which is probably unobtainable anywhere else. I detest overlinking and don't think that every date in an article should be linked, maybe option 2 1/2 ? Like Kumioko said only birth/death dates, or the relative equivalent - the date of an important discovery, but not every date at Handel works. -- ΖαππερΝαππερ BabelAlexandria 08:26, 1 April 2009 (UTC)[reply]
  5. Strong Support. I think it is part of what makes Wikipedia so cool: If a date is contained somewhere in an article, you are able to see what was going on at the same time (which is quite important if you are for example researching something...) Also, personally, I like reading the month-day pages linked from articles. They give a link to knowlage I probaly wouldn't have found else and make interesting connections between articles. They're just a cool thing. Also, what is relevant to one may be unrelevant to someboedy else... How do you want to determine what is relevant or what is not? For me, these links are relevant since they give the opportunity to find and discover other interesting articles better than any other feature. Old Death (talk) 21:42, 2 April 2009 (UTC)[reply]
  6. Strong Support. Per above, adding that serendipity sometimes plays a useful role in research.[21]Daytrivia (talk) 22:59, 5 April 2009 (UTC)[reply]
  7. Support - I can't see any convincing argument against it. Deb (talk) 18:02, 6 April 2009 (UTC)[reply]
  8. I support this option. My reasons are the same as those explained by everyone else who supports this option. Go links!Simplebutpowerful 00:12, 9 April 2009 (UTC)[reply]
I support Option #4 (removal of guidance)
  1. Strongly support. All links are required to be relevant and helpful to the reader. what more do we need to say about these? Septentrionalis PMAnderson 23:32, 29 March 2009 (UTC)[reply]
    • This is the only way to ensure that date links are treated like other links. I observe that, despite the successful campaign to remove this objective from this poll, this equality has received support from support for all forms of language.
    • Even #3 has been read to impose restraints on date links which do not apply to other links, as in These comments. #1 and #2 have been used to justify extreme and sweeeping removals.
    • I therefore strongly oppose #1, Oppose #2 (which at least concedes a major use of these links) and weakly oppose #3. Septentrionalis PMAnderson 00:38, 30 March 2009 (UTC)[reply]
  2. Yes please; take as much as possible out of the hands of the hands of the people who made this clusterfuck in the first place. Mr.Z-man 01:10, 30 March 2009 (UTC)[reply]
  3. Strongly support as first preference. It doesn't seem that the date guidelines in MOS actually help anyone to do anything which they wouldn't otherwise be doing, and the constant edit wars show how little consensus the whole concept of a manual of style has. AKAF (talk) 07:04, 30 March 2009 (UTC)[reply]
  4. Option #3 is just silly: other than for the current form of date autoformatting (i.e. Dynamic Dates), I can see no reason whatsoever to add any link in the sentence "Retrieved on 30 March 2009." at the end of a citation. Option #1 spends way too many words, and makes the point of "relevance of the content of an article rather than of its topic", which some editors like so much way too explicit. (I wonder if they would remove the link to Ronald Reagan in Santa Fe Trail (film) on the basis that most of the former article is about his career as a politician, which couldn't possibly be relevant to a film in which he acted decades earlier.) Also, it seems to acknowledge that the month-day articles are listcruft, which can be taken as decreeing that they should forever continue to be such. (Will it still be so useless to link the article April 23 from St George's Day if it becomes like this?) Option #2 happens to match somewhat closely the criteria I would personally use to determine when to link such articles (except that I would say "event" rather than "commemoration"—how is linking 21 June from Solstice any worse than linking 17 March from St Patrick's day?—and I would add "... and eponymous events": ideally September 11 could contain a section about how that phrase has become a synonymous with the attacks of 11 September 2001, which would be outside the scope of the already very long article about the latter, but which could be linked to by it). But I don't think we need explicit instruction on when to link dates any more than we need explicit instruction on when to link common names of animal species: the Wikipedia guidelines are already bloated enough without WP:Linking mentioning that St Patrick's Day isn't celebrated on 17 March in some years. Hence, I support option #4, although I wouldn't oppose adding "...and days of the year" to the third bullet point of WP:LINK#What generally should not be linked. (FWIW, my preferences are 4-2-1-3 in decreasing order.) --A. di M. (talk) 09:14, 30 March 2009 (UTC)[reply]
  5. Support. Too many events are simply irrelevant, and would rather metadates be used. Day/Month alone is next to pointless. -- billinghurst (talk) 10:32, 30 March 2009 (UTC)[reply]
  6. Support, MOS should not be dictating when to link as it is a Style Guide, not a Content Guide. MOS overreached when they tried to dictate when to link. —Locke Cole • t • c 11:02, 30 March 2009 (UTC)[reply]
  7. Support I see no fundamental reason why 1) Wikipedia should have uniform expectations or 2) such expectations should be enforced. Jclemens (talk) 16:29, 30 March 2009 (UTC)[reply]
  8. Support I wish I could say something more than what has been clearly -- if not forcefully -- stated above. There are many, many useless links in articles that have nothing to do with days, months or years, but for some reason a group of Wikipedians have decided to focus their attentions on removing all date-related links, instead of finding & removing these unhelpful links. -- llywrch (talk) 17:03, 30 March 2009 (UTC)[reply]
  9. Strong Support as I found it very useful and interesting to be able to click a date and see what other events happened then. Yes, there were (and still are) a lot of articles linked to specific dates (as happens in a world with a long history), but I think that argument is irrelevant. All this worry about articles having too many links to them is pointless worry as we will have more and more articles linked to each other as the encyclopedia grows. Are we going to start limiting the number of links which can be placed into articles when we reach 5 or 10 million articles just so we don't have "too many links" to any given article? That's just absurd. We're going to have to accept that many articles on main topic are going to have hundreds, thousands, and perhaps tens of thousands of links to them. In the case of dates, it's likely they will be on the high end of things, but that's what happens when an online encyclopedia grows. And the argument that someone is going to have to go put back the links that someone removed is absurd. Just run the same bots again, only in reverse. It certainly won't be any more difficult than it was to remove them all. I also strongly oppose #1 and #2 and #3 is too arbitrary. ···日本穣? · Talk to Nihonjoe 19:20, 30 March 2009 (UTC)[reply]
  10. Support per Nihonjoe --Cybercobra (talk) 19:50, 30 March 2009 (UTC)[reply]
  11. Support. I've been aware of these discussions for a while and today I saw the watchlist notice so I decided to finally make a comment on the topic. I find these proposals CREEPY. This is much more than when to use italic text or in what way bullet points should be used in an article. This is about links, the fundamental infrastructure of the web and the connections between articles on Wikipedia. Whether or not a specific date article requires a link is not the point, such a blanket guideline is too much and it'd be better handled on a case by case basis. --Bill (talk|contribs) 20:41, 30 March 2009 (UTC)[reply]
  12. Support Let the editors maintain control over what is and isn't relevant. bots do enough as it is — Ched ~ (yes?)/© 21:27, 30 March 2009 (UTC)[reply]
  13. Support Dates should be treated like anything else, if they are relevant to the article they can be linked. TJ Spyke 21:36, 30 March 2009 (UTC)[reply]
  14. Support We need exactly one rule for when to use links, dates are not special. When I click on a link I expect useful information in the context of what I am reading. Date categories serve the purpose of linking in time similar events and can be specific to the type of article. --NrDg 00:09, 31 March 2009 (UTC)[reply]
  15. Support. Many dates require linking, regardless - and besides that, Infoboxes look much nicer when dates are highlighted. Hence, I support #4. Daniel Benfield (talk) 01:23, 31 March 2009 (UTC)[reply]
  16. Support It just doesn't matter so let people do what they want. hulmem (talk) 03:18, 31 March 2009 (UTC)[reply]
  17. Option one is just a watered-down version of this, which is more elegant and relies (gasp!) upon the judgment of the community. Somehow I think we can handle treating dates like other links and having one less MoS to have to look at!otherlleftNo, really, other way . . . 03:56, 31 March 2009 (UTC)[reply]
  18. I am hard pressed to see any use for articles that list events that happened on a certain date (month-number) throughout the centuries. What difference does it make that Pierre Corneille was born on June 6 (1606, in the Julian calendar, just by happenstance the same combination of a month and a number as D-day, 1944, in the Gregorian calendar)? And what about those civilizations that don't use the Western calendar? Thus I would never choose to link a date, and I would certainly not liked to be forced to. For what it's worth, I normally will delete date links in any article I am editing. Thus I support Option 4, or maybe Option 1. Sincerely, GeorgeLouis (talk) 05:46, 31 March 2009 (UTC)[reply]
  19. I dont care if dates are linked or not in general, but individual editors in a particular article can best determine this. This option also allows things like "births in YEAR", etc. dm (talk) 06:01, 31 March 2009 (UTC)[reply]
  20. Strong support. Only one of the options which stands a cat in hell's chance of actually being followed. Physchim62 (talk) 18:59, 31 March 2009 (UTC)[reply]
  21. Strong support reduce the number of rules and increase creativity J04n(talk page) 01:19, 1 April 2009 (UTC)[reply]
  22. ✔ Yep. It's a wikilink, so why shouldn't it be treated as any other wikilink? — Twas Now ( talk • contribse-mail ) 09:25, 1 April 2009 (UTC)[reply]
  23. Strong support I really agree with J04n's comment. With Wikipedia edited by many contributors, with different ideas of appropriateness, imposing one Procrustean solution is stupid. (I felt the same about year linking, and I wonder why the two are being polled separately.) -- BRG (talk) 14:46, 1 April 2009 (UTC)[reply]
  24. Support Let editors determine appropriate implementation at the article or project level. Content discussions are not under the purview of MOS. --guyzero | talk 20:48, 1 April 2009 (UTC)[reply]
  25. Strong support. Anything that doesn't need to be in the MOS, shouldn't be in the MOS. Trust the editors to know what's best in each set of circumstances. – iridescent 20:50, 2 April 2009 (UTC)[reply]
  26. Support this proposal that leads to the least rule-creep.—S Marshall Talk/Cont 22:27, 2 April 2009 (UTC)[reply]
  27. Support per guyzero above. — Hex (❝?!❞) 15:28, 4 April 2009 (UTC)[reply]
  28. Support. Do we really need the instruction creep? bibliomaniac15 23:47, 4 April 2009 (UTC)[reply]
  29. Support. Enough instructions already.--catslash (talk) 23:54, 4 April 2009 (UTC)[reply]
  30. Support. However, leave a comment that the style used to be to link every date, and many articles still do this, but now dates should only be linked if the they follow the general rules. JonH (talk) 09:08, 5 April 2009 (UTC)[reply]
  31. Support. Treating dates like other links does not seem much different from proposed solutions. And yet, the cost of a specific guideline is nonzero. --Thomas Btalk 17:00, 5 April 2009 (UTC)[reply]
  32. Strong Support Where to add links and what to link to is currently at the discretion of the editor. I would need a compelling reason to change this. Phil_burnstein (talk) 09:45, 6 April 2009 (UTC)[reply]
  33. Support. Reconsidering my position. Eluchil404 (talk) 22:29, 6 April 2009 (UTC)[reply]
  34. Support. Every unnecessary piece of policy should go.--Pgallert (talk) 09:49, 7 April 2009 (UTC)[reply]
  35. Support. Editors can make up their own minds. Too many rules and they're unlikely to be followed. G-Man ? 22:48, 7 April 2009 (UTC)[reply]
  36. Support. This or option three, but mostly I think editors should decide. I'm not troubled by overlinking, and I believe attempts to make Wikipedia conform to a consistent style are futile and foolish. There's already too much excuse for rule-mongering editor-hobgoblins to tromp on newcomers. Fijagdh (talk) 21:27, 8 April 2009 (UTC)[reply]
  37. Support (or rather, oppose everything else) - years are one thing, but days are usually pointless. Leave it up to the editors' discretion. --Alinnisawest,Dalek Empress (extermination requests here) 03:10, 10 April 2009 (UTC)[reply]
  38. Support I've never understood the need for these links. --Auntof6 (talk) 07:17, 11 April 2009 (UTC)[reply]
  39. Support The date pages have nothing of consequence to these articles, end the clutter and get rid of them all. You can still find them by typing it in the search box.- J.Logan`t: 11:23, 11 April 2009 (UTC)[reply]
  40. Support perhaps with a caveat that we add a small non-guidance statement to MOSNUM or MOSLINK stateing explicitly "Links to dates are not treated any differently than links to other articles." or some such. Not necessary, but may be helpful. --Jayron32.talk.contribs 14:57, 12 April 2009 (UTC)[reply]
  41. Support. Dates are not special. Jayron32's suggestion for a caveat is imminently sensible too; given the history of the affair, a sentence that explicitly states "not special" might be a good idea. -- Fullstop (talk) 12:08, 13 April 2009 (UTC)[reply]
  42. Strongly Support: Let the editors decide (as they should with so very much else that the MoS and outside 'bots are trying to decide for them) what's useful or helpful and what isn't. The editors who are actually concerned with the particular topic at hand will disagree at times, but they can argue it out the way they decide any other secondary matter on the basis of specific issues. —— Shakescene (talk) 20:24, 13 April 2009 (UTC)[reply]
Other comments
Doesn't consensus decide what is releavnt, as with all content? Voting for no linking ever would mean over-riding consensus on a page, in which linking a date is really useful (can't think when, but it could happen!). Guidelines should be flexible wrt consensus.YobMod 09:04, 2 April 2009 (UTC)[reply]
Too right it does. That's what collaboration is all about!Wikipeterproject (talk) 21:25, 8 April 2009 (UTC)[reply]

From Wikipedia:Village_pump (technical)#CSS link color settings for mw-formatted-date. After some testing, it was found that following addition to ones CSS (at Special:Mypage/monobook.css if you are using the standard style sheet) disables the display of wikilinks around dates:

span.mw-formatted-date a {color: black;}

Hope this helps. -- User:Docu

Thanks, Docu ... except that I like my wikilinks. Thing is, smart linking—that is, a selective approach—is the way to optimise the utility of linking for our readers and ourselves. (I do turn the bright blue down to a darker shade of blue, but that may be because my Mac monitor is pretty strong on colour display. My user page has instructions on how to do so.) Tony (talk) 14:56, 6 April 2009 (UTC)[reply]
Personally, I wasn't under that impression. I'm sure you'd be better off if you just changed the link color of auto formatted dates. The articles will always disappoint you in the context of most articles they are linked from, similar to other frequently linked articles, e.g. United States. This unless you know how they are structured and what they include. -- User:Docu

Year linking

Background statement

Year linking is when a specific year is linked to in an article (1987), or a pipe link to a year article on a specific topic ([[1987 in sports|1987]]).

Advantages of year linking
  1. Provides easy access to year articles.
  2. Populates "what links here" pages with possibly relevant data.
  3. Allows readers to browse freely through global historical context via year.
Disadvantages of year linking
  1. Rarely relevant or useful to achieving a greater understanding of an article's topic.
  2. "What links here" often generates many false positives and sources of questionable utility or relevance; the search box can easily be used instead.
  3. If added indiscriminately, articles may become overlinked and high-value links would be diluted.
Advantages of year markup (whether or not it entails linking)
  1. Simplifies automated processing of article text (i.e. gathering metadata).
Disadvantages of year markup
  1. Complicates the editing process and contributes to instruction creep.
  2. There are already powerful tools for gathering "metadata", including the search box and by adding "site:wikipedia.en" to a google search for years.
Advantages of removing guidance on year links
  1. Year links do not differ significantly from other links; year articles should be treated like any other articles for this purpose. Any specific guidelines on year links that do not apply to all links are instruction creep.
Disadvantages of removing guidance on year links
  1. The linking of year articles needs special guidance because they are not like ‘normal’ articles—almost all year articles are lists of events, related only by the coincidence of occurring in the same year. Such lists almost never provide a context that helps in the understanding of an article that links to them, and therefore should not be linked to. If year articles are ever improved to the point where they do indeed provide historical context, this guidance may then need to be reviewed.


If supported through consensus, one of the following four proposed guidelines (Options 1, 2, 3 or 4) would be added to Wikipedia:Manual of Style (dates and numbers)#Linking and autoformatting of dates and Wikipedia:Linking#Chronological items. Please respond below the four options.

Year articles (1795, 1955, 2007) should not be linked unless they contain information that is germane and topical to the subject matter—that is, the events in the year article should share an important connection other than merely that they occurred in the same year. For instance, Timeline of World War II (1942) may be linked to from another article about WWII, and so too may 1787 in science when writing about a particular development on the metric system in that year. However, the years of birth and death of architect Philip C. Johnson should not be linked, because little, if any, of the contents of 1906 and 2005 are germane to either Johnson or to architecture.

Years: Option #2 (Option #1 plus birth/death years, etc)

Year articles (1795, 1955, 2007) should not be linked unless the year is particularly relevant to the topic; that is, a seminal event relevant to the subject of the article occurred in that year. Examples may include the birth and death of a person, and the establishment and disestablishment of an organization.

Year articles may be linked on their first occurrence in an article, regardless of how relevant the two articles are to each other.

Years: Option #4 (removal of guidance)

All specific language dealing with year links will be removed from the Manual of Style and related pages. This will have the effect of treating year links like any other potential link. (This need not include mentions of linking in the context of auto-formatting; whether these are current guidance or a historic note depends on the question on auto-formatting above.)

Year-linking responses

Please indicate your support vote under ONE option, accompanied by a concise explanation for your choice. Your explanation is important in determining the community consensus.
  1. Best option out of the four. If the year link is relevant to the article, link it. If not, don't. Steve Crossin Talk/24 23:16, 29 March 2009 (UTC)[reply]
  2. I would prefer absolutely no links at all, because they are hardly relevant and seldom help deepen understanding of the subject. Let common sense prevail. Few links only please. Ohconfucius (talk) 23:25, 29 March 2009 (UTC)[reply]
  3. Once again only link to the year if it is very relevant to the topic. Links to YYYY in music/film etc. are okay, but even some of those are linked to too much. Rambo's Revenge (How am I doing?) 23:25, 29 March 2009 (UTC)[reply]
  4. Per WP:OVERLINK. --John (talk) 23:37, 29 March 2009 (UTC)[reply]
  5. Absolutely. Even when a date is notable in its own right, e.g. 1492, it may be irrelevant to the passage in which it occurs. --Philcha (talk) 23:51, 29 March 2009 (UTC)[reply]
  6. Support: We are overlinking enough as is. seicer | talk | contribs 23:58, 29 March 2009 (UTC)[reply]
  7. Support. I hope this provision will be construed fairly narrowly. -- Donald Albury 23:59, 29 March 2009 (UTC)[reply]
  8. Support, the value of these links are way overstated. Year articles are still (mostly) lists of trivia; please note that I am not necessarily saying that these articles are bad, just that they will not help readers of other articles in their current format. Dabomb87 (talk) 00:01, 30 March 2009 (UTC)[reply]
  9. Support, only link the year if it's relevant to the article. Again, common sense and the best way to prevent overlinking, in my opinion. Raven1977Talk to meMy edits 00:09, 30 March 2009 (UTC)[reply]
  10. Support. Exactly the same effect as option 4, except there is a chance of less fighting. --Hans Adler (talk) 00:11, 30 March 2009 (UTC) Just to make sure that nobody reads this as option 4 being my 2nd choice. It is not. It's actually the worst option because it doesn't settle the question. --Hans Adler (talk) 10:22, 31 March 2009 (UTC)[reply]
  11. Support - Date links, like all others, should enhance a reader's understanding of the topic. This can be decided on a case-by-case basis. Awadewit (talk) 00:13, 30 March 2009 (UTC)[reply]
  12. Support. When did you last require "easy access to year articles"? I never have. Year articles are breathtakingly useless. And the day—impatiently awaited—that I do want access to one of them, the search box gives quite easy enough access for my needs. Moreover, the famous "metadata" isn't the same as "useful metadata". Bishonen | talk 00:23, 30 March 2009 (UTC).[reply]
  13. Support This pretty much covers the rare circumstances when years should be linked. The proposed wording says it all: years “should not be linked unless they contain information that is germane and topical to the subject matter”. Enough said. Greg L (talk) 00:36, 30 March 2009 (UTC)[reply]
  14. Support as per Greg L.—MDCollins (talk) 00:45, 30 March 2009 (UTC)[reply]
  15. Support (Ditto my date linking reason.) I would tend to support the remove guidance option, but I suspect that past tendencies to link all dates would lead to continued overlinking. Guidance is needed to limit date links to those of notable historical significance. -- Tcncv (talk) 00:48, 30 March 2009 (UTC)[reply]
  16. Per Steve, Bishonen, and Greg. NuclearWarfare (Talk) 00:49, 30 March 2009 (UTC)[reply]
  17. Support The additional guidance would help avoid overlinking years. Eubulides (talk) 01:38, 30 March 2009 (UTC)[reply]
  18. Support as this is the closest to my preferred position of link no dates at all. Ealdgyth - Talk 01:49, 30 March 2009 (UTC)[reply]
  19. Support: among the options, this is likely the one to cut down the "sea of blue" best. Jappalang (talk) 01:59, 30 March 2009 (UTC)[reply]
  20. Per Steve Crossin. –Juliancolton | Talk 02:16, 30 March 2009 (UTC)[reply]
  21. Support: Of all the options available, I support this one. I tire of seeing fields of blue date links that take me to places that are not germane to the topics I'm reading.SteveB67 (talk) 02:19, 30 March 2009 (UTC)[reply]
  22. Support.-gadfium 03:24, 30 March 2009 (UTC)[reply]
  23. Support: Year articles are almost entirely a bunch of coincidental happenings. I cannot find one year article that would provide the deeper understanding of a topic that you'd want it to (see Bishonen, above). The sea of blue looks seriously unprofessional in an article, dilutes the good links, and clutters the text. The "See also" section at the bottom is a better place if an editor feels an unbridled urge to link to one or two years, but I'd still want to see the justification—not just so people can indulge in discretionary browsing (I think we kid ourselves that readers hit such links, anyway). Tony (talk) 03:59, 30 March 2009 (UTC)[reply]
  24. Support I find year links unnecessary and dislike the extra blue. bridies (talk) 04:43, 30 March 2009 (UTC)[reply]
  25. Support. I strongly oppose the presumption in #2, that links to year articles (which contain mostly trivia) are somehow more relevant in the case of birth and death dates. If anything, they are less relevant. Random events occurring in some year are almost never relevant to the life of someone born in that year, for example.--Srleffler (talk) 05:00, 30 March 2009 (UTC)[reply]
  26. SupportChris! ct 05:03, 30 March 2009 (UTC)[reply]
  27. Support. links should be made when the articles they lead to are relevant. on the rare occasions when a year page might add some useful context, the "see also" section is the perfect place for it. i would also support renaming most year articles to something like "List of Events in [Year]". Sssoul (talk) 05:13, 30 March 2009 (UTC)[reply]
  28. Support, as with the date links. (Note that in a perfect world I would side with Pmanderson and vote for complete removal, but apparently some people need to be told more explicitly.) Fut.Perf. ☼ 06:04, 30 March 2009 (UTC)[reply]
  29. Actually, I most support Option 4 (just as in the month/day section, so skip the rest if you know where this is going) - no guidance means nothing to edit war over, and the practical result would be identical to this guideline. Since the poll format ostensibly won't allow supporting multiple options (Why? Seriously, why?) I support this one on the basis already stated - it is identical to option 4 in practice, and more likely to be supported by others in practice. However, your poll format is broken in any case. Gavia immer (talk) 06:17, 30 March 2009 (UTC)[reply]
  30. Support There has to be an excellent reason to link to a year. These will be rare. Dougweller (talk) 08:14, 30 March 2009 (UTC)[reply]
  31. Support. This is the only option that explicitly states that each date link must be relevant. No more, no less. That is the same with non-date links but after a long period of overlinking, editors need explicit guidance. Lightmouse (talk) 08:28, 30 March 2009 (UTC)[reply]
  32. Support Why link to irrelevant years like birth years, unless they are relevant? So, only link to years if they are relevant. I was puzzled why I linked to years when I joined the project three years ago. It was and is a waste of time and adds nothing to articles.--HJensen, talk 09:13, 30 March 2009 (UTC)[reply]
  33. Support with caveat that years are seldom "relevant" per se. Bongomatic 09:14, 30 March 2009 (UTC)[reply]
  34. Support. I need say no more, as before. This, that and the other [talk] 09:29, 30 March 2009 (UTC)\[reply]
  35. Support. Years that aren't relevant don't need to be linked, which is most of them. Extremepro (talk) 09:30, 30 March 2009 (UTC)[reply]
  36. Support There are many films set in a historical year which are worth linking to, otherwise I see date linking as unnecessary. Alientraveller (talk) 09:51, 30 March 2009 (UTC)[reply]
  37. Support; useful if the year has some pertinence, not useful if the year has no relation. Good discretion is needed here. —Anonymous DissidentTalk 10:09, 30 March 2009 (UTC)[reply]
  38. Support. Links should always be judged based on relevancy and value to the reader. — TKD::{talk} 11:11, 30 March 2009 (UTC)[reply]
  39. Support. If I understand correctly, then this is what we do now. I see no reason to change. Adding unhelpful links to articles harms Wikipedia, since readers are misled as to where they might find additional relevant information.--Kotniski (talk) 11:26, 30 March 2009 (UTC)[reply]
  40. Support. I was going to write something witty, but Bishonen encapsulated it much better than I could have (or is it would have?) Casliber (talk · contribs) 11:32, 30 March 2009 (UTC)[reply]
  41. Support Option 2 was also tempting, but Arther Rubin's comment down in the Comments section (that it's too open to interpretation) is a good point, and also there is the problem that it would add yet another detail to scare newbies. So I can't support Option 2 unless it is clarified (for example, to link only the year in the first sentence of the article, where it says when X person was born or X book was written), and even then I might still not support it. Option 1, on the other hand, can effectively allow the same kind of linking and delinking as Option 2, and is an easier "rule of thumb" to remember. rʨanaɢ talk/contribs 13:21, 30 March 2009 (UTC)[reply]
  42. Support The most reasonable proposal. Articles shouldn't be overlinked with trivial links. - Darwinek (talk) 13:24, 30 March 2009 (UTC)[reply]
  43. Support - This seems to be the best option. Camw (talk) 13:40, 30 March 2009 (UTC)[reply]
  44. Support - this is what I've gotten used to in the past months, and it works just like any other links. This is equivalent to #4, but special guidance is necessary because of the history here. --NE2 13:42, 30 March 2009 (UTC)[reply]
  45. Support, just like with month-day linking. — Emil J. 13:44, 30 March 2009 (UTC)[reply]
  46. Support because it's the best choice, but year links are almost never relevant. SandyGeorgia (Talk) 13:45, 30 March 2009 (UTC)[reply]
  47. Support Here, however, there are likely to be relevant articles that should have significant prose and could be linked via piped links (e.g. XXXX in European politics, YYYY in Asian art - where XXXX and YYYY might be years, decades, or centuries depending on the topic and time). Such links are generally more likely to be relevant than the useless year lists we currently have. It would be fine if the guidance suggested such piped context links as more likely to be of use to the reader. GRBerry 14:08, 30 March 2009 (UTC)[reply]
  48. Support as per my response to the month-day poll - Dumelow (talk) 14:19, 30 March 2009 (UTC)[reply]
  49. Strong support per month-day poll Cnilep (talk) 14:37, 30 March 2009 (UTC)[reply]
  50. Support that years only be linked when absolutely relevant, primarily in chronological articles. I oppose the other options. Karanacs (talk) 15:30, 30 March 2009 (UTC)[reply]
  51. Support per Bishonen. But again, I want this to be a bit stronger - the year articles are almost always irrelevant to the subject at hand and should almost never be linked to. If you want to reference an event that happened in a specific year, surely it's far more logical to link the event. Pfainuk talk 15:44, 30 March 2009 (UTC)[reply]
  52. Perhaps in the future formal guidance on this issue can be removed. Since it's been a back and forth issue for a while, we need it for now, I think. --TreyGeek (talk) 15:49, 30 March 2009 (UTC)[reply]
  53. Support Basically the same as above. Alan16 talk 15:54, 30 March 2009 (UTC)[reply]
  54. Strong support based on most of the above. Johnny Au (talk/contributions) 15:58, 30 March 2009 (UTC)[reply]
  55. Support Makes the most sense, although I personally see no point in links to year except in date articles. I think the piped links are a good idea and should not be discouraged, and discouraging direct year links will make them more visible. Orderinchaos 16:04, 30 March 2009 (UTC)[reply]
  56. Suport What SandyGeorgia said. --Dweller (talk) 16:05, 30 March 2009 (UTC)[reply]
  57. Support, partly for use in "what links here". I rate the options: 1,2,4,3. Let's get rid of the useless links to lists of irrelevant trivia, though option 2 is also tempting and I would happily accept it too. Certes (talk) 16:10, 30 March 2009 (UTC)[reply]
  58. Support - Gran2 16:15, 30 March 2009 (UTC)[reply]
  59. Support, there is no need to needlessly overlink articles. Plastikspork (talk) 16:25, 30 March 2009 (UTC)[reply]
  60. Support. Rettetast (talk) 16:28, 30 March 2009 (UTC)[reply]
  61. Support. Personal logic prevails. I'm certain that there should be some guidance, but wonder how time consuming it could end up being... Greggers (t • c) 16:31, 30 March 2009 (UTC)[reply]
  62. Support. Whatever we can do to minimize the unnecessary overlinking of years. --Skeezix1000 (talk) 16:34, 30 March 2009 (UTC)[reply]
  63. Support. This is concurrent with the general guideline to make onlyrelevant links. Debresser (talk) 16:56, 30 March 2009 (UTC)[reply]
  64. Support. We have to veer toward quality links for our reader's benefit. This is a good step. -- Banjeboi 16:59, 30 March 2009 (UTC)[reply]
  65. Support. It is important to distinguish between a year being relevant to an article and the year-article being relevant. Often the first is true; very rarely the latter. Clear guidance is essential to avoid future disputes. When year-articles reach the quality of 1345, 1346 and 1347, then links to them will likely be relevant. This option will remove the current state of overlinking, without prejudicing relevant links when year-articles are improved. --RexxS (talk) 17:14, 30 March 2009 (UTC)[reply]
  66. When we link to articles whose content is not relevant to the context, we do our readers a disservice by distracting them from links to relevant articles. In the absolute majority of cases, year links are irrelevant to the context of the article from which they are being linked. –Black Falcon (Talk) 17:19, 30 March 2009 (UTC)[reply]
  67. Support Again, all links should have semantic value. OrangeDog (talk • edits) 17:28, 30 March 2009 (UTC)[reply]
  68. Makes sense to me--Scott Mac (Doc) 17:32, 30 March 2009 (UTC)[reply]
  69. Support All of the disadvantages to the other options resonate strongly with me. WhatamIdoing (talk) 17:37, 30 March 2009 (UTC)[reply]
  70. Support As per month-day links. RupertMillard (Talk) 17:39, 30 March 2009 (UTC)[reply]
  71. Support. As above: This should be the "common sense" option as I don't see any reason for it to be otherwise. Dates should be linked under the same rules as anything else - if relevant. |→ Spaully† 18:20, 30 March 2009 (GMT)
  72. Pro --Morten (talk) 18:27, 30 March 2009 (UTC)[reply]
  73. Support per SandyGeorgia. --Philosopher Let us reason together. 18:29, 30 March 2009 (UTC)[reply]
  74. Support: Really can't see the point in linking them. Others supporting in this section have said it much better! Maedin\talk 18:39, 30 March 2009 (UTC)[reply]
  75. Support. I don't value linking the years...I never use them myself so it scores as code-cruft to me.
    ⋙–Berean–Hunter—► ((⊕)) 19:08, 30 March 2009 (UTC)[reply]
  76. Support this option, seems the best of those presented. Mjroots (talk) 19:15, 30 March 2009 (UTC)[reply]
  77. Support. As with date linking, it's only useful occasionally. Mr Stephen (talk) 19:56, 30 March 2009 (UTC)[reply]
  78. Support Most logical. KellenT 20:20, 30 March 2009 (UTC)[reply]
  79. Support It is the most logical and most practical option. ~EdGl ★ 20:59, 30 March 2009 (UTC)[reply]
  80. Support. Same as the dates; years can occasionally be relevant, but very rarely and therefore much be linked to with caution. – Joe N 21:36, 30 March 2009 (UTC)[reply]
  81. Support per Hans Adler. —Josiah Rowe (talk • contribs) 21:50, 30 March 2009 (UTC)[reply]
  82. Support This is the only option that makes any sense and avoids linking to articles that are irrelevant to the first article. - Ahunt (talk) 22:10, 30 March 2009 (UTC)[reply]
  83. Support. Linked years are typically even less relevant that linked month+days. RossPatterson (talk) 22:15, 30 March 2009 (UTC)[reply]
  84. Support. As with the month-day linking poll, option 1 is the best option by a distance. Useful rarely, overused massively. Julianhall (talk) 22:27, 30 March 2009 (UTC)[reply]
  85. Support faithless (speak) 22:55, 30 March 2009 (UTC)[reply]
  86. Support - I see no point in having these links, and like I said above, I haven't missed them in cases where they have been removed. Giants2008 (17-14) 00:25, 31 March 2009 (UTC)[reply]
  87. Support, agree this is the best option and brings year linking into compliance with general linking guidelines - if its relevant, fine, but just linking Year in films, year in Sports, year itself, etc is not. -- Collectonian (talk · contribs) 02:00, 31 March 2009 (UTC)[reply]
  88. Support. The bright blue is a visual distraction and it's only relevant to numerologists. VikSol 02:42, 31 March 2009 (UTC)[reply]
  89. Support, Option 1 not only means that date links will be treated like other links, but there will also be a guideline to put an end to revert wars. We need a guideline because linking has already been done and de-linking means a change: imagine if the word imagine had been linked every time, then suddenly it wasn't. A guideline will prevent any short term confusion. Sillyfolkboy (talk) 02:47, 31 March 2009 (UTC)[reply]
  90. support and also support mass delinking of all such dates to get to where we should be: few links Hmains (talk) 03:08, 31 March 2009 (UTC)[reply]
  91. Support. Most years are highly overlinked and irrelevant to article content. RainbowOfLight Talk 03:28, 31 March 2009 (UTC)[reply]
  92. First choice. shoy (reactions) 03:36, 31 March 2009 (UTC)[reply]
  93. Support. Best choice to limit over-linking and improve the readability of articles and the utility of links is to treat years just like any other word- only link if it's a related or useful topic. --Clay Collier (talk) 05:08, 31 March 2009 (UTC)[reply]
    Support the first choice. Years and dates are like any other links, they should only be linked if relevant. Better yet, link the thing that makes linking the date relevant, and leave the date as an unlinked event. SDY (talk) 05:26, 31 March 2009 (UTC)[reply]
  94. The year in which a person is born is seldom relevant. A wp:mos should point that out. Support this option or No. 4. Yours, GeorgeLouis (talk) 05:55, 31 March 2009 (UTC)[reply]
  95. Support. Again, another thing that has always puzzled me since I joined Wikipedia. Links should always be relevant. If you have any questions, please contact me at my talk page. Ian Manka 06:23, 31 March 2009 (UTC)[reply]
  96. Support but that does not mean no autoformatting. Especially for negative years (before year 0). If we want more cool tools exposing Wikipedia data in interesting ways, we must write years in a very explicit way. Nicolas1981 (talk) 06:36, 31 March 2009 (UTC)[reply]
  97. Support: only articles with relevant information should be linked to, otherwise why link? Other uses are trivia. NJGW (talk) 07:48, 31 March 2009 (UTC)[reply]
  98. Support: I was leaning towards option 2, but in reality, I don't see the benefit of finding out more about a year someone was born. -- WORMMЯOW  08:21, 31 March 2009 (UTC)[reply]
  99. Support Again, this seems the best option to reduce unnecessary blue links. --JD554 (talk) 11:43, 31 March 2009 (UTC)[reply]
  100. As with month/day, above.  Sandstein  11:50, 31 March 2009 (UTC)[reply]
  101. Support but option 1 doesn't give a good example of a reason to link to a general year article like 1795. Colin°Talk 12:48, 31 March 2009 (UTC)[reply]
  102. Support. I would also suggest to avoid linking to articles like 1964 in sports because they are rater useless. Timeline of World War II (1942) is fine. --Apoc2400 (talk) 15:12, 31 March 2009 (UTC)[reply]
  103. Support. Bubba73 (talk), 15:55, 31 March 2009 (UTC)[reply]
  104. Support. Best of the options. --Jc3s5h (talk) 16:38, 31 March 2009 (UTC)[reply]
  105. Support, but the outlook on what would be a meaningful link to a year should be rather tight. Gwen Gale (talk) 16:47, 31 March 2009 (UTC)[reply]
  106. Support, as above. noq (talk) 17:07, 31 March 2009 (UTC)[reply]
  107. Support There is no point in irrelevant links. That they might be "interesting" is not the point (and is also a rather unlikely outcome anyway: have you tried reading those articles?). Richard75 (talk) 17:26, 31 March 2009 (UTC)[reply]
  108. Support. Only link if the year is directly relevant to the article. Less is more when it comes to links. The more links, the less impact each link has. SlimVirgin talk|contribs 17:36, 31 March 2009 (UTC)[reply]
  109. Support As most logical. Option 4 doesn't seem to preclude the re-creation of mosdate guidelines after they are removed. All options except 1 will lead to an overly high link density in too many situations. -- Quiddity (talk) 18:05, 31 March 2009 (UTC)[reply]
  110. Support so once more we stick with linking relevant links only and not inundating our readers with a bunch of unrelated links. The Rambling Man (talk) 18:14, 31 March 2009 (UTC)[reply]
  111. Support. I think the date policy at WP:OVERLINK justifies itself. Daniel J Simanek (talk) 18:46, 31 March 2009 (UTC)[reply]
  112. Support - It's all about context. 99% of an article about a year has no relevance to the subject of another article that contains that year. With regard to the "Background" statement, piped links should always be contextual. "Year in whatever" links almost always belong in a "See also" section. --IllaZilla (talk) 19:14, 31 March 2009 (UTC)[reply]
  113. Support: only when directly relevant, to reduce the burden on readers. CRGreathouse (t | c) 20:00, 31 March 2009 (UTC)[reply]
  114. Support, second choice. Option #2 is my first choice. – Quadell (talk) 20:04, 31 March 2009 (UTC)[reply]
  115. Support. Context-irrelevant links are worth avoiding, and there is no reason to make an exception for dates. ~ mazca t|c 20:50, 31 March 2009 (UTC)[reply]
  116. Support, just adds visual clutter and very low-value links. Ground Zero | t 23:40, 31 March 2009 (UTC).[reply]
  117. Support - it settles the issue by setting a policy. The policy doesn't need to be rigidly enforced and awareness of it doesn't need to be high. Hawthorn (talk) 23:55, 31 March 2009 (UTC) clarification: Would prefer no date linking at all. Hawthorn (talk) 09:53, 2 April 2009 (UTC)[reply]
  118. Support the only sensible option provided, link the date to a relevant listing that connects to the article's content. FWiW Bzuk (talk) 01:00, 1 April 2009 (UTC).[reply]
  119. Support - Relevence good - Irrelevence bad. --Kbh3rdtalk 01:29, 1 April 2009 (UTC)[reply]
  120. Support per summary. don't see the need for linking birth / death years, already linked to year of birth and death categories and onwards, and several million links to years does nothing really worthwhile.--ClubOranjeT 01:54, 1 April 2009 (UTC)[reply]
  121. Support. Most years do not need linking. Only a few add anything to the article by having a link. --Bduke (Discussion) 02:38, 1 April 2009 (UTC)[reply]
  122. Support as the most logical option. Again to avoid edit wars, guidance should be to only use if you can make a strong case for adding the link. Vegaswikian (talk) 03:57, 1 April 2009 (UTC)[reply]
  123. Again, not sure when a year link would help a reader. –thedemonhog talk • edits 06:53, 1 April 2009 (UTC)[reply]
  124. Support. Ruslik (talk) 07:23, 1 April 2009 (UTC)[reply]
  125. Support. The most relevant option. --Popiloll (talk) 07:24, 1 April 2009 (UTC)[reply]
  126. Support—As with day-month links, year links should be treated like any other potential link. However, we're not ready for option 4 yet. Explicit guidance not to overlink will be a helpful maybe even essential part of reversing the damage done so far. JIMp talk·cont 08:44, 1 April 2009 (UTC)[reply]
  127. Support. SilkTork *YES! 11:15, 1 April 2009 (UTC)[reply]
  128. Support Too many year links are annoying, and they're usually worthless. CheesyBiscuit (talk) 12:50, 1 April 2009 (UTC)[reply]
  129. Support This is the best option, we don't need to overlink VJ (talk) 13:03, 1 April 2009 (UTC)[reply]
  130. Support. Same arguments as for day-month linking. Matt 13:09, 1 April 2009 (UTC).
  131. Support Virtually none of out year articles are worth linking to, and we need specific guidance to roll back the existing overlinking. Any metadata these links provide is so vague as to be worthless. It's not helpful to anyone to know that some unspecified event, related to the subject of the article in some unknown way happened in that year. Colonies Chris (talk) 13:13, 1 April 2009 (UTC)[reply]
  132. Support Year links are over-links. --Phil Holmes (talk) 15:17, 1 April 2009 (UTC)[reply]
  133. Support - I was born in 1985; but I don't think I deserve having my birthday listed in 1985. However, noting Kristallnacht in the 1938 article would help show a timeline of what was happening around that time. Fightin' Phillie (talk) 18:05, 1 April 2009 (UTC)[reply]
  134. Support. Link years only for very exceptional reasons. Every link must be revelant to the article, something like "read more about that subject", not confusing, not irrelevant. Birth/death dates should not be linked, this is overlinking. The same reasoning I would follow for common terms such as "municipality", "astronomer", "German", etc. -- Magioladitis (talk) 19:44, 1 April 2009 (UTC)[reply]
  135. Support - Per WP:OVERLINK. EdJohnston (talk) 19:51, 1 April 2009 (UTC)[reply]
  136. Support. Relevant year links only. Powers T 23:44, 1 April 2009 (UTC)[reply]
  137. Support - as per day-month linking. hamiltonstone (talk) 00:51, 2 April 2009 (UTC)[reply]
  138. Support Pointless links dilute the value of useful links and are distracting. Johnuniq (talk) 02:59, 2 April 2009 (UTC)[reply]
  139. Support In nearly all cases, date links are irrelevant and distracting. Exceptions can be made for the few that aren't. Rivertorch (talk) 05:35, 2 April 2009 (UTC)[reply]
  140. Support Again per Rivertorch, who appears to be reading my mind.--Aervanath (talk) 05:39, 2 April 2009 (UTC)[reply]
  141. Support. I've never followed a year link and found anything of relevance or interest, so they are a waste of time to put in, and dilute hight value links. A few relevant year may benefit from linking, but rarely.YobMod 09:06, 2 April 2009 (UTC)[reply]
  142. Support The sea of blue which can be found in some articles is worsened by having irrelevant date links. Only relevant links are useful, and as such only these should be highlighted in blue. See WP:OVERLINK -m-i-k-e-y-talk 11:05, 2 April 2009 (UTC)[reply]
  143. Support. Year links should be done at most to year articles on specific subjects. −Woodstone (talk) 11:34, 2 April 2009 (UTC)[reply]
  144. Support, pretty much for the same reasons as supporting Option #1 on month/day links. --R'n'B (call me Russ) 13:33, 2 April 2009 (UTC)[reply]
  145. Support too many articles linked to a specific year, and that makes "what links here" link useless --NullSpace (talk) 15:12, 2 April 2009 (UTC)[reply]
  146. Support, per WP:OVERLINK: "...avoid cluttering the page with obvious, redundant and useless links.". --Rosiestep (talk) 17:51, 2 April 2009 (UTC)[reply]
  147. Support, since there was no option for "Never link a year". "World War II (1942)" or "US films of 1942" are linkable. "1942" is hardly ever. --Alvestrand (talk) 18:49, 2 April 2009 (UTC)[reply]
  148. Support. Seems the most reasonable option: Don't link years that are just factual timeline markers, which is by far the most common. Optionally link years if the year article provides relevant context. Esobocinski (talk) 20:04, 2 April 2009 (UTC)[reply]
  149. Support. Link years only when necessary for context or usefulness, as we do for everything else. I really wonder why this was controversial all these years. Steve T • C 22:08, 2 April 2009 (UTC)[reply]
  150. Support – While some editors might interpret this rule more loosely than others (such as using various "rationals" to support the linking of all years in an article), a formatting change is needed to reduce link density and irrelevance. In addition, piped year links, such as [[2008 in film|2008]], are useful to readers. momoricks (make my day) 01:21, 3 April 2009 (UTC)[reply]
  151. Support - As per Months and Days. Relevance isn't a difficult thing to determine with years. Australian Matt (talk) 02:13, 3 April 2009 (UTC)[reply]
  152. Support - All links must be relevant for users. Cacycle (talk) 02:34, 3 April 2009 (UTC)[reply]
  153. Support - relevant links can prevent overlinking. MathCool10 Sign here! 04:39, 3 April 2009 (UTC)[reply]
  154. Support. Guidelines should strongly encourage links such as 1924 in Science in the see also sections as an alternative however.Headbomb {ταλκκοντριβς – WP Physics} 06:57, 3 April 2009 (UTC)[reply]
  155. Support. As for the month-day linking. Mike Christie (talk) 11:05, 3 April 2009 (UTC)[reply]
  156. Support. Obvious choice as it follows standard policy against overlinking. The Birth/Death option is a strawman as we already have categories for these. -- KelleyCook (talk) 15:56, 3 April 2009 (UTC)[reply]
  157. Support Best option available, as linking to random years that happen to be mentioned in the article is pointless. Link density would be far too high if more than the obivously relevant years were linked.
  158. Support. Similar to my support for option #1 in the month-day linking poll. --seav (talk) 16:54, 3 April 2009 (UTC)[reply]
  159. Support — Malik Shabazz (talk · contribs) 19:47, 3 April 2009 (UTC)[reply]
  160. Support I never understood why there were links to those articles. Deegee375 (talk) 21:17, 3 April 2009 (UTC)[reply]
  161. Support Remove unnecessary, unhelpful, links - almost always there is no point in linking to the year. PamD (talk) 10:18, 4 April 2009 (UTC)[reply]
  162. Support Personally, I don't see the need to link to any year, but I suppose this is the best option, of one must chose one of them. Giano (talk) 11:40, 4 April 2009 (UTC)[reply]
  163. .Support Best option. Will prevent needless wikilinking.Mosedschurte (talk) 11:45, 4 April 2009 (UTC)[reply]
  164. Support Again, as with month-day linking, this seems the best way to go, and (I believe) in-line with existing wikilink guidelines. ~~ [ジャム][t - c] 14:19, 4 April 2009 (UTC)[reply]
  165. Support Best option of the four. --Patar knight - chat/contributions 18:35, 4 April 2009 (UTC)[reply]
  166. Support Like anything else, link only if relevant, which they rarely are. Struway2 (talk) 20:03, 4 April 2009 (UTC)[reply]
  167. Support Almost all date links are, as stated frequently above, actively useless. To be discouraged unless serving some function. Igenlode (talk) 02:21, 5 April 2009 (UTC)[reply]
  168. Support, as least worst option, most year links are unnecessary. There may be occasional uses for it which I have not as yet encountered. The main potential use is already covered by cateorys such as 1937 births, etc. Jezhotwells (talk) 12:22, 5 April 2009 (UTC)[reply]
  169. Support. Best of the worst option. — Σxplicit 19:07, 5 April 2009 (UTC)[reply]
  170. Support. Most fitting option I believe. Nja247 21:09, 5 April 2009 (UTC)[reply]
  171. Support - Better option. --  ThinkBlue  (Hit BLUE) 22:53, 5 April 2009 (UTC)[reply]
  172. Support As per month linking relevancy. Hohohob (talk) 01:19, 6 April 2009 (UTC)[reply]
  173. Support I see no need for any bare date links. Ever.--2008Olympianchitchat 05:03, 6 April 2009 (UTC)[reply]
  174. Support Link where truly relevant, not otherwise. Richard New Forest (talk) 15:01, 6 April 2009 (UTC)[reply]
  175. Support, although I do wish dates were not linked whatsoever. Corn.u.co.piaDisc.us.sion 16:00, 6 April 2009 (UTC)[reply]
  176. Support - little benefit of linking to these lists with only trivial common connection. If an event is topically linked to others (no matter what year), perform the courtesy of linking directly to it - it's neither useful nor helpful to leave your readers scrabbling through a trivia list of events that happened in an almost arbitrary 365.25 day band around it. Knepflerle (talk) 16:51, 6 April 2009 (UTC)[reply]
  177. Support this option provides guidance on when to link, guidance that will help avoid overlinking, and such guidance will help minimize style dispute. —Danorton (talk) 18:20, 6 April 2009 (UTC)[reply]
  178. Support appropriate guidance. years are rarely useful, so generally should not be linked. occasionally they can be helpful (e.g. linking 1970s in the article western cosmetics in the 1970s, so readers can see other cultural changes of the era). because there is a particular problem with overlinking years (a relic of autoformatting of yore) it makes sense to add a guideline specific to years. Calliopejen1 (talk) 18:29, 6 April 2009 (UTC)[reply]
  179. Support A guideline encouraging sensible discussion will be more likely to lead to sensible editorial choices. Peter Isotalo 19:06, 6 April 2009 (UTC)[reply]
  180. Support Of lack of an option that simply eliminates all possible date linking, this will provide the least blue. Date and year links have no function and reduce readability significantly. Arsenikk (talk) 19:14, 6 April 2009 (UTC)[reply]
  181. Support seems to be the standard of wikipedia to include what is noteworthy, and this would follow that recomendation.--Mrboire (talk) 20:06, 6 April 2009 (UTC)[reply]
  182. Support — Coherent, consistent, common-sense link policy calls for treating years the same as we treat any other potentially linkable word, phrase, or number: we link them only if they are really relevant to the article at hand. We don't link words just on speculation that the reader might happen to find the link target interesting, or because we happen to be using a linkable word as part of the article text. —Scheinwerfermann T·C00:44, 7 April 2009 (UTC)[reply]
  183. Support As has been repeated many, many times by myself and others, every link should be included if relevant and not if not. Date links are no exception.
  184. Support. For the same reason as I gave for other date links: It is unconscionable to adopt a policy by which supplying irrelevant links is the default. Most occurrences of dates, in most contexts, are simple markers on a timeline; they are not gateways to any sort of rich and relevant background. In most cases, therefore, a link would make a false promise, and distract from the force and immediacy of the text. I grant that the year will sometimes be relevant – more often than a month or a precise day. In such a case, linking may be a good option. Simple!–¡ɐɔıʇǝoNoetica!T– 07:45, 7 April 2009 (UTC)[reply]
  185. Wowza, this option has landslide support. Looks like the community is finally coming to a consensus on this issue. --Cyde Weys 15:41, 7 April 2009 (UTC)[reply]
  186. Support, easily, creating links to every single year is kinda useless. As Wikipedia:Overlinking says. Xenus (talk) 16:16, 7 April 2009 (UTC)[reply]
  187. Support - links to years are generally unhelpful, and this option would remove most of them. Robofish (talk) 00:01, 8 April 2009 (UTC)[reply]
  188. Support There's generally little need to link to years and it shouldn't be encouraged, but there are circumstances where its appropriate. Nick-D (talk) 11:21, 8 April 2009 (UTC)[reply]
  189. Support No need to link every year, but some links would be useful. -- MightyWarrior (talk) 11:42, 8 April 2009 (UTC)[reply]
  190. Support best option --Armchair info guy (talk) 14:58, 8 April 2009 (UTC)[reply]
  191. Support matches my support in the daymonth; anything different for years would be confusing. --GedUK  20:14, 8 April 2009 (UTC)[reply]
  192. Support: Option 2 is too vague, and will lead to load of overlinking and fights about overlinking. Option 3 makes no sense at all (for the same reason that we don't link the first occurrence of everyday words like woman and food except in unusual contexts). Option 4 is pointless, as MOS exists for a reason, and inevitable date-related disputes will automatically re-engender MOS debate and eventual guidance on the matter. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:02, 9 April 2009 (UTC)[reply]
  193. Support. I can't think of many occasions where years need to be linked, but the option should be available if doing so will improve a reader's understanding of an article. EyeSerenetalk 09:59, 9 April 2009 (UTC)[reply]
  194. Support Links are visually distracting. Irrelevant links reduce readability. Cstaffa (talk) 00:01, 10 April 2009 (UTC)[reply]
  195. Support - definitely the best option of them all. Link relevant ones, as that actually adds to the article; don't link the others. --Alinnisawest,Dalek Empress (extermination requests here) 03:07, 10 April 2009 (UTC)[reply]
  196. Weak support. I would prefer not linking years at all, just like we never link weekdays (I hope). "Relevant years" seems POV-loaded to me and could lead to edit wars. But this is the least worst option of the 4. – IbLeo (talk) 05:32, 10 April 2009 (UTC)[reply]
  197. Support for piping I support this guidance for unpiped years. Lots of things happen in a year, and most have no relation to each other, and the year should not be linked from such articles. However, if a year is properly piped to define related contexts, I believe that this is an acceptable compromise. 2000 is a useless trivia page, but 2000 in film can be meaningful (for example, if one is researching year-over-year trends in film). Ham Pastrami (talk) 06:25, 10 April 2009 (UTC)[reply]
  198. Support Ditto what I said for month-day linking: Put an end to this silly overlinking.EEng (talk) 19:31, 10 April 2009 (UTC)[reply]
  199. Strong support Linking the year a film was released or a book was published or a song was written makes sense, since it leads to articles about similar accomplishments within the same year. But why link birth and death dates? How often does someone read a biographical article and feel the need to see who else was born or what else happened in that year? 209.247.22.164 (talk) 13:51, 11 April 2009 (UTC)[reply]
  200. Support  Just like a date or any other term in an article, link if appropriate, and according to the editors' judgment. Michael Z. 2009-04-11 16:20 z
  201. Support, remembering that the year article is almost never relevant.--Fabrictramp | talk to me 23:21, 11 April 2009 (UTC)[reply]
  202. Support - Like with month linking links should only be provided if they have some relevance to the topic at hand; removing all guidance would again be unhelpful and cause future conflicts. I don't see birth/death linking as particularly necessary. Camaron | Chris (talk) 14:08, 12 April 2009 (UTC)[reply]
  203. Support -- "relevance" is a bit vague, but I guess it has to be. I do a lot of linking to the years-in-poetry articles, especially from bibliography sections of poet articles and list-of-[nationality]-poets articles, but that seems to be allowed with this option. Year-in-music and Year-in-film links are clearly relevant to anyone considering the historical context of a work of art, which would be the only reason someone would click on the link anyway. Same for any year-in-topic link. -- Reconsideration (talk) 18:36, 12 April 2009 (UTC)[reply]
  204. Support - provides the best balance between overlinking and utter barrenness. However, projects could be allowed to refine the guidance on year-linking e.g. a sports project could advise when a 2003 in sports link is appropriate. Dl2000 (talk) 01:39, 13 April 2009 (UTC)[reply]
  205. Support, particularly with regard to links to 'year-in-subject' articles within articles about that subject, whether piped or not. Links should always be relevant, and dates should be no exception. In addition, if the resolution of the autoformatting question is that autoformatting is not desired by the community, or if autoformatting is desired and the eventual implementation of it does not rely on linked dates, links that were solely for the purpose of autoformatting will need to be removed. Two important points related to this, however. First, no links should be removed until the question of autoformatting is decided. Second, the most efficient method of removing these links is through automated and semi-automated methods. However, since it is impossible for bots and scripts to determine relevancy. a method must first be created to identify and protect links that are determined by editors to be relevant — this, for me, is the main issue related to the current arbitration. This is even more critical for year links than it is for month/day links. Mlaffs (talk) 12:26, 13 April 2009 (UTC)[reply]
  206. Perhaps special guidance will not be necessary in the future, but as long as we are accustomed to a precedent of treating year links differently from the rest, having identical guidelines for the two and expecting identical results will simply not do. This option about a simple relevance check is just the ticket. Waltham, The Duke of 13:55, 13 April 2009 (UTC)[reply]
  207. Support. As previously noted for month-day links, relevance is context-dependent and discretionary, but on balance, this proposal will likely result in a broadly acceptable result. TheFeds 16:35, 13 April 2009 (UTC)[reply]
  208. Support - Single years are ridiculously overlinked now. The one reader in 10,000 who wants to go to a particular year article can type 4 digits (or fewer) and hit the "Go" button. No sense in cluttering up every article just to save 4 keystrokes for these very few readers. Chris the speller (talk) 20:24, 13 April 2009 (UTC)[reply]
I support Option #2 (Option #1 plus birth/death years, etc)
  1. Again, this seems the best solution for readers of the article, with further discussion probably required to determine the exact circumstances where year links should be allowed and/or encouraged. I would rank the options 2,4,1,3. — Arthur Rubin (talk) 23:47, 29 March 2009 (UTC)[reply]
  2. Support. Years are much more often relevant than month, day articles and should generally be linked to provide chronological context where relevant. I would rank the options 2,4,1,3. Eluchil404 (talk) 00:09, 30 March 2009 (UTC)[reply]
    Support, birth years, death years should all be tied together in some way. dm (talk) 00:15, 30 March 2009 (UTC) Switched to option 4 dm (talk) 06:03, 31 March 2009 (UTC)[reply]
    Support. Say yes to global historical context. — Hex (❝?!❞) 08:30, 30 March 2009 (UTC) Changing to option 4; however, this is the only non-4 option that makes sense. — Hex (❝?!❞) 11:49, 31 March 2009 (UTC)[reply]
  3. Support. Like date links, years should not be linked to unless relevant. Unlike date links, however, there is some relevance to being able to quickly find out what else happened the year that someone was born or died. YLee (talk) 09:23, 30 March 2009 (UTC)[reply]
  4. Support I would like birth dates to be linked. Reywas92Talk 14:25, 30 March 2009 (UTC)[reply]
  5. Support. As a reader, I rather like having birth dates etc linked, and I know some who are fairly obsessed with it. Every "On this day ..." speaks to the popularity of this kind of link. — the Sidhekin (talk) 15:01, 30 March 2009 (UTC)[reply]
  6. Support. As a long-time fan of printed almanacs, I like this option best. — Bellhalla (talk) 15:09, 30 March 2009 (UTC)[reply]
  7. Support This has been the practice on Wikipedia before the controversial change to the MoS last summer; & as Bellhalla notes, these are of demonstrable interest to many of our users. (And, in the spirit of Eluchil404's note above, I would be inclined to vote with option #1 if it weren't for the fact I can't assume good faith that this is simply a way to eliminate year-linking completely by then arguing there are no relevant years which justify a link. So my first alternative to this would be #4 -- eliminate the section entirely.) -- llywrch (talk) 16:44, 30 March 2009 (UTC)[reply]
  8. Support davidwr/(talk)/(contribs)/(e-mail) 18:34, 30 March 2009 (UTC)[reply]
  9. Support per llywrch --Cybercobra (talk) 19:53, 30 March 2009 (UTC)[reply]
  10. Not too bothered really, but I think it is better when the days & months are linked.
  11. Support, But only for certain dates (like birth and death) I am going to be the apparent oddball here and say that I think that overlinking is bad but there is nothing wrong with linking the dates the first time, or maybe even twice if one is an infobox and 1 is in the article itself. We have to remember that WP is not a paper encyclopedia, it is a 4 dimensional online encylclopedia that allows pages to be "linked" to other pages. I alot of folks have argued that it adds little value to them, but if I am reading an article and want to look at the date why should I have to type it in to go see it. Also, if we are going to remove links to dates then should we also consider deleting the date articles themselves, we are going to get quite a few orphaned date articles of we remove all links.--Kumioko (talk) 20:20, 30 March 2009 (UTC)[reply]
  12. Support. I would be inclined to vote with option #1 but I suspect that would be too heavily weighted towards elimating all year-links. I don't think all births and deaths should be year-linked, but the etc would provide some help for the pro-link argument in specific cases. CS46 20:55, 30 March 2009 (UTC)[reply]
  13. I also support option 4. 1000% support of Gavia immer's comment above. AKAF (talk) 07:05, 30 March 2009 (UTC)[reply]
  14. Support with reservations: what I'd really prefer is #1 without the "don't link birth and death years" language. Gareth McCaughan (talk)
  15. Support: as another commenter said above, just say yes to global historical concept. -- The Anome (talk) 01:34, 31 March 2009 (UTC)[reply]
  16. Support: Birth and death years can be helpful for providing a quick historical context. — D. Wo. 06:50, 31 March 2009 (UTC)[reply]
  17. Support, by reference to the usual content of the years' own articles, which are heavy on b/d. David Brooks (talk) 17:48, 31 March 2009 (UTC)[reply]
  18. Support, first choice. #1 is second choice for me. – Quadell (talk) 20:03, 31 March 2009 (UTC)[reply]
  19. Support, birth/death years should be linked when historical context is relevant. — Xavier, 21:00, 31 March 2009 (UTC)[reply]
  20. Support - Again, seems the most sensible way to go about it, giving relevant links for readers to follow. Colds7ream (talk) 07:29, 1 April 2009 (UTC)[reply]
  21. Why is there not a duplicate of this option above in regards to month-day linking? neways, i support this because, again, it provides great level of depth to the non-paper encyclopedia. Addtionally, while the "you can use Search" arguement might work with search terms like March 2 (regional differences being ignored), if I wanted to find events that happened in the year 105 i would likely get a multitude of false positives i'd have to wade through. Again, not all years should be linked, but any that are extremely important in regards to the subject are potentially linkable. -- ΖαππερΝαππερ BabelAlexandria 08:35, 1 April 2009 (UTC)[reply]
  22. Support I would like WP:Popups or some other script to allow me to go to a year page for any year (which might be easier if there was the autoformatting meta data present), but in general excessive irrelevant visible links is bad. Mark Hurd (talk) 02:47, 2 April 2009 (UTC)[reply]
  23. Support Although a link to decade, era or similar might be better than the year article for birthyears. Taemyr (talk) 06:01, 2 April 2009 (UTC)[reply]
  24. Support Birth and death dates are relevant and really should be included in option 1 to begin with (especially when the people listed are already on the linked year page) - Mgm|(talk) 10:06, 2 April 2009 (UTC)[reply]
  25. Support Birth and death years certainly seem "relevant" in any case. Ed Fitzgerald t / c 13:04, 2 April 2009 (UTC)[reply]
  26. Support To me, birth/death years are relevant links. --ThaddeusB (talk) 16:29, 2 April 2009 (UTC)[reply]
  27. Support Birth/death years of people, organisations, etc are relevant links. -Arb. (talk) 22:05, 2 April 2009 (UTC)[reply]
  28. Support I would prefer that users have the option to see all dates linked, including years, via some improved version of the date autoformatting/autolinking software — but I think something like option 2 should be the default. I think date/birth years are always relevant to a person, so I don't actually distinguish between this option and option 1. --Sapphic (talk) 06:16, 3 April 2009 (UTC)[reply]
  29. Support - marginally (but just marginally) preferable to #1, which is also a good solution. Shimgray | talk | 15:34, 3 April 2009 (UTC)[reply]
  30. Support -- Birth and death years are relevant, and it will be handier once the date preference formatting is removed from the links. -- William Allen Simpson (talk) 14:30, 6 April 2009 (UTC)[reply]
  31. Support for reasons already stated. Deb (talk) 18:00, 6 April 2009 (UTC)[reply]
  32. Support for maximum usability. Also, I'll steal Sapphic's argument above. ~user:orngjce223 how am I typing? 20:17, 7 April 2009 (UTC)[reply]
  33. Support as I do believe this option is the same as option 1, as the type of events described are relevant.--4wajzkd02 (talk) 21:21, 7 April 2009 (UTC)[reply]
  34. Support - Broadly support. Although the meaning of 'events relevant to the subject' is open to interpretation, and will probably lead to more arguments. G-Man ?
  35. Support - first choice, choice 1 also acceptable. Birth and death years are relevent. Hipocrite (talk) 14:14, 8 April 2009 (UTC)[reply]
  36. Support. Again, the issue here is relevancy. However, here I have decided to go for option 2 instead. I disagree with the part in option 1 regarding birth and death years. The birth and death of someone or something, etc. can often be used as markers for an era of influence, and/or such. For example, knowing that Philip C. Johnson died in 2005 lets me know that, with the exception of post-humous works, there are no works by him after that year that he will be directly or personally involved with, since he's already passed-on, and that any works after that year will be, at most, influenced by him but not directly or personally worked by him. --A.K.R. (talk) 16:34, 9 April 2009 (UTC)[reply]
  37. Support Just as I said in the month section, I think that "relevant" should be defined liberally. Better to have too many links instead of too few. I also think birth and death years are always relevant. Captain panda 17:12, 11 April 2009 (UTC)[reply]
  38. The last sentence of option #1 makes it unacceptable. Titoxd(?!? - cool stuff) 18:31, 11 April 2009 (UTC)[reply]
  39. Support while I personally can't what the fuss about these anniversaries is I notice that there is a large call for that kind of information. Agathoclea (talk) 14:47, 12 April 2009 (UTC)[reply]
  40. Support Birth dates et. al. are important information. Option 1 is also acceptable. -- M2Ys4U (talk) 16:17, 12 April 2009 (UTC)[reply]
  41. Support - Again, my ranking is #2, #1, #4, and last #3. Important and relevant dates and years should be linked. Irrelevant ones not. It's as simple as that. But an automated system should not make that determination, nor should there be a "witchhunt" to track down violating dates. Let date changes evolve naturally. It's safer. Important dates could be lost in articles otherwise. --Willscrlt (→“¡¿Talk?!”) 13:25, 13 April 2009 (UTC)[reply]
  1. This is how everything else is linked, I don't see why years should be treated any differently.-Jeff (talk) 00:11, 30 March 2009 (UTC)[reply]
  2. As above, I think it should be like this, it can be interesting. — Preceding unsigned comment added by Dottydotdot (talk • contribs)
  3. Support Lets give the readers as many opportunities to find new information as possible, relevance is subjective and secondary. Unomi (talk) 16:51, 31 March 2009 (UTC)[reply]
  4. strong Support. Year links give access to have an overview about what happened around a certain date. This is relatively important while doing research, because this can add (historical) background information for those who which to know more about what happened at a certain time, what events might have also influenced public opinion etc. Also, what is relevant to one may be unrelevant to someboedy else... How do you want to determine what is relevant or what is not? For me, these links are relevant since they give the opportunity to find and discover other interesting articles better than any other feature. Old Death (talk) 21:53, 2 April 2009 (UTC)[reply]
  5. Support, when I've been reading articles, I generally found date/year links helpful to get historical perspective. --Soman (talk) 07:19, 5 April 2009 (UTC)[reply]
  6. Strong Support. Per above, adding that serendipity sometimes plays a useful role in research.[22]Daytrivia (talk) 22:59, 5 April 2009 (UTC)[reply]
I support Option #4 (removal of guidance)
  1. Strongly support. All links are required to be relevant and helpful to the reader. what more do we need to say about these? Septentrionalis PMAnderson 23:32, 29 March 2009 (UTC)[reply]
    • This is the only way to ensure that date links are treated like other links. I observe that, despite the successful campaign to remove this objective from this poll, this equality has received support from support for all forms of language.
    • Even #3 has been read to impose restraints on date links which do not apply to other links, as in These comments. #1 and #2 have been used to justify extreme and sweeeping removals.Septentrionalis PMAnderson 00:41, 30 March 2009
  2. Yes please; take as much as possible out of the hands of the hands of the people who made this clusterfuck in the first place. Mr.Z-man 01:19, 30 March 2009 (UTC)[reply]
  3. Support. I agree that years have been linked too much, but option #1 is over-reacting; on the other hand option #3 is silly (who would make any link in "Retrieved on 30 March 2009" at the end of a citation?). Option #2 is sane in principle, but the word seminal remembers me more of sperm than of anything which has anything to do with hypertextual links. The point is, I would make links if the historic context when something happened is relevant: I wouldn't link to 1824 in "However, there is no formula for general quintic equations over the rationals in terms of radicals; this is known as the Abel–Ruffini theorem, first published in 1824, which was one of the first applications of group theory in algebra": that theorem could have been published in 1624, or in 1924, and that would make no difference to the point being made about quintic equations. But I don't think I would be able to put down in words all the rules I would use to decide when a link to a year is relevant: I know it when I see it. This issue is best left to editors' common sense than to blind application of a list of rules. (FWIW, my preferences are 4-2-3-1 in decreasing order.) ---A. di M. (talk) 09:29, 30 March 2009 (UTC)[reply]
  4. Support As above, incl. metadata commentary and options. billinghurst (talk) 10:37, 30 March 2009 (UTC)[reply]
  5. Support MOS should not be dictating content decisions to editors (and really, even style issues per Requests for arbitration/Jguk), so all such language should be removed. —Locke Cole • t • c 11:05, 30 March 2009 (UTC)[reply]
  6. Support Anything more than this will result in overcorrection. Wrad (talk) 17:03, 30 March 2009 (UTC)[reply]
  7. Strong Support as I found it very useful and interesting to be able to click a date and see what other events happened then. Yes, there were (and still are) a lot of articles linked to specific dates (as happens in a world with a long history), but I think that argument is irrelevant. All this worry about articles having too many links to them is pointless worry as we will have more and more articles linked to each other as the encyclopedia grows. Are we going to start limiting the number of links which can be placed into articles when we reach 5 or 10 million articles just so we don't have "too many links" to any given article? That's just absurd. We're going to have to accept that many articles on main topic are going to have hundreds, thousands, and perhaps tens of thousands of links to them. In the case of dates, it's likely they will be on the high end of things, but that's what happens when an online encyclopedia grows. And the argument that someone is going to have to go put back the links that someone removed is absurd. Just run the same bots again, only in reverse. It certainly won't be any more difficult than it was to remove them all. I strongly oppose #1 and #2, and think #3 is too arbitrary. ···日本穣? · Talk to Nihonjoe 19:25, 30 March 2009 (UTC)[reply]
  8. Support. I find these proposals CREEPY. This is much more than when to use italic text or in what way bullet points should be used in an article. This is about links, the fundamental infrastructure of the web and the connections between articles on Wikipedia. Whether or not a specific date article requires a link is not the point, such a blanket guideline is too much and it'd be better handled on a case by case basis. --Bill (talk|contribs) 20:41, 30 March 2009 (UTC)[reply]
  9. I also support option 2. 1000% support of Gavia immer's comment above. AKAF (talk) 07:05, 30 March 2009 (UTC)[reply]
  10. Support Let the editors maintain control over what is and isn't relevant. bots do enough as it is — Ched ~ (yes?)/© 21:28, 30 March 2009 (UTC)[reply]
  11. Support We need exactly one rule for when to use links, dates are not special. When I click on a link I expect useful information in the context of what I am reading. Use dated categories to serve the purpose of linking in time similar events and can be specific to the type of article. --NrDg 00:11, 31 March 2009 (UTC)[reply]
  12. Support Many dates require linking, regardless. Infoboxes look much nicer when dates are highlighted. Hence, I support #4. Daniel Benfield (talk) 01:22, 31 March 2009 (UTC)[reply]
  13. Support It just doesn't matter so let people do what they want. hulmem (talk) 03:19, 31 March 2009 (UTC)[reply]
  14. Support Switched from option 2 as per Pmanderson. It's the only way to be sure.dm (talk) 06:06, 31 March 2009 (UTC)[reply]
  15. Support. Switched from option 2 as well. Date links are not special. — Hex (❝?!❞) 11:49, 31 March 2009 (UTC)[reply]
  16. Support removal of all guidance (changed from option 1). This whole issue reeks of WP:CREEP and WP:BIKESHED. Editors can make their own decisions. I would always choose Option #1's logic, but don't feel that this justifies having a written guideline for it. This whole tempest in a teapot is reminiscent of people getting hot and bothered about the correct dash to use. When we hit the WP:DEADLINE, we can clean up the little stuff before we send it to the printers. SDY (talk) 15:35, 31 March 2009 (UTC)[reply]
  17. Strong support. Let's rid the MoS of such useless naval-gazing. Physchim62 (talk) 19:11, 31 March 2009 (UTC)[reply]
  18. Strong support fewer rules=good J04n(talk page) 01:22, 1 April 2009 (UTC)[reply]
  19. BAM! The Man has too much power. — Twas Now ( talk • contribse-mail ) 09:23, 1 April 2009 (UTC)[reply]
  20. Strong support I really agree with J04n's comment that fewer rules=good. With Wikipedia edited by many contributors, with different ideas of appropriateness, imposing one Procrustean solution is stupid. -- BRG (talk) 14:42, 1 April 2009 (UTC)[reply]
  21. Support Let editors determine appropriate implementation at the article or project level. Content discussions are not under the purview of MOS. --guyzero | talk 20:49, 1 April 2009 (UTC)[reply]
  22. Support Editors should be allowed to link particularly important years to provide readers with background information about the events that occurred in that year, in order to better contextualize the current article's subject. Option 1 appears to disallow this; option 2 focuses on birth and death dates, which are the least relevant when talking about the events in a person's life; option 3 dilutes the value of year links. This leaves only option 4 for me. AxelBoldt (talk) 03:07, 2 April 2009 (UTC)[reply]
  23. Support. I've always viewed this matter as a choice of individual preference. There's much too much creep here. bibliomaniac15 23:48, 4 April 2009 (UTC)[reply]
  24. Support. Enough instructions already.--catslash (talk) 23:57, 4 April 2009 (UTC)[reply]
  25. Support - Seems better than any alternative. Shoemaker's Holiday (talk) 06:10, 5 April 2009 (UTC)[reply]
  26. Support. However, leave a comment that the style used to be to link every date, and many articles still do this, but now years should only be linked if the they follow the general rules. JonH (talk) 09:09, 5 April 2009 (UTC)[reply]
  27. Support. Cost of a reg is nonzero. --Thomas Btalk 17:01, 5 April 2009 (UTC)[reply]
  28. Strong Support Absent a reason to change, why make a new rule? Phil_burnstein (talk) 09:55, 6 April 2009 (UTC)[reply]
  29. Support. Every unnecessary piece of policy should go. --Pgallert (talk) 10:05, 7 April 2009 (UTC)[reply]
  30. Support. Matching my comments on dates. Leave the decision up to editors. If you want to achieve consistency, it's best done by getting rid of all of these bothersome volunteer editors and having a small group of appointed editors who makes all the decisions and follow all of the rules. If you want to continue the free-for-all of anyone can edit, then you have to also accept some free-for-all formatting. I'm a whole lot less distracted by a sea of blue links than I am by the zillions of footnotes. Fijagdh (talk) 21:38, 8 April 2009 (UTC)[reply]
  31. I would almost go with Option 3, but if a year link is relevant twice or more in an article it'd be good to link it twice; this is not the case for month/days. Therefore, I support this option, seeing as it's the most likely way such would be encouraged.Simplebutpowerful 00:22, 9 April 2009 (UTC)[reply]
  32. Support As Guyzero expressed it above: "Let editors determine appropriate implementation at the article or project level. Content discussions are not under the purview of MOS." Thanks, Lini (talk) 01:05, 9 April 2009 (UTC)[reply]
  33. Support I've never understood the need for these links. --Auntof6 (talk) 07:20, 11 April 2009 (UTC)[reply]
  34. Support The date pages have nothing of consequence to these articles, end the clutter and get rid of them all. You can still find them by typing it in the search box.- J.Logan`t: 11:21, 11 April 2009 (UTC)[reply]
  35. Support perhaps with a caveat, maybe a statement in MOSNUM or MOSLINK that states explicitly "dates are not treated any differently than any other word or term with regards to linking guidelines". That may make it more clear for users who historically are use to linking dates excessively, as the old guidelines said to do so. --Jayron32.talk.contribs 15:00, 12 April 2009 (UTC)[reply]
  36. Support. Dates are not special. But, as Jayron32 has observed, given the history of the affair, a (placeholder) sentence that explicitly states "not special" might be a good idea. -- Fullstop (talk) 12:15, 13 April 2009 (UTC)[reply]
  37. Support: Sometimes year links are quite relevant, often they're just a distraction, but that should be argued by the editors of a specific article on the basis of issues specific to that topic. If auto-formatting by link is removed, however, then an indication in the Manual that this is no longer a reason for linking would be extremely useful. ¶ There really ought to be something like a Collection of Suggestions to give helpful, non-mandatory hints and comparisons with other articles, because any stylistic guidance in the Manual of Style eventually becomes in many uniformity-minded editors' eyes, universally and peremptorily obligatory, to be strayed from after some (usually little-known) ill-tempered, arcane and monstrously huge discussion like this one, that soon gets buried away from profane eyes in Wikipedia Talk: MOS or Wikipedia Talk: MOSNUM Archive no. 23 or 37. —— Shakescene (talk) 20:41, 13 April 2009 (UTC)[reply]
Other comments

I don't like overlinking any more than the next guy, but I really think that option 4 will lead to editors overreacting. We don't want to kill all year links, and if you have a special guideline for year links that says they can only be linked in X, Y, or Z situations, then people will think: "If year links have a special section, then that means they must be judged more strictly than any other links." I don't think that is what most people supporting the first proposal intend to support. I much prefer option one. Year links need to just quietly slide into the same mass of rules all other links abide by. If we overreact, then we will, I guarantee you, be back in a few months, after several edit wars, having another poll. Wrad (talk) 17:11, 30 March 2009 (UTC)[reply]

Karanacs: You first changed my vote to another option. Then when I reverted that you deleted my vote. You do not delete my vote. Here it is again. And don't you dare deleting it, changing it or moving it:
I support Option #0 (don't link years)
1: Support - I prefer not linking year numbers at all. If you want to link the year, then do a proper link that more clearly says what it is linking.
--David Göthberg (talk) 19:45, 1 April 2009 (UTC)[reply]

  1. ^ contribuciones de Rydel a la herramienta global de contribuciones de usuarios de Luxo. Consultado el 7 de enero de 2008 .
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.