Conversa de ajuda: Estilo de citação 1

Da Wikipédia, a enciclopédia livre
Ir para navegação Pular para pesquisar
NewFavicon icon.svg           Outros banners de páginas de discussão
Modelos de citação
... na concepção
... e na realidade

Sugestão de parâmetro: | page-url =

Muitas das citações que vejo apontando para referências em archive.org incluem urls para páginas específicas no |page=parâmetro como em |page=[https://archive.org/details/cihm_07495/page/n255 237]. Parece que um parâmetro adicional, talvez nomeado |page-url=, seria útil para controlar essas informações separadamente. Até agora, tenho deixado os links assim porque eles não parecem estar quebrando nada ainda. Slambo (fala) 15:43, 20 de julho de 2021 (UTC)[]

Deve ser um alias de |url=, não um novo parâmetro. Apenas 1 URL, o mais específico, deve ser inserido nas citações, com a página ou a primeira página em um intervalo de páginas. Em qualquer caso, eu removeria o url do parâmetro de página e inseriria o parâmetro de url. Se a citação incluir um número de página, entende-se que o link pode levar à página pertinente. Se for necessário vincular várias páginas, referências curtas seriam mais adequadas. 50.74.114.218 ( talk ) 17h46min de 20 de julho de 2021 (UTC)[]
Porque? A URL da publicação fornece acesso a informações sobre o contexto das páginas citadas. - Shmuel (Seymour J.) Metz Usuário: Chatul ( talk ) 14:04, 21 de julho de 2021 (UTC)[]
Está correto. Mas também potencialmente confuso, no sentido de ter dois URLs apontando para coisas diferentes, ou seja, informações / contexto sobre a obra (a URL da obra) e o local da obra (a URL da página). Não estou certo de que o leitor médio será capaz de navegar por isso com facilidade. Suponho que pessoalmente incluiria o URL do trabalho na citação completa e os URLs das páginas nas referências curtas. Mas isso é apenas uma preferência. 65.88.88.126 ( talk ) 16:54, 21 de julho 2021 (UTC)[]
Recentemente, tivemos uma discussão relacionada no Help talk: Citation Style 1 / Archive 78 # Como extlink os componentes de uma publicação de múltiplos componentes .
Esses links de página são normalmente adicionados por bots. Quando os vi pela primeira vez adicionados a artigos, alguns anos atrás, também pensei que seria uma má ideia (porque eles adicionam desordem aos |pages=parâmetros), no entanto, eles não são tão ruins quanto podem parecer à primeira vista: como você já observados, eles não estão quebrando nada (em nenhum dos parâmetros relacionados à página, isto é), porque os links são removidos automaticamente antes de usar as informações da página para metadados.
Com relação à sugestão de ter (apenas) um alias |url=para um "link de página" e para a proposta ter parâmetros de página numerados (no outro thread), isso não funcionaria:
Ao contrário do que afirma o IP, o |pages=O parâmetro geralmente contém uma lista de páginas ou mesmo intervalos de páginas, e não é desejável dividi-los em páginas individuais ou usar referências curtas para elas. A divisão em páginas individuais só é necessária quando é particularmente importante documentar os locais exatos onde várias declarações independentes são obtidas. Na grande maioria dos casos, isso não é importante e combinar todas as referências a uma única publicação e fornecer uma lista de páginas é suficiente. Na maioria dos casos, é fácil folhear essas páginas para encontrar aquela que apóia uma declaração específica, portanto, ter referências individuais para cada uma delas apenas adicionaria redundância e desordem ao artigo. Referências curtas adicionam uma camada extra de indireção e não permitem backlinks,portanto, eles são frequentemente inconvenientes de usar - eles resolvem um problema adicionando um monte de outros problemas. PorWP: CITEVAR , eles não são obrigatórios de forma alguma e muitas pessoas não querem (querem) usá-los por causa de suas deficiências. Portanto, sugerir qualquer coisa que nos obrigue a dividir as citações simplesmente não é solução.
Com relação aos links de páginas numeradas (como sugerido no outro tópico), isso exigiria não apenas parâmetros de link de página numerados, mas também parâmetros de página numerados, caso contrário, seria quase impossível saber qual link pertence a qual página. Embora fosse uma solução tecnicamente viável, não seria uma boa, porque tornaria a lista de páginas ainda mais difícil de ler e adicionaria uma enorme quantidade de desordem de parâmetros às citações. Isso também tornaria o código muito mais complexo e difícil de manter. Quero dizer, nós fazemostêm parâmetros numerados para os vários tipos de contribuidores, mas não os temos porque essa seria uma ideia particularmente boa, mas simplesmente porque o modelo precisa saber o nome dado, o sobrenome e, opcionalmente, o link para gerar a representação adequada para para fins de exibição e metadados a partir disso, e a complexidade dos esquemas de nomenclatura torna impossível fornecer apenas uma lista de nomes e permitir que o modelo seja confiávelextraia os bits informativos dele. Funcionaria em alguns casos, mas não em geral; é por isso que precisamos de um conjunto de parâmetros numerados para os nomes. No entanto, embora haja uma grande variedade de esquemas de numeração de página, eles ainda são muito mais simples do que nomes e, portanto, o código pode ser inteligente o suficiente para extrair de forma confiável todas as informações necessárias de um único argumento de parâmetro.
Finalmente, houve uma reclamação de que seria uma má decisão de projeto os parâmetros aceitarem vários tipos de entrada. Eu posso ver de onde vem isso, e às vezes é verdade, mas não para modelos de citação na Wikipedia. Eu considero nossa abordagem orientada a objetos(ou pelo menos tentamos dar essa impressão aos usuários). Existem limites, mas idealmente, você poderia lançar qualquer tipo de "objetos de dados" contendo as informações relevantes em um parâmetro e o modelo seria capaz de descobrir tudo sozinho. Do ponto de vista dos usuários, a maneira mais intuitiva de fornecer um link é usar nossa sintaxe wikitext padrão do Mediawiki. Além disso, simplesmente não deve importar se eles fornecem uma única página, um intervalo de páginas, uma lista de páginas únicas, uma lista de intervalos de páginas, qualquer tipo de combinação deles, uma página vinculada, intervalo de páginas vinculadas, lista de páginas vinculadas ou intervalos vinculados, você entendeu ... (Não no caso de parâmetros relacionados à página, mas para integridade, em alguns casos, os parâmetros também aceitam algumas palavras-chave simbólicas além de objetos de texto.) O que pode ser mais simples e intuitivo de um do utilizador'perspectiva do que permitir que eles usem a sintaxe normal do Wikitexto e apenas forneçam uma lista de itens de dados? Na verdade, não pode ser mais fácil do que isso. (Infelizmente, não podemos fazer isso para nomes, pelo menos não sem introduzir uma sintaxe especial, que frustraria a ideia.)
Mais um pensamento sobre isso: como já foi dito acima, eu também não gosto particularmente dessas strings longas como |page=[https://archive.org/details/cihm_07495/page/n255 237](mas passei a aceitá-las porque adicionam informações úteis para os leitores e que as citações só se tornariam mais longas com o uso de parâmetros especiais por esta). No entanto, em muitos casos, a primeira parte desses links é igual ao link fornecido no |url=parâmetro, como em . Para esses casos, posso imaginar algum tipo de notação de atalho como . Obviamente, isso não funcionaria para todos os casos, mas já reduziria a desordem e a redundância em muitos casos.|url=https://archive.org/details/cihm_07495|page=[*/page/n255 237] |url=https://archive.org/details/cihm_07495
Algo relacionado:
- Matthiaspaul ( talk ) 00:11, 21 de julho 2021 (UTC) (atualizado 13:45, 13 de agosto 2021 (UTC))[]
Você diz que as referências curtas adicionam uma camada extra de indireção e não permitem backlinks ; no entanto, vejo referências anteriores a, por exemplo, 3270Intro , em IBM 3270 # References . É certo que é um pouco desajeitado, mas funciona. - Shmuel (Seymour J.) Metz Usuário: Chatul ( talk ) 14:04, 21 de julho de 2021 (UTC)[]
Eu quis dizer backlinks das "citações básicas" de volta às várias referências curtas. No seu exemplo, se você chegar, por exemplo, à citação "3270Intro", não há links para acessar todas as referências curtas que apontam para esta entrada; você teria que procurá-los passando por todas as referências. No entanto, se eu chegasse lá, gostaria de ver todos os outros locais citados nesta publicação. Com uma quantidade extrema de trabalho, algo como isso poderia ser construído manualmente, mas estaria sujeito a erros e seria muito difícil de manter. Em seu exemplo específico de "3270Intro", há apenas duas referências curtas apontando para lá, portanto, elas podem ser facilmente mescladas em uma, sem perda de informações. Mesmo em casos como "3270DS", que têm muito mais referências curtas,a maioria deles está se referindo a páginas adjacentes no capítulo 3, então provavelmente é suficiente consultar o capítulo 3 e talvez o intervalo de páginas, mas não a páginas individuais e, assim, evitar a maioria, senão todas as referências curtas. Se houver uma declaração particularmente importante a ser mencionada,|quote=e também |quote-pages=pode ser útil. Se os números das páginas individuais devem ser preservados, {{ rp }} pode ser usado para as páginas individuais e |pages=para as páginas combinadas. Dessa forma, a camada adicional de indireção pode ser evitada e backlinks automáticos são possíveis.
- Matthiaspaul ( talk ) 15:00, 21 de julho de 2021 (UTC)[]
Usar funciona bem quando você está apenas adicionando um número de página à citação base, mas a que é equivalente ? - Shmuel (Seymour J.) Metz Usuário: Chatul ( talk ) 21:52, 21 de julho de 2021 (UTC)<ref name=foo />{{rp|bar}}{{sfn|foo|p=bar|loc=baz}}[]
Eu apenas acrescentaria, separado por uma vírgula, como em . Alternativamente, você provavelmente poderia usar algo como ou . Até mesmo links de página podem ser usados ​​em combinação com , embora isso às vezes possa exigir o uso de parâmetros numerados como [Atualização 2021-08-11: as convenções de chamada foram aprimoradas, agora não é mais necessário].<ref name="foo" />{{rp|bar, baz}}{{rp|at=p. bar, baz}}{{rp|at=baz}}{{rp}}|1=
No entanto, WP: CITEVAR se aplica e você pode usar etc. se quiser. Meu ponto acima foi principalmente que várias páginas são perfeitamente adequadas em uma citação (mesmo quando usadas para apoiar várias declarações independentes em um artigo) e que não há nenhum requisito e, muitas vezes, nenhum benefício em dividir as citações em referências curtas individuais - isso tem um preço, e as desvantagens costumam ser maiores do que as vantagens - como sempre, depende das circunstâncias. Fiz isso para ilustrar por que precisamos oferecer suporte a várias páginas e por que propostas que nos permitiriam lidar apenas com páginas únicas (ou relacionadas) em uma citação não levam a lugar nenhum.{{sfn}}
- Matthiaspaul ( talk ) 00:53, 22 de julho de 2021 (UTC)[]
Adicionar vários números de página que suportam diferentes afirmações em uma única citação não é um problema, mas esta discussão sobre links de página não é? Parece-me que uma citação completa com links de várias páginas é pesada e desordenada. Uma referência curta com o link da página específica para o wikitexto específico parece mais intuitiva e fácil de entender. 65.88.88.127 ( talk ) 17:10, 22 de julho de 2021 (UTC)[]
Usando , e dá-me : bar, baz  , : bar, baz  e : p. bar, baz  . O segundo e o terceiro têm as informações corretas, mas o local provavelmente será longo e deve estar na lista de referência, em vez de embutido. - Shmuel (Seymour J.) Metz Usuário: Chatul ( talk ) 19:35, 22 de julho de 2021 (UTC){{rp|bar|at=baz}}{{rp|bar, baz}}{{rp|at=p. bar, baz}}[]

Ainda é um problema com os volumes dos livros

Todos esses meses depois, e o problema com os volumes dos livros ainda não foi abordado. Eu entendo porque não queremos um "volume" explícito com um jornal / revista. Eu não compreender a questão com os livros. Se Birds of North America tiver 13 volumes, exibirá "Birds of North America. 2." não indica, para a maioria dos humanos, claramente que o 2 se refere ao volume 2 - principalmente porque o leitor médio provavelmente não tem ideia de que há 13 volumes no conjunto. Por que o modelo não pode se comportar de maneira diferente dependendo se o item é um livro ou um diário ?! Eu sei que é possível fazer isso, então alguém deve ter alguma justificativa para explicar por que não o fazemos. Por favor explique! MeegsC ( talk ) 20:25, 27 de julho de 2021 (UTC)[]

Inércia, basicamente.
Discussões anteriores produziram dois estilos alternativos propostos para renderização |volume=, |number=/ |issue=(usado apenas com periódicos) e |pages=:
Diário Não jornal Notas
Atual 3 (4): 12–56. 3 , pp. 12–56. Nomes de volumes longos não estão em negrito, mas |volume=vol. 3são considerados um erro.
Proposta 1 3 (4): 12–56. vol. 3, pp. 12–56.
Proposta 2 vol. 3, não. 4, pp. 12–56. Os não periódicos não teriam um número ou edição.
A definição atual de "diário" é
Acredito que devemos oferecer essas alternativas para uma consideração mais ampla. Kanguole 09:37, 28 de julho de 2021 (UTC)[]
{{cite magazine}}?
- trapista o monge ( talk ) 11:07, 28 de julho 2021 (UTC)[]
Adicionando magazine à linha atual:
Diário revista outros
Atual 3 (4): 12–56. Vol. 3 não. 4. pp. 12–56. 3 , pp. 12–56.
Proposta 1 3 (4): 12–56. vol. 3, não. 4, pp. 12–56.
Proposta 2 vol. 3, não. 4, pp. 12–56.
Kanguole 14:10, 28 de julho de 2021 (UTC)[]
Eu apoio a padronização proposta, mas acho que a nomenclatura "científica" ainda pode ser desejável em artigos altamente acadêmicos, portanto, sugiro introduzir um parâmetro |periodical-style=ou |serial-style=(ou qualquer outro) para selecionar o formato desejado se este não for o padrão já. (Em um estágio posterior, isso poderia ser suportado por modelos semelhantes ao |cs1-dates=parâmetro de modelos {{ usar datas dmy }} / {{ usar datas mdy }} para mudar globalmente o formato de exibição para todas as citações em um artigo em vez de ter que usar em citações individuais. Eu tinha algum código experimental para isso há um ano, mas teria que ser ajustado para a base de código atual significativamente alterada.)
Acredito que ter essa opção para substituir o padrão aumentaria significativamente a aceitação da comunidade de uma mudança geral para um formato mais padronizado - sem ela, já vejo o próximo tumulto emergindo de proponentes militantes de um desses formatos. Com esse parâmetro implementado, ainda teríamos instantaneamente um formato consistente na maioria dos artigos (a meta que desejamos alcançar), mas permitiríamos que os editores substituíssem o padrão para atender a necessidades especiais em citações (e artigos) específicos. O melhor dos dois mundos.
Poderíamos usar a Proposta 1 como os formatos padrão para os vários modelos e o parâmetro permitiria substituir o padrão e selecionar o outro formato, ou, poderíamos escolher a Proposta 2 como o novo formato padrão geral para todos os tipos de citação e o parâmetro iria devem ser usados ​​em citações individuais para mudar para o formato científico.
- Matthiaspaul ( talk ) 16:53, 28 de julho de 2021 (UTC)[]
Eu seria fortemente contra a introdução de outro parâmetro de configuração de estilo. Seria outro botão para as pessoas mexerem e brigarem, e já temos muitos deles obstruindo nossas listas de observação. Eu preferiria ter uma opção menos preferida do que essa.
Quanto a aumentar a aceitação, não acho que ninguém goste de livros em negrito. A escolha entre os outros dois deve ser decidida em um RFC. Kanguole 17:11, 28 de julho de 2021 (UTC)[]
Design by rfc; quão terrível.
Eu também me oponho a outro parâmetro de estilo. renderiza o estilo de jornal acadêmico. Se você não gosta disso, use ou . Não há necessidade de parâmetros especiais.{{cite journal}}{{cite magazine}}{{cite periodical}}
- trapista o monge ( talk ) 17:58, 28 de julho de 2021 (UTC)[]
Se quisermos que as pessoas possam usar a revista cite - então ela precisa ser adicionada à Wikipedia: RefToolbar / 2.0 - caso contrário, a maioria dos editores usará apenas os modelos que as ferramentas impõem a eles. Nigel Ish ( conversa ) 18:29, 28 de julho de 2021 (UTC)[]
Você não terá oposição de mim, mas boa sorte com isso:
Talvez, se editores suficientes fizerem barulho sobre isso, alguém fará o trabalho necessário (ingrato) que lhes dará o que desejam. Talvez você?
- trapista o monge ( talk ) 19:12, 28 de julho de 2021 (UTC)[]
Bem, se conforme indicado pelas discussões na página RefToolbar, a ferramenta não está sendo mantida, então ela deve ser desativada. Nigel Ish ( talk ) 20:34, 28 de julho de 2021 (UTC)[]
Eu acho que você está enganado. Várias páginas javascript implementam WP: RefToolbar . A ferramenta é praticamente estável, portanto, há pouco a fazer com ela. Ainda assim, essas partes foram atualizadas este ano:
Como eu disse antes, se editores suficientes fizerem barulho sobre isso, alguém fará o trabalho necessário (ingrato) que lhes dará o que desejam. Se você quiser a mudança, recrute editores suficientes que também queiram a mudança, ou, se não conseguir, faça você mesmo.
- trapista o monge ( talk ) 13:10, 29 de julho 2021 (UTC)[]
O design da RfC provou resultar em soluções inconsistentes, incoerentes e normalmente menos poderosas. Mas forçar nossas próprias (normalmente excelentes ;-) ideias para a comunidade também não é uma opção. Quero dizer, mesmo aqui neste lugar dedicado, onde a maioria de nós tem bastante experiência com formatos de citação, muitas vezes temos visões muito diferentes em relação à melhor solução para um problema, indicando claramente que temos uma gama diversificada de necessidades e, portanto, precisamos de flexibilidade para abordá-los. É por isso que acho que devemos dar aos usuários alguma orientação (na forma de padrões razoáveis ​​e boa documentação), mas também a flexibilidade necessária para que eles possam (se necessário) obter os resultados que desejam para atender a requisitos mais especiais. Caso contrário, eles reclamarão dos nossos modelos ou não os usarão.Ambos são insatisfatórios para eles e para nós - e para o projeto como um todo.
Concordo que, em princípio, seria suficiente deixar {{ cite journal }} usar o formato científico e {{ cite magazine }} o formato verboso - basicamente é um parâmetro de estilo disfarçado. No entanto, temos leitores alternando entre esses modelos com base na natureza do periódico, o que frustraria a ideia de escolher o modelo com base no formato de exibição.
Resumindo, sem um parâmetro de estilo para substituir opcionalmente o padrão, eu ainda poderia suportar a proposta 1, mas não a proposta 2.
- Matthiaspaul ( talk ) 02:05, 29 de julho de 2021 (UTC)[]
@ Matthiaspaul : temos leitores alternando entre esses modelos com base na natureza do periódico - faço isso com frequência ( exemplo ), porque muitas vezes acho que algumas pessoas estão usando inadequadamente , e para revistas - para mim, não é uma questão de escolha [ing] o modelo baseado no formato de exibição, mas na escolha do modelo mais apropriado para a fonte. Cada um desses quatro tem documentação que dá esse conselho: {{cite journal}}{{cite news}}{{cite web}}
  • {{cite journal}} - artigos acadêmicos e científicos publicados em periódicos de boa-fé
  • {{cite magazine}} - artigos em revistas e boletins informativos
  • {{cite news}} - artigos de notícias impressos, em vídeo, áudio ou na web
  • {{cite web}} - fontes da web que não são caracterizadas por outro modelo CS1
Acredito que as pessoas que não usam o fazem em parte porque não lêem a documentação, mas principalmente porque ela não é oferecida pela ferramenta de citação que usam (ver postagem de Nigel Ish em 18:29, 28 de julho de 2021 (UTC .) ea resposta trapista enquanto que continua a ser o caso, sempre haverá a necessidade de alterar a citação -. Red Rose64 🌹 ( talk ) 09:58, 29 de julho de 2021 (UTC){{cite magazine}}[]
Sim, está certo. Na verdade, estou fazendo isso também, mas estou razoavelmente feliz com a diferença nos formatos de saída entre {{ cite journal }} e {{ cite magazine }}. Acho que devemos continuar a manter essa ideia, escolhendo o parâmetro mais adequado |journal=ou com |magazine=base na natureza do periódico. Normalmente, usaríamos |journal=em {{ cite journal }} e |magazine=em {{ cite magazine }}, mas seguindo o comentário de Trappist para escolher o modelo dependendo do formato de saída desejado acima, precisaríamos reconhecer que algumas pessoas podem ter deliberadamente escolhido use {{ cite journal }} para |magazine=ou {{ cite magazine}} para |journal=, e que, se isso faz sentido na renderização de um artigo específico como um todo, devemos deixar isso como está.
- Matthiaspaul ( talk ) 10:14, 29 de julho de 2021 (UTC)[]
Eu acho que o que você está dizendo, sem realmente expressar é que , , todos os redirecionamentos tornou para o modelo canônico . em seguida, renderiza volume / problema / página no estilo ditado pelo alias do parâmetro que é usado no modelo. Isso provavelmente seria um desafio significativo, principalmente em outro lugar que não no Módulo: Citação / CS1 . Algum ou algumas séries de bots precisariam converter modelos existentes; ferramentas como WP: RefToolbar precisariam ser atualizadas, etc. Eu gosto dessa ideia, mas prevejo tochas e pitch forks porque os editores de en.wiki odeiam, odeiam, odeiam mudanças ...{{cite journal}}{{cite magazine}}{{cite news}}{{cite periodical}}{{cite periodical}}|work=
- trapista o monge ( talk ) 13:10, 29 de julho 2021 (UTC)[]

Eu geralmente prefiro alguma forma de Proposta 1. Vamos {{ cite journal }} usar o formato mais curto. Na {{ cite magazine }}, obtenha o número da página ao lado do volume e do número da edição. (Atualmente, se um editor for especificado, ele divide o volume / edição do número da página.) Em {{ cite map }}, et al., Vincule a saída a se |journal=ou |magazine=é usado.

Para os livros, porém, eu deixaria o número do volume próximo ao título como uma função do título e manteria o número da página no final, mas caso contrário adicionaria o "vol." texto para o número do volume para consistência. Imzadi 1979   22:46, 28 de julho de 2021 (UTC)[]

A proposta 2 é o único esquema que faz sentido para um projeto como a Wikipedia. É facilmente compreensível pelos leitores. O separador de vírgula terá que ser explicado aos editores, pois viola o estilo. Isso ocorre por causa da implementação rígida atual de separadores em "estilo 1" e "estilo 2", que não traz nenhuma utilidade funcional. 64.18.9.208 ( talk ) 23:40, 28 de julho 2021 (UTC)[]

  • Proposta de apoio 2 Embora eu ficaria feliz o suficiente com a Proposta 1. Concordo com Imzadi sobre não separar título do volume. Achei que os mantenedores já haviam recusado. Hawkeye7 (discussão) 23:49, 28 de julho de 2021 (UTC)[]
    • Eu pessoalmente prefiro a Proposta 2, mas acho que haveria muita inércia para sair completamente do formato de periódico abreviado. Imzadi 1979   00:16, 29 de julho de 2021 (UTC)[]
  • Prefiro fortemente 1, mas poderia viver com 2 . O status quo é inaceitável. Headbomb { t · c · p · b } 01:22, 29 de julho de 2021 (UTC)[]
  • Proposta de suporte 1 ; Concordo que o status quo não funciona. E a proposta 2 certamente "não é a única que faz sentido", apesar do que um IP anônimo possa afirmar. Estou assumindo que se o campo "número" for deixado em branco, esse parâmetro não aparecerá - ou seja, vol. 2, pp. 12–56. MeegsC ( talk ) 10:28, 29 de julho de 2021 (UTC)[]
Você está dizendo que os leitores são melhor atendidos por interpretações diferentes (e complicadas) de questões e volumes, dependendo do uso de um modelo sobre o qual eles nada sabem? E por que uma afirmação de algo chamado "MeegsC" é melhor em face disso? 64.18.9.201 ( talk ) 11:16, 29 de julho 2021 (UTC)[]
  • Prefira a Proposta 2, mas também apóia a Proposta 1 e prefere fortemente ambas ao status quo. Eu acho (com base em nenhuma evidência, obviamente) que a maioria dos editores que adicionam citações a artigos de periódicos estão provavelmente felizes com a abreviatura acadêmica, uma vez que estão acostumados a ela; portanto, a mudança vai incomodá-los, já que as mudanças de estilo são sempre irritantes. Por outro lado, (ainda baseado em nenhuma evidência), nosso leitor médio provavelmente quase nunca olha para um periódico acadêmico e é deixado para adivinhar o que significa a codificação concisa. Acho que devemos priorizar a clareza para o leitor ao invés do conforto da familiaridade para o editor. Isso vale duplamente para livros em que a abreviatura não é, até onde eu sei, amplamente usada. Wham2001 ( talk ) 11:11, 29 de julho de 2021 (UTC)[]
  • Forte apoio para a Proposta 1 . Isso dá a saída para periódicos e livros que eu esperaria ver na literatura científica. Os livros usam Volume ou Vol, enquanto as revistas têm apenas o número, que pode estar em negrito (a maioria?), Itálico (alguns) ou sem ênfase. Jts1882  |  conversa 12:17, 29 de julho de 2021 (UTC)  []
  • Proposta 2 - é inequívoca, onde a proposta 1 deixa ambigüidade e deixa você confuso quanto ao que os números significam. E a oportunidade de misturar estilos em um único artigo não é muito boa. Keith D ( conversa ) 12:50, 29 de julho de 2021 (UTC)[]
  • Forte suporte para a proposta 1 . Do ponto de vista da biologia, a grande maioria das citações de periódicos científicos é no estilo APA, que processa o volume 8, número 10 como 8 (10) ou 8 (10) ou 8 (10). Acho que seria estranho incluir "vol." em uma citação de biologia, mas não inédita. No entanto, por MeegsC realmente precisa haver uma mudança, há tantos livros científicos publicados em volumes e citados com palavras para observar os volumes. Jack ( talk ) 14:11, 22 de agosto de 2021 (UTC)[]
  • Proposta 1 - não há como fazer a proposta 2 sem obter muitos atritos imediatos da comunidade, o que inevitavelmente resultará em uma solução alternativa como a proposta |periodical-style=acima, que apresenta ainda mais complicações. Imagine o problema de criar uma citação por meios automatizados e tentar determinar o estilo certo a ser usado para um determinado artigo; então precisamos ter algo como bagunçar o topo de cada artigo. Não, não vá por esse caminho. A proposta 1 mantém o que já existe para o qual é de longe o maior de todos e terá menos atrito ao consertar o problema com os outros modelos menores. - Verde C 14:40, 22 de agosto de 2021 (UTC){{use dmy}}{{cite journal}}[]
A Wikipedia não é uma publicação científica. Também não é um veículo para fins especiais para profissionais de qualquer tipo, incluindo aqueles no campo da biologia. Também existe o argumento de que uma solução adaptada a toda a comunidade (seus leitores) deve ser contornada porque uma minoria (seus editores ou um subconjunto deles) pode causar confusão. Não é muito surpreendente. Os "wikipedistas" :) geralmente agem com senso de propriedade e também costumam ter ataques. Nesse ínterim, a Wikipedia, de forma bastante inconsciente, proclama sua própria inutilidade. 195.123.233.197 ( talk ) 15:55, 22 de agosto 2021 (UTC)[]
Definitivamente concordo com o IP aqui. Os artigos não são WP: DE PROPRIEDADE de nenhum indivíduo em particular, e se decidirmos aqui que usar o vol. 3 não. 2 é melhor do que usar 3 (2), uma proposição com a qual concordo plenamente, então é certo e adequado, para o benefício de nossos leitores , permitir que seja propagado para todos os artigos que citam periódicos. -  Amakuru ( talk ) 10:51, 23 de agosto 2021 (UTC)[]
Quem somos "nós"? A experiência tem mostrado, repetidamente, que todos os milhões de comunidade ou mais são sensíveis às mudanças de status quo , e quando "nós" decidimos mudar as coisas para seus "leitores" para o próprio bem de acordo com nossas opiniões de especialistas e corretas, os 'forcados' aparecem e trincheiras são cavadas. IMO esta é uma mudança mais significativa em seguida, dizer |accessdate=vs. |access-date=e você sabe como isso foi, as linhas de batalha agora tão endurecido que é um assunto morto, ele nunca vai ficar fixo. Uma vez que a atenção em larga escala é dada ao problema, você perde o controle. Fique o mais próximo possível do status quo e conserte as pequenas coisas que realmente precisam ser consertadas, você terá sucesso. Volte mais tarde e trate o jornal de citação como um problema separado, porque é provável que não haja consenso. - Verde C 20:47, 23 de agosto de 2021 (UTC)[]
Você está correto ao dizer que qualquer desafio ao status quo causará uma perturbação. Se isso deve dissuadir de aplicar a melhor solução, é a questão. Se isso acontecer, a mediocridade vence novamente. Esta é uma norma aqui. Afinal, este é um projeto onde, sem qualquer senso de ironia ou autoconsciência, a maior parte de seu conteúdo é considerado suspeito por padrão. Há uma pequena minoria dos chamados "bons artigos". Quem pensaria, deveria imediatamente levantar a questão, por que deveria uma enciclopédia publicar artigos que ela mesma designou como não bons? Comparados a essa esquizofrenia institucional, os forcados sem dúvida já afiados com esse fio parecem palitos de dente. 195.123.233.197 ( falar ) 00:21, 24 de agosto de 2021 (UTC)[]
  • Proposta 2 . Há muito tempo penso que o formato 3 (2) não é ideal para uso em uma enciclopédia, onde a maioria dos leitores não é especialista e pode não saber automaticamente o que significa. É muito melhor explicar explicitamente o que se quer dizer, usando o vol. e não. nomenclatura, de acordo com o estilo de citação Chicago ou MLA. Isso deve se aplicar a qualquer publicação, seja um jornal, livro, revista ou qualquer outra coisa. Amakuru ( talk ) 10:47, 23 de agosto de 2021 (UTC)[]
  • Proposta 1 . No entanto, gostaria de solicitar que {{ cite magazine }} use a mesma nomenclatura que o editor da edição. - Shmuel (Seymour J.) Metz Usuário: Chatul ( talk ) 19:18, 23 de agosto de 2021 (UTC)[]

Implementação

Parece ser universalmente aceito que números de volume em negrito para não periódicos são inaceitáveis, mas as opiniões estão divididas quanto a mantê-los para periódicos, ou seja, não há consenso para mudança nisso. Portanto, mudei o sandbox para estender a formatação da revista a todos os não periódicos.

Cite a comparação do livro
Wikitexto {{cite book|first=Ann|last=Author|pages=12–34|title=Book|volume=3|year=2000}}
Ao vivo Autor, Ann (2000). Livro . 3 . pp. 12–34.
Caixa de areia Autor, Ann (2000). Livro . Vol. 3. pp. 12–34.
Cite Journal Comparation
Wikitexto {{cite journal|first=Ann|journal=Journal|last=Author|number=5|pages=12–34|title=Article|volume=3|year=2000}}
Ao vivo Autor, Ann (2000). "Artigo". Journal . 3 (5): 12–34.
Caixa de areia Autor, Ann (2000). "Artigo". Journal . 3 (5): 12–34.
Comparação de citação
Wikitexto {{citation|first=Ann|last=Author|pages=12–34|title=Book|volume=3|year=2000}}
Ao vivo Autor, Ann (2000), Livro , 3 , pp. 12-34
Caixa de areia Autor, Ann (2000), Livro , vol. 3, pp. 12-34
Comparação de citação
Wikitexto {{citation|first=Ann|journal=Journal|last=Author|number=5|pages=12–34|title=Article|volume=3|year=2000}}
Ao vivo Autor, Ann (2000), "Artigo", Jornal , 3 (5): 12-34
Caixa de areia Autor, Ann (2000), "Artigo", Jornal , 3 (5): 12-34

Kanguole 19:11, 10 de setembro de 2021 (UTC)[]

Separador entre volume e número

Parece bom. Aqui estão mais dois para comparação (sem alteração):
Comparação de citação
Wikitexto {{citation|date=2000|first=Ann|last=Author|magazine=Magazine|number=5,7|pages=12–34|title=Article|volume=3,5}}
Ao vivo Autor, Ann (2000), "Artigo", Revista , vol. 3, 5 não. 5, 7, pp. 12-34
Caixa de areia Autor, Ann (2000), "Artigo", Revista , vol. 3, 5, não. 5, 7, pp. 12-34
Comparação da revista Cite
Wikitexto {{cite magazine|date=2000|first=Ann|last=Author|magazine=Magazine|number=5,7|pages=12–34|title=Article|volume=3,5}}
Ao vivo Autor, Ann (2000). "Artigo". Revista . Vol. 3, 5 não. 5, 7. pp. 12–34.
Caixa de areia Autor, Ann (2000). "Artigo". Revista . Vol. 3, 5, não. 5, 7. pp. 12–34.
No entanto, acho que devemos colocar pelo menos uma vírgula (possivelmente um ponto em CS1) entre o volume e as informações do número. Parece-me estranho que não haja separador entre eles, mesmo nos casos simples acima, mas ainda mais nos casos mais complicados (para fins de ilustração, alterei os parâmetros |volume=e |number=para conter listas).
- Matthiaspaul ( talk ) 14:48, 15 de setembro de 2021 (UTC)[]
Sim, a apresentação atual de não foi alterada e agora se estende a outras revistas não. Porém, a combinação de e deve ocorrer apenas com revistas e periódicos, portanto sua formatação independe dessa alteração. Kanguole 15:27, 15 de setembro de 2021 (UTC){{cite magazine}}|volume=|number=[]
Eu acrescentaria que nunca vi listas dentro |volume=ou |number=fora dela - geralmente é 3/4 ou 3-4. Se um artigo for publicado em várias partes com diferentes intervalos de páginas em diferentes edições / volumes, elas deverão ser citações separadas. Kanguole 15:34, 15 de setembro de 2021 (UTC)[]
Sim, embora raramente e não em combinação em ambos |volume=e |number=. Usei aqui como um exemplo para mostrar com mais clareza, que há algo faltando entre o volume e o número. Eu basicamente "sequestrei" este tópico para a possível discussão de adicionar uma vírgula (ou ponto), porque esta seria outra alteração menor provavelmente aceita (se mesmo notada) pelas massas, e porque este tópico já tem uma boa lista de citações renderizadas modelos para comparação rápida da saída.
- Matthiaspaul ( talk ) 16:48, 15 de setembro de 2021 (UTC)[]
Feito. - Matthiaspaul ( talk ) 14:19, 24 de setembro 2021 (UTC)[]

Limite s2cid atingido

Apenas para avisar que está começando a haver artigos preenchendo na categoria: erros CS1: S2CID que parecem estar corretos com valores maiores que 237000000. - Lightlowemon ( conversa ) 13:55, 31 de agosto de 2021 (UTC)[]

Só para fins de registro, isso foi prontamente definido para 240000000 em 31/08/2021 pela Trappist.
- Matthiaspaul ( talk ) 19:08, 26 de setembro de 2021 (UTC)[]

Marcação HTML

@ Trappist o monge : Saudações! Para responder à sua pergunta levantada nesta reversão , Sbb iniciou um tópico na conversa do usuário: Beland # Uso de modelos, HTML e entidades HTML dentro de modelos de citação . Acho que isso aconteceu porque eu estava mudando artigos (incluindo citações) para ficar em conformidade com o MOS: FRAC e Wikipedia: Manual de estilo / sobrescritos e subscritose as diretrizes atuais resultam em marcação HTML em vez de frações, sobrescritos e subscritos pré-compostos Unicode. Não consegui encontrar uma especificação COinS oficial que explica como lidar com sobrescritos, frações (incluindo aqueles não disponíveis como caracteres pré-compostos), itálico e outras marcações em campos. Achei que Sbb estava defendendo sem oposição que caracteres Unicode fossem usados ​​em vez de marcação, e estava começando a mudar as diretrizes para refletir isso quando chamamos sua atenção. Sbb também apontou que tem havido oposição na conversa da Wikipedia: Manual de estilo / sobrescritos e subscritos. Portanto, seria bom discutir para que eu possa obter alguns esclarecimentos sobre qual é o consenso aqui para que eu possa atualizar meu código de verificação ortográfica e páginas de diretrizes, se necessário. Existem várias possibilidades para o que fazer:

  • Use caracteres Unicode sempre que possível (mas a marcação é difícil de evitar em 100% dos casos)
  • Use HTML quando necessário para seguir as diretrizes do MOS, mas evite modelos porque eles tendem a espalhar marcações HTML indesejadas e esperam que os consumidores posteriores analisem <sup>...</sup>etc.
  • Como sugerido pelo Headbomb , siga as diretrizes da Wikipedia para fins de exibição, mas escreva algum código para que os modelos de citação forneçam aos consumidores COinS resultados traduzidos em Unicode sem marcação, ou o que for necessário em qualquer caso particular.

Pensamentos? - Beland ( talk ) 02:59, 12 de setembro 2021 (UTC)[]

Não sou trapista, mas discordo veementemente de sua sugestão de usar substitutos Unicode em referências e sua implicação de que podem ser substitutos adequados para a formatação matemática em títulos de referência. Eles não são substitutos adequados. Em particular, eles são muito limitados em sua aplicação e freqüentemente incompatíveis em aparência com a formatação matemática apropriada que é exigida quando seus limites são atingidos. - David Eppstein ( conversa ) 04:33, 12 de setembro de 2021 (UTC)[]
Os metadados COinS são transportados no title="..."atributo de um <span>...</span>elemento HTML vazio que também possui o atributo class="Z3988". Os atributos HTML não podem conter marcação de qualquer tipo, então se não puder ser higienizado para remover a marcação, deve ser omitido em primeiro lugar. - Red Rose64 🌹 ( talk ) 07:22, 12 de setembro de 2021 (UTC)[]
@ Redrose64 : A marcação pode aparecer lá, mas precisa ser codificada. Os exemplos que o Sbb deixou na minha página de discussão usam codificação percentual , então, por exemplo, <sup> seria codificado como %3Csub%3E. Parece que outros campos (como o URL da página) também usam codificação por cento, então os consumidores downstream deveriam decodificar por cento, é claro? O resultado dessa decodificação pode ser HTML ou Unicode ou MathML sem marcação ou qualquer outro. - Beland ( talk ) 16:49, 12 de setembro de 2021 (UTC)[]
Minha conclusão seria, em vez disso, que se as COINS não podem representar referências precisas, então devemos descartar as COINS em vez de usá-las como uma desculpa para forçar nossas referências a serem imprecisas. O rabo está sacudindo o cachorro. Devemos ser capazes de citar artigos como, digamos, Pintér, Ákos; de Weger, Benjamin MM (1997). "". Publicationes Mathematicae Debrecen . 51 (1–2): 175–189. MR  1468225 .. Se nossa conversão de COINS produzir lixo como "rft.atitle = MATH + RENDER + ERROR" porque COINS é incapaz de representar tais títulos, nos impede de incluir o nowrap evitando a horrível quebra de linha entre aspas duplas e o início do título, ou pior, evita mesmo que possamos especificar tais títulos, então o problema são as MOEDAS. Encontre alguma outra maneira de obter sua correção de raspagem de metadados. - David Eppstein ( conversa ) 07:24, 12 de setembro de 2021 (UTC)[]
Essa coisa "MATH + RENDER + ERROR" é um espaço reservado inserido por nós para objetos matemáticos para os quais não podemos gerar metadados sensíveis. Como foi corretamente apontado, COinS basicamente quer texto simples, mas uma vez que todos os dados são codificados, não estamos limitados ao que o atributo title = HTML permitiria e também poderia transmitir quase qualquer tipo de outra coisa. O problema é que "outras coisas" não fazem sentido para o receptor. Eu acho que, enquanto o título ocasionalmente contiver marcação simples como <sup></sup>essa, é fácil de ser analisado corretamente até mesmo por humanos, mas a maioria das coisas matemáticas é mais complicada.
O que outros produtores de moedas fazem nesses casos?
Havia / existe alguma notação padrão sobre como transliterar matemática em ASCII, por exemplo, em postagens de grupos de notícias antigos? Nesse caso, poderíamos tentar traduzir blocos matemáticos para isso e torná-los parte dos metadados.
Em alguns casos, retirar toda a marcação e deixar apenas texto simples e dígitos também pode criar uma string que ainda pode ser boa o suficiente para humanos reconhecerem um título ou funcionar como um padrão de pesquisa, mas dificilmente seria ideal.
Outra solução poderia ser fornecer um título descritivo |descriptive-title=, além do título apropriado, |title=e se o título apropriado for muito complicado para usar para metadados, passe o título descritivo em seu lugar. - Matthiaspaul ( talk ) 09:34, 12 de setembro de 2021 (UTC)[]
Em relação ao seu comentário sobre o nowrap evitando a horrível quebra de linha entre aspas duplas e o início do título , ainda não vi isso. você pode dar um exemplo? - Matthiaspaul ( talk ) 09:43, 12 de setembro 2021 (UTC)[]
Agora vi que você adicionou um exemplo usando nowrap acima, então isso não é mais necessário. Para ilustrar sua observação, aqui está o exemplo sem o nowrap:
Pintér, Ákos; de Weger, Benjamin MM (1997). "". Publicationes Mathematicae Debrecen . 51 (1–2): 175–189. MR  1468225 .
- Matthiaspaul ( talk ) 11:53, 12 de setembro 2021 (UTC)[]
O principal a se ter em mente é que as citações ajudam na descoberta de informações, e os dados que elas carregam devem estar no formato mais fácil de ser encontrado, que é, exatamente como a informação de origem apresenta, personagens "engraçados" e tudo. Por "informação da fonte", quero dizer a entrada do índice para o trabalho nos vários bancos de dados de classificação, que é o que um leitor será apresentado ao descobrir a fonte. O que quer que WP: MOS diga que é secundário. E, a sugestão de descartar as moedas se não puder representar adequadamente esses dados é adequada. 65.88.88.57 ( talk ) 12:12, 12 de setembro de 2021 (UTC)[]
COinS realmente não "representa" nada por si só, é um método para transferir dados usando OpenURL de uma forma estruturada. Não teríamos problemas para passar o blob matemático no exemplo de David para o receptor, o problema é que o receptor provavelmente não será capaz de entender isso e, em vez disso, apenas deixar cair sobre eles o que para eles é apenas um bolha de dados binários estranhos, inserimos um espaço reservado esperando que pelo menos o restante do título seja útil o suficiente para que o receptor o compreenda.
Não conheço outro padrão de metadados que tenha uma solução confiável para esse problema. Você é?
Com relação à entrada de índice que você mencionou, como uma obra como a do exemplo de David seria representada em seus bancos de dados de classificação? A questão é com relação à aparência visual e também como ela está codificada ali. Isso é algo que pode ser derivado do título adequado ou é um título descritivo?
- Matthiaspaul ( talk ) 00:53, 12 de setembro 2021 (UTC)[]
Como foi observado acima por David sobre COinS ou quaisquer metadados, isso é olhar para o problema do lado errado. A representação de metadados de qualquer tipo (vamos esquecer os problemas subjacentes com OpenURL por enquanto) é secundária. Trata-se de apresentar dados (para o leitor humano). Bancos de dados de referência, incluindo bancos de dados especializados de trabalhos matemáticos, constroem seus índices usando dados inseridos conforme aparecem no próprio trabalho, a menos que o banco de dados de referência / classificação tenha estranhas peculiaridades de entrada de dados. As citações devem passar os dados do índice "como estão", porque essa é a maneira mais fácil de encontrar a fonte subjacente, com muito, muito poucas exceções. É simples assim. Se Unicode, COinS ou qualquer outra coisa não puderem lidar com isso, então eles devem ir embora. 98.0.246.242 ( conversa) 13:52, 12 de setembro de 2021 (UTC)[]
Matthiaspaul: A lista em https://publi.math.unideb.hu/searchb.php mostra este artigo como "210 = 14 × 15 = 5 × 6 × 7 = {21 2} = {10 4}". Esse link clicável leva a https://publi.math.unideb.hu/load_jpg.php?p=391 que exibe um JPEG. - Michael Bednarek ( conversa ) 14:00, 12 de setembro de 2021 (UTC)[]
Obrigado, Michael, isso foi útil. Mas precisamos de mais exemplos desse tipo, também outros mais complicados para derivar padrões a partir dele. - Matthiaspaul ( talk ) 20:18, 12 de setembro de 2021 (UTC)[]
A falha de outros sites em exibir títulos de referência adequadamente não deve ser uma desculpa para falharmos na mesma coisa. O link pdf desse site para o artigo real mostra como ele deve ser formatado. - David Eppstein ( talk ) 21:48, 12 de setembro de 2021 (UTC)[]
Parece que fui mal interpretado pelo IP e por David. Nunca disse isso, muito pelo contrário - não procuro desculpas, mas sim soluções.
Mas desligar o COinS, como foi sugerido, não é uma boa ideia, pois ainda transmite informações úteis. No pior caso, apenas os dados ofensivos devem ser silenciados - e basicamente é isso que fazemos agora com nosso espaço reservado "MATH + RENDER + ERROR" (embora devamos tentar fazer melhor).
Um PDF, como sugerido, também não adianta, é apenas um binário e não muito diferente de passar por cima de uma foto do título do livro impresso ou imagem gráfica de nossa renderização local. Por um lado, não podemos presumir que uma imagem ou PDF possa ser visualizado no receptor, mas também não pode ser usado para pesquisas. O que precisamos é de alguma notação de fórmula legível por máquina e humana codificada como texto para que um padrão de pesquisa possa ser derivado dele. É por isso que eu estava perguntando o que outros produtores de COinS estão transmitindo nesses casos e como esses títulos de trabalho são armazenados na entrada de título (texto) de bancos de dados externos.
- Matthiaspaul ( talk ) 16:37, 15 de setembro de 2021 (UTC)[]

Duas coisas. 1) Sem caracteres Unicode. Esses são uma praga e devem ser eliminados à vista. 2) Leitores e processamento preciso de informações são a prioridade. Se as moedas não podem lidar com algo, estrague as moedas. Se o codefu mágico pode ser feito para converter algo não compatível com COinS em algo compatível com COinS nos bastidores (por exemplo, ''H''<sub>x</sub>20<sup>6</sup>H_{x}20^{6}ou qualquer que seja o padrão COinS), ótimo, mas não deve exigir que os editores sacrifiquem a renderização precisa. Headbomb { t · c · p · b } 14:51, 12 de setembro de 2021 (UTC)[]

Algumas considerações e uma pergunta:

  • Presumo que, devido à aplicação geral de MOS: CONFORM a citações (não apenas citações), geralmente já alteramos a pontuação e outros caracteres especiais para se adequar ao estilo da Wikipedia, em vez de deixá-los exatamente como no material de origem. Principalmente, trata-se de usar aspas retas. Um caso mais exótico é quando alguém tweeta em negrito todo o quadro negro - que é renderizado como todas as letras maiúsculas na citação da Wikipedia.
  • Quando estou limpando caracteres especiais em citações, geralmente encontro um título corrompido no documento que citamos, seja devido a mojibakeou algum outro manuseio incorreto. Eu sempre corrijo isso para que um humano que leia a Wikipedia com seus olhos possa ver o título verdadeiro, mas se eles estiverem pesquisando em certos bancos de dados, eles podem não encontrar esse título literalmente. Portanto, embora eu goste da ideia de "copiar exatamente para que as pessoas possam encontrar o original" em teoria, na prática estamos agregando vários bancos de dados diferentes, que podem ter representações incompatíveis e, em alguns casos, quebradas. A alternativa é "usar uma representação consistente na Wikipedia" e se nossa representação for sensata, esperamos que outros bancos de dados usem a mesma ou pelo menos sejam capazes de normalizar nossa representação para a deles ao pesquisar (para não mencionar sites que pesquisam a Wikipedia). Na pior das hipóteses, deve ser possível encontrar o texto completo de um artigo de periódico sem o título como parâmetro de pesquisa usando o periódico,autor e data, embora isso claramente não seja o ideal.
  • O que a Wikipedia produz para COinS pode de fato afetar o formato padrão aceito (e se o COinS se torna popular ou não), uma vez que parece não haver um padrão formal para questões de marcação e somos um grande site e poucos sites o usam. Também poderíamos olhar para os outros sites listados em COinS e ver como eles lidam com caracteres especiais.
  • Para artigos de ciência e matemática, MOS: FRAC diz que podemos usar {{ sfrac }} ou frações ASCII como "1/2". Para artigos gerais, devemos usar apenas {{ frac }}. Portanto, se estivermos usando a abordagem MOS: CONFORM , o resultado desejado é alterar o MOS: FRAC para aconselhar o uso apenas de frações ASCII nas citações, para todos os tipos de artigos? (A menos que seja parte de uma fórmula matemática mais complicada, é claro.) Ou devemos usar, por exemplo, <sup> 1 </sup> / <sub> 2 </sub> para aproximar {{ frac }} às custas da produção de COinS poluentes com marcação HTML?

- Beland ( talk ) 17:29, 12 de setembro de 2021 (UTC)[]

Devemos citar as fórmulas nas referências da maneira como a referência as formatou, mesmo quando nossas diretrizes de estilo nos dizem para usar um estilo diferente para a fórmula com o mesmo significado em nosso próprio texto. Assim, por exemplo, seria correto citar: Bandukwala, J .; Shay, D. (fevereiro de 1974). "Teoria dos táquions livres de spin ½". Physical Review D . 9 (4): 889–895. doi : 10.1103 / physrevd.9.889 .Usei o Unicode ½ aqui, mas acho que seria melhor usar {{frac | 1 | 2}} 12 e que a falha do nosso modelo em permitir isso é um bug: Bandukwala, J .; Shay, D. (fevereiro de 1974). "Teoria do spin- 12 tachyons livre". Physical Review D . 9 (4): 889–895. doi : 10.1103 / physrevd.9.889 . templatestyles stripmarker em |title=na posição 22 ( ajuda ) - David Eppstein ( talk ) 18:57, 12 de setembro 2021 (UTC)[]
Os dados de COinS para este título incluem um marcador (que não faz sentido passar adiante, por isso o aviso):
&rft.atitle=Theory+of+free%2C+spin-%7F%27%22%60UNIQ--templatestyles-0000001B-QINU%60%22%27%7F%3Cspan+class%3D%22frac%22+role%3D%22math%22%3E%3Cspan+class%3D%22num%22%3E1%3C%2Fspan%3E%26frasl%3B%3Cspan+class%3D%22den%22%3E2%3C%2Fspan%3E%3C%2Fspan%3E+tachyons
Poderíamos retirar o marcador de texto e passar o HTML restante. Decodificado, isso resultaria na seguinte string:
Theory of free, spin-<span class="frac" role="math"><span class="num">1</span>⁄<span class="den">2</span></span> tachyons
que renderiza (quase) bem como:
Teoria do spin livre, 12 taquions
mas apenas se pudermos assumir um mecanismo de renderização de HTML no final do receptor (o que não podemos, infelizmente).
Remover automaticamente os atributos daria a este HTML uma aparência muito mais limpa:
Theory of free, spin-<span><span>1</span>⁄<span>2</span></span> tachyons
ou, neste caso fácil, mesmo:
Theory of free, spin-1⁄2 tachyons
para:
Teoria do spin livre, 12 taquions
Certamente é melhor passar isso do que silenciar os metadados completamente, mas essa obviamente também não é uma boa solução funcionando em todos os casos.
Presumivelmente, o código já extrai texto útil para metadados COinS de alguns marcadores matemáticos específicos (o alt=atributo com PNGs, texto simples com TeX ou o conteúdo de <annotation>elementos com MathML), mas isso obviamente não cobre todos os casos. Pode valer a pena tentar melhorar ainda mais, mas provavelmente também precisamos de um |descriptive-title=para permitir que os editores especifiquem o que deve ser transmitido como metadados.
- Matthiaspaul ( talk ) 20:18, 12 de setembro de 2021 (UTC)[]
Se você pensa que a "Teoria do free, spin- 12 tachyons" renderiza "quase bem", você deve estar usando uma configuração de navegador muito diferente da minha, onde o 2 é enorme e substituído pelo /. Além disso, não devemos reescrever as referências para fazê-las caber em moedas; a única coisa que deve ser reescrita é o que aparece nos metadados COINS. Quanto a "texto simples com TeX": não. O que você obtém com a implementação atual do TeX é "MATH + RENDER + ERROR" nos metadados COINS. - David Eppstein ( talk ) 21:44, 12 de setembro 2021 (UTC)[]
Well, that's why I wrote "almost". ;-) Basically, we are in agreement here. What's important here is that it carries over the semantic information, not that it looks pretty. Our CSS definitions are not available at the receiver's end (and shouldn't), that's why my example looks a bit distorted. But there will always be differences in the output of different rendering engines. It would matter if this would be used for our local display of citations (where we should not compromise on the quality of its appearance), but it does not really matter for metadata purposes. What we need is not a particularly nice visual representation of the metadata, but an accurate semantic description of the math.
--Matthiaspaul (talk) 16:37, 15 September 2021 (UTC)[]
Previous discussion: Help talk:Citation Style 1/Archive 19 § math ml rendering changes and metadata
It used to be that we could extract the content of a math stripmarker and from that content extract a more-or-less human-readable copy of an equation that we could put into the metadata. What was in the math stripmarker depended on the math preferences setting of the editor who last saved the article. Here is what we used to get for this equation example:
<math display=inline>210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}</math>
for the various math preferences settings:
MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools)
<span class="mwe-math-element"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}">
  <semantics>
    <mrow class="MJX-TeXAtom-ORD">
      <mstyle displaystyle="false" scriptlevel="0">
        <mn>210</mn>
        <mo>=</mo>
        <mn>14</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>15</mn>
        <mo>=</mo>
        <mn>5</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>6</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>7</mn>
        <mo>=</mo>
        <mrow class="MJX-TeXAtom-ORD">
          <mrow>
            <mrow class="MJX-TeXAtom-OPEN">
              <mo maxsize="1.2em" minsize="1.2em">(</mo>
            </mrow>
            <mfrac linethickness="0">
              <mn>21</mn>
              <mn>2</mn>
            </mfrac>
            <mrow class="MJX-TeXAtom-CLOSE">
              <mo maxsize="1.2em" minsize="1.2em">)</mo>
            </mrow>
          </mrow>
        </mrow>
        <mo>=</mo>
        <mrow class="MJX-TeXAtom-ORD">
          <mrow>
            <mrow class="MJX-TeXAtom-OPEN">
              <mo maxsize="1.2em" minsize="1.2em">(</mo>
            </mrow>
            <mfrac linethickness="0">
              <mn>10</mn>
              <mn>4</mn>
            </mfrac>
            <mrow class="MJX-TeXAtom-CLOSE">
              <mo maxsize="1.2em" minsize="1.2em">)</mo>
            </mrow>
          </mrow>
        </mrow>
      </mstyle>
    </mrow>
    <annotation encoding="application/x-tex">{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}</annotation>
  </semantics>
</math></span><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/4012a8a0261dae95c0a7443dbf67dcb58800df0c" class="mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -1.005ex; width:40.087ex; height:3.343ex;" alt="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}"/>
LaTeX source (for text browsers):
<span class="mwe-math-fallback-source-inline tex" dir="ltr">$ {\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}} $</span>
PNG images:
<img src="https://wikimedia.org/api/rest_v1/media/math/render/png/4012a8a0261dae95c0a7443dbf67dcb58800df0c" class="mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -1.005ex; width:40.087ex; height:3.343ex;" alt="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}" />
For PNG we took the content of the alt= attribute; for LaTeX we took everything between the paired $...$; for MathML we took the content of the <annotation>...</annotation> tag.
And then, suddenly, that ability was taken away from us; see the Phabrication link. Because a math stripmarker is wholly and completely meaningless to anyone consuming a cs1|2 citation via the metadata, I replaced the stripmarker with the text: MATH+RENDER+ERROR. Except for that, all of the rest of the metadata are correct:
<span ...>...
&rft.genre=article
&rft.jtitle=Publicationes+Mathematicae+Debrecen
&rft.atitle=MATH+RENDER+ERROR
&rft.volume=51
&rft.issue=1%E2%80%932
&rft.pages=175-189
&rft.date=1997
&rft_id=%2F%2Fwww.ams.org%2Fmathscinet-getitem%3Fmr%3D1468225%23id-name%3DMR
&rft.aulast=Pint%C3%A9r
&rft.aufirst=%C3%81kos
&rft.au=de+Weger%2C+Benjamin+M.+M.
</span>
so readers consuming the citation via the metadata are likely to be able to locate the source (especially if the title has more to it than an equation). Despite this 'fix', what actually ends up in &rft.atitle= is dependent on the preference settings of the editor who last saved the article:
PNG:
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E%7B%5Cdisplaystyle+210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D%7B%5Cbinom+%7B21%7D%7B2%7D%7D%3D%7B%5Cbinom+%7B10%7D%7B4%7D%7D%7D%3C%2Fspan%3E
LaTeX:
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D%7B%5Cbinom+%7B21%7D%7B2%7D%7D%3D%7B%5Cbinom+%7B10%7D%7B4%7D%7D%3C%2Fspan%3E
MathML
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3EMATH+RENDER+ERROR%3C%2Fspan%3E
I think that this behavior is new since the last time that I looked at this issue because I seem to recall that all three cases put MATH+RENDER+ERROR in the metadata. Alas, we cannot force editors to use PNG or LaTeX rendering, nor can we force MediaWiki to give us back the ability to extract content from math stripmarkers.
The only way that I can think of to include math markup in |title= is to have an alternate |math-title= or some such that requires some sort of special-secret-markup that is not <math>...</math> tags to wrap whatever would normally be in <math>...</math> tags so, for example:
|math-title=A title with some text and $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$ and yet more text
The module would then make a copy of the value assigned to |math-title= and then remove the special-secret-markup and put the result into the metadata. Then, the module would replace the special-secret-markup with actual opening and closing <math>...</math> tags, and then preprocess a special template that renders the math title. That rendering then goes into |title=. Yeah, pretty ugly, and I have no idea if it would work.
This search finds about 650 articles that contain |title= with a <math> tag (not all |title= parameters are associated with cs1|2).
Trappist the monk (talk) 23:19, 12 September 2021 (UTC)[]
Very simple proof of concept. I have hacked a sandbox module. It takes a string of text as single parameter |math-title= that may, or may not, have $ delimited math text. If it finds a matched pair of $ delimiters, it replaces the delimiters with <math display=inline> and </math> and then preprocesses that string to get a math rendering that can be used in the citation's title:
{{#invoke:Sandbox/trappist_the_monk/math|math-title|math-title=$210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$}}
math title: ; metadata: $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$
The raw value from |math-title= might be used in the metadata as-is because the $ delimiters are 'native' to LaTex / TeX.
To be done: support for escaped \$ (literal '$' appearing in math text), support for '$' appearing in plain text that is not math text – for |math-title=, requiring editors to escape '$' when it appears in text that is not math text seems a reasonable restriction for this parameter. No doubt there is other stuff to do with this hack before we consider implementing it in the cs1|2 module suite.
Trappist the monk (talk) 16:24, 14 September 2021 (UTC)[]
I like your approach to grab the data before MediaWiki gets it by playing man in the middle. This is brilliant. I didn't know that such a pre-processing of the formula would be possible. We should definitely try to further build on this.
But: Even if we are able to pass on a perfectly workable string as metadata, we still cannot be sure that it can be correctly interpreted at the receiver's end, so it is good to have this, but we still need a more general solution to cover other cases as well.
Since publishers of works containing formulas or other "visually complex stuff" in their titles will have to pass some textual representation of such titles to customers it is quite likely that some publisher-provided text-only alternative titles are already stored and established as standard alternative titles in external databases. In some cases, they might even be known by our contributing editors, so it would be useful if they could be entered as alternative text titles into our citations without having to give up on the nice "presentation" titles in |title= for our local purposes.
David's |text-title= and my |descriptive-title= are basically the same idea, except that in his, the contents of |text-title= would completely replace the contents of |title= for metadata purposes (similar to how your |math-title= would replace |title= for both, our local rendering as well as the metadata), whereas my |descriptive-title= could be used instead of a normal |title= (if not given), but could also be combined with |title= (when both are given). The contents of the descriptive title should be displayed without text decoration when rendered (not sure if in front or following the normal title if both exist), and should be put into [square-brackets] in metadata to indicate that this is not the original title (probably prefixing the normal title if both exist). The different representation styles would allow to tell them apart when both are displayed or combined into the single &rft.atitle= or &rft.btitle= COinS key.
I think, our ideas are similar enough to be combined so that |descriptive-title= would effectively become your |math-title= when it contains some $TeX$. (And for the rare case, where the $TeX$ stuff should not be interpreted in your suggested way, we have our ((accept-this-as-written)) syntax to indicate this.) This way, the editor would have the flexibility to provide either the |title= or the |descriptive-title= (including its special handling for math), or both.
This would also cover all cases for which we have discussed a need for something like a |descriptive-title= in the past, non existing titles, dynamic titles, visual or acoustical only titles, functional titles, alias titles, unrepresentable titles, because too long, in unsupported scripts, or misleading in our context...
In past discussions we have also established two more special cases: The case where no actual title exists and we want to indicate this by a standardized descriptive title (keyword "none" to display the localized "no title"), and the case where a title does exists, but should not be displayed for some reason (keyword "off"), for example in an article listing many revisions of a work), but where we would still want to issue the complete metadata for it. Last year, I started to implement this by introducing these keywords to |title=none/off, but realized we would still need something more like a |descriptive-title= parameter to specify the title for metadata.
We now have the chance to combine this and cover all these use cases with one new parameter.
--Matthiaspaul (talk) 16:37, 15 September 2021 (UTC)[]
Adding support for a |descriptive-title= is scope creep. What we are trying to solve is the display of math in titles. So we should limit it to such with a name that makes it obvious the purpose of that parameter. Izno (talk) 18:02, 15 September 2021 (UTC)[]
Perhaps it is scope creep in this particular thread, but not in general. Our whole discussion including Trappist's proposal is tangential to the original question raised by the OP, nevertheless the discussion was quite productive so far.
However, thinking about how to possibly combine open requirements when they are related is a good design approach. Many of the incoherences of the existing template design were caused by former ad hoc solutions to fix isolated problems. In the past years we were able to correct some of these bad design decisions to improve the interface but there are still weak spots and we also have a long list of still needed features which haven't been implemented yet because of lack of time or because it was felt that something was still missing to round out the design of a feature. Descriptive titles are among them - I had hoped that it would be possible to implement them without a need for a new parameter at all, but then we would have to introduce some special syntax to the normal |title=. It's still a possibility, but when we are now tinkering with the idea of introducing a dedidated |math-title=, it is important to also think about more general descriptive titles. After all, a title for a textual math representation is some kind of descriptive title. Otherwise, we easily end up with a whole new bunch of special title parameters, something, I think, we both want to avoid. Therefore, it is a valid question how to possibly combine this at least in the design, even if not all parts of the actual solution would be implemented at the same time.
--Matthiaspaul (talk) 22:17, 15 September 2021 (UTC)[]

Hmm, some sources when ASCIIfying article titles, appear to use TeX-like markup inside special markers like "##" or "$". Examples: [1] [2]. And here's an example of <em>...</em> where we'd probably want to use '', but I think the em tag gets emitted in the final HTML: [3]. -- Beland (talk) 23:49, 13 September 2021 (UTC)[]

I'm not sure that the following is a good idea, myself, but one possible way through this would be to add a |text-title= parameter to the template to use as the text version of the title, and simultaneously to allow templates like {{frac}} or {{nowrap}} or whatever in titles when a text-title is present. That wouldn't address the inability to extract meaningful text from <math> formulas, but I'm sure Citation bot could be persuaded to add text-titles for those. One reason it's a bad idea is that the parameter would only produce invisible markup and therefore there wouldn't be much incentive for editors to make it accurate. —David Eppstein (talk) 00:34, 14 September 2021 (UTC)[]
Templates inside a cs1|2 template are expanded before the cs1|2 template is expanded. So, what cs1|2 sees when an editor writes:
|title=A {{frac|1|2}} Title
is this:
A '"`UNIQ--templatestyles-00000081-QINU`"'<span class="frac" role="math"><span class="num">1</span>&frasl;<span class="den">2</span></span> Title
The templatestyles stripmarker refers to Template:Fraction/styles.css which is where class="frac", class="num", and class="den" are defined. None of that styling is available to readers who consume the citation through the metadata. Module:Citation/CS1 might remove the stripmarker, all class= attributes, and any <span>...</span> tags without attributes:
A <span role="math">1⁄2</span> Title
We might also strip other attributes, style= might be one, and remove other html tags.
This same mechanism, where the editors writes this:
|title={{nowrap|don't wrap this text}}
cs1|2 gets as this:
<span class="nowrap">don't wrap this text</span>
where the nowrap class is defined in MediaWiki:Common.css. cs1|2 would include this in the metadata:
don't wrap this text
If this is a workable solution and if the code that implements it doesn't take too much of the limited processor time, we will need a list of commonly used attributes and html tags that can be stripped from every parameter value that is made part of the metadata.
Trappist the monk (talk) 11:46, 14 September 2021 (UTC)[]
I suspect that the <em>...</em> is inappropriate use where <i>...</i> would have been a better choice. Apparently the $ is a standard part of LaTeX and TeX used to delimit the beginning and end of math text; using a standardized delimiter is always better than making up our own delimiters. I've changed my example above to use the $ delimiters.
Trappist the monk (talk) 11:46, 14 September 2021 (UTC)[]
To clarify, $ delimits in-line math text, which TeX renders in a smaller font size. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:48, 14 September 2021 (UTC)[]
Math text in a cs1|2 parameter that contributes to the citation's metadata is always inline math text so the $ delimiters are appropriate, right?
Trappist the monk (talk) 15:07, 14 September 2021 (UTC)[]
The math in reference titles should only be inline, yes. $ ... $ for inline math and $$ ... $$ for display math is old-school TeX markup. The modern alternative (better for being less ambiguous wrt actual dollar signs, and also with some technical advantages in actual TeX for making it easier to hang hooks in the code) is \( ... \) for inline math and \[ ... \] for display math. The Wikimedia developers have vetoed allowing these to be shortcuts for math markup in the Wikimedia codebase, but I suppose that doesn't prevent them from being used in templates that intercept them and convert them to <math display=inline> ... </math> and <math display=block> ... </math> respectively. Would this actually work? Can math tags in template output still be expanded, or is math tag expansion only done before the templates are expanded? If this could be done in the existing |title= parameter, I think that would be better than introducing a new multiplicity of confusing variations of title parameters. —David Eppstein (talk) 18:32, 15 September 2021 (UTC)[]
For the same reasons it was vetoed there, use in the general parameter I think is a bad idea. Izno (talk) 20:47, 15 September 2021 (UTC)[]
Perhaps you could articulate those reasons, and convince me that it isn't one of (1) we are deliberately sabotaging LaTeX-based math because we still want people to use MathML instead, or (2) we don't care about whether mathematics works on Wikipedia because it isn't an important enough subset of our use and we don't want to pay the ongoing development costs of keeping it working? Because neither of those reasons applies to mathematics formulas in citation titles. —David Eppstein (talk) 21:14, 15 September 2021 (UTC)[]
Because you don't know what might be citation titles that look like your preferred <math> tag replacements. Izno (talk) 21:24, 15 September 2021 (UTC)[]
That would be a valid reason to avoid $ ... $. It's not a valid reason to avoid \( ... \) because very few references use that syntax (very likely, zero references) and because if they do we can fall back to the format-as-typed escape codes already used elsewhere in the citation templates. —David Eppstein (talk) 22:09, 15 September 2021 (UTC)[]
(edit-conflict) Actually, if it would be possible to include the functionality of the proposed |math-title= (or whatever) into the normal |title=, as David suggests, this would be better from the user's perspective than to introduce a dedicated parameter for this. The question, however, is how conflictive such $TeX$ stuff would be within normal titles. If collisions would be rather rare, we still have our ((accept-this-as-written)) syntax to force the template to take the title verbatim (which is already supported by |title= to override the removal of end interpunctation).
If it can't be combined into the existing |title= parameter then the question is how at least text titles for math (which fall under the category of descriptive titles) can be combined with more general descriptive titles interfacewise, so that we eventually need only one new parameter rather than two for semantically close purposes.
Not thinking about this now at least conceptually is exactly what leads to incoherent interface design, something we should try to avoid.
--Matthiaspaul (talk) 22:22, 15 September 2021 (UTC)[]
ok, so here's a version of my test hack that uses the \( ... \) delimiters:
{{#invoke:Sandbox/trappist_the_monk/math|math_test2|math-title=Entropy-Based Uncertainty Measures for \(L^2(\mathbb{R}^n),\ell^2(\mathbb{Z})\), and \(\ell^2(\mathbb{Z}/N\mathbb{Z})\) With a Hirschman Optimal Transform for \(\ell^2(\mathbb{Z}/N\mathbb{Z})\)}}
math title: Entropy-Based Uncertainty Measures for , and With a Hirschman Optimal Transform for ; metadata: Entropy-Based Uncertainty Measures for \(L^2(\mathbb{R}^n),\ell^2(\mathbb{Z})\), and \(\ell^2(\mathbb{Z}/N\mathbb{Z})\) With a Hirschman Optimal Transform for \(\ell^2(\mathbb{Z}/N\mathbb{Z})\)
That's a real title I found somewhere (except that in its current guise it uses <math>...</math> tags).
<math>...</math> tags in parameter values are expanded into math stripmarkers before cs1|2 gets parameter values. After cs1|2 has rendered the citation, MediaWiki replaces each math stripmarker with its associated expansion. Using $...$ or \( ... \) instead of <math>...</math> tags allows us to apply <math>...</math> tags and then expand them into math stripmarkers (to be replaced by MediaWiki after cs1|2 final rendering) at the time of our choosing.
The only reasons that I can think of to not support this directly in |title= is that we have to inspect every |title= value for the \( ... \) delimiters and it is possible that some title somewhere legitimately uses the TeX delimiters. Inspecting every |title= value is relatively inexpensive because all we have to look for is the opening \( delimiter so if Title:find ('\\%(') then ... end – attempt to convert delimiters to <math>...</math> tags only when a \( delimiter is present. I found only two instances of the opening \( delimiter; one is vandalism and the other a malformed title. It would not be so simple with the $...$ delimiters so if we proceed with this solution and choose to use $...$ delimiters, implementing |math-title= along-side |title= is the better choice.
Trappist the monk (talk) 21:54, 15 September 2021 (UTC)[]
I would be fine with \( ... \) to mark TeX blocks, for as long as our (( ... )) wrapping syntax would disable the feature.
--Matthiaspaul (talk) 22:46, 15 September 2021 (UTC)[]
\( ... \) TeX delimiters experiment moved to Module:Citation/CS1/sandbox. I have disabled the <math>...</math> 'allowance' so parameters with <math>...</math> tags will emit the stripmarker error:
{{Cite book/new |title=<math display="inline">3987^{12} + 4365^{12} = 4472^{12}</math>}}
. {{cite book}}: math stripmarker in |title= at position 1 (help)
math in a book title:
{{Cite book/new |title=\(3987^{12} + 4365^{12} = 4472^{12}\)}}
.
math in a book chapter:
{{Cite book/new |chapter=\(3987^{12} + 4365^{12} = 4472^{12}\) |title=Title}}
"". Title.
math in a journal title:
{{Cite journal/new |title=\(3987^{12} + 4365^{12} = 4472^{12}\) |journal=Journal}}
"". Journal.
math in a book title with accept-as-written markup:
{{cite book/new |title=((\(3987^{12} + 4365^{12} = 4472^{12}\)))}}
\(3987^{12} + 4365^{12} = 4472^{12}\).
math in a book title metadata:
'"`UNIQ--templatestyles-00000098-QINU`"'<cite class="citation book cs1">'''"`UNIQ--math-00000099-QINU`"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%5C%283987%5E%7B12%7D+%2B+4365%5E%7B12%7D+%3D+4472%5E%7B12%7D%5C%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
Trappist the monk (talk) 23:22, 16 September 2021 (UTC)[]
Disabling the default <math> formatting in references is (1) going to cause a huge number of errors with existing citations, and (2) going to cause enormous confusion with editors who don't understand why the mathematics delimiters should be different in this context than everywhere else. I think emitting an error message is the wrong way to go. Better would be to continue to allow the math stripmarkers, but to put them into a tracking category so that a bot or AWB can run around behind the scenes converting the delimiters. I think such conversion is going to continue to be needed on a slow but ongoing basis, rather than being a one-time thing that can be enforced as an error once a change is made. —David Eppstein (talk) 00:54, 17 September 2021 (UTC)[]
Of course, the error message help would explain the problem, and the article is also put into category Category:CS1_errors:_invisible_characters. The COinS metadata for the citation with the MATH+RENDER+ERROR is still issued just like before (after all, it's still possible that MediaWiki will be fixed somewhen in the future). I think that's exactly how it should be, but an alternative would be to change the error message into a warning.
--Matthiaspaul (talk) 01:17, 17 September 2021 (UTC)[]
We don't have any warning messages. If this change is accepted, I expect to remove the parts of Module:Citation/CS1/COinS that decoded the math stripmarker content – it won't be needed.
Trappist the monk (talk) 01:24, 17 September 2021 (UTC)[]
For some unknown reason I often call our maintenance messages "warnings" - probably have worked with systems which could issue warnings and errors rather than maintenance and error messages... ;-)
Removing the code that decoded the math stripmarker contents, this would not affect the code for SVG and LaTeX math extraction, only for MathML, right?
Brings up the question if we should normalize the slightly different output from the SVG, LaTeX and now MathML via \( ... \) extraction methods, because, from a COinS consumer's perspective, that's our internal business and should always give identical output, shouldn't it?
--Matthiaspaul (talk) 19:10, 17 September 2021 (UTC)[]
If we keep this proposed solution, all of the code that decoded the math stripmarker contents should go away because we won't need to extract anything from SVG, LaTeX, or MathML, whichever of those the last publishing editor had selected for math rendering – everything we need is right there in the parameter value.
Trappist the monk (talk) 20:00, 17 September 2021 (UTC)[]
But this holds true only for new edits, what about the old ones? And what if some editors continue to use the SVG or LaTeX methods, should we prompt them with an error message and force them to rewrite the citation using \( ... \) although their edits did not actually cause us problems?
We should definitely keep the new solution, it's great. I'm just not sure the old handling should be removed (at least not until the new markup is fully established)...
--Matthiaspaul (talk) 22:03, 17 September 2021 (UTC)[]
I get the impression that you do not understand how the old mechanism works. When I edit an article that just happens to have a cs1|2 template with <math>...</math> markup in a |title= parameter, and then publish that article, the live cs1|2 module will create the metadata string for that citation (coins_replace_math_stripmarker()) using the math settings in my preferences because MediaWiki renders that math image into a stripmarker before cs1|2 gets the content of |title=. Since the stripmarker was created using my settings, the metadata will be derived from my settings. The resulting metadata are then cached for everyone until some other editor saves the article and their math preference setting is different from mine.
The cached metadata will remain as is until something causes MediaWiki to refresh the article. If/when the proposed \( ... \) TeX delimiters are introduced, as noted elsewhere in this discussion, an awb or some such script will be required to replace the <math>...</math> markup which will cause an article refresh and so new metadata using the \( ... \) TeX delimited wikitext straight from the appropriate parameter. Because we feed the metadata directly from the \( ... \) TeX delimited wikitext, there is no need (and no ability to) decode a math stripmarker so the code that decoded the math stripmarker content (even if it still worked) will no longer be need so should be removed. If we ever need it, we can always get it back from a previous version of the module.
Trappist the monk (talk) 01:13, 18 September 2021 (UTC)[]
Thanks, Trappist. I think I understood the mechanism well, but its always good to get reconfirmation by reading your explanation. What I did not understood was that you really meant a refresh run to be a mandantory part of the introduction process, instead I thought we'd leave that as optional (if some volunteer cares enough to do it) and otherwise the articles would remain with their old cached data until someone happens to edit them (which could take weeks, months, years).
I guess, there will still be editors who continue to use the <math>...</math> markup at least for a while and it would have been convenient for them if they could continue to use it for entries which either do not contribute to the metadata, or to entries contributing to metadata, if they have selected SVG or LaTeX, not MathML. However, this would put the burden to switch to \( ... \) on the next editor with MathML settings and would also leave the citation source code in a mix of markups, which might not be desirable for other parties which read our wikitext rather than metadata, so yes, I agree, a hard switch is probably the better approach here.
--Matthiaspaul (talk) 09:48, 20 September 2021 (UTC)[]
I don't know that a huge number of errors with existing citations is an accurate description. If these search results are to be believed, there are:
~650 articles that have <math>...</math> tags in |title=
~25 articles that have <math>...</math> tags in |chapter=
I think that editors will learn quickly enough about the change in markup if they can see an error message that has a link to an explanation; maintenance category messaging is hidden from all editors who have not chosen to show those messages.
If we are to keep this change it isn't difficult to write an awb script that will change the <math>...</math> tags to \( ... \) TeX delimiters. That script can be run on the same day that the change goes live (if it goes live) and be done after a couple of hours.
Trappist the monk (talk) 01:24, 17 September 2021 (UTC)[]
This should also work for the title- and chapter-related |script-= parameters which become part of the metadata. Are there other parameters ending up in metadata where math-like constructs could show up occasionally? What about the journal name, work, author etc. names and publisher entries?
And what shall we do with other parameters which definitely might contain math, but are not part of metadata like the corresponding |trans-= parameters, and |quote=, |script-quote= and |trans-quote=. Should we support the \(...\) syntax there as well as an alternative for syntax compatibility/consistency, or should we insist on <math> there?
--Matthiaspaul (talk) 19:10, 17 September 2021 (UTC)[]
If we keep this proposed solution, certainly all of the 'title-holding' parameters and the quotation parameters should support \( ... \) TeX delimiters for math markup. |journal=? |work=? |publisher=? |author=? I don't think so; at least not until a need has been sufficiently demonstrated. Quick searches for <math>...</math> tags in those parameters either timed out with no results or returned no results. We should only support one form of math markup.
Trappist the monk (talk) 20:00, 17 September 2021 (UTC)[]

Guidance for science etc.

Given the new proposed solution for <math>...</math> markup and the above comments, I'm wondering where we've come down on how to handle simple markup. I see contradictions between editors like "No unicode characters. Those are a blight, and should be purged on sight." vs. "exactly as the source information presents it, 'funny' characters and all". David Eppstein said titles should be formatted "the way the reference formatted it, even when our style guidelines would tell us to use a different style", but then used {{frac}} instead of ½. Our style guide says to use {{sfrac}} for science articles, so that seems to satisfy neither the goal of looking consistent with the style of body text nor the goal of being exactly the same as the original document for ease of search.

What are we proposing as the solution for simple markup, like a chemical formula? If we're following the sources exactly, we might use no-markup Unicode vs. <sup>...</sup> depending on what the original document does, though if it's on paper or PDF it will be impossible to tell. If we're avoiding Unicode compatibility characters, then we still have at least three choices:

  • Something about H
    2
    O
    2
    .
    - {{chem2|H2O2}} - Copy-paste: Something about H 2O 2
  • Something about . - \(H_2 O_2\) - Copy-paste: Something about H 2 O 2 {\textstyle H_{2}O_{2}} {\textstyle H_{2}O_{2}}
  • Something about H2O2. - H<sub>2</sub>O<sub>2</sub> - Copy-paste: Something about H2O2
  • Something about H₂O₂. - Unicode subscripts - Copy-paste: Something about H₂O₂

Though it's unclear to me how well any database or web search engine is going to handle the difference between say, "H2O2" as a search parameter and an internally stored "H<sub>2</sub>O<sub>2</sub>". -- Beland (talk) 17:19, 18 September 2021 (UTC)[]

Certainly not {{chem2}}; your example renders this mishmash:
<span class="chemf nowrap">H<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span>O<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span></span>
The copypasta is not as you have shown it but actually like this because the markup includes <br /> tags:
Something about H
2O
2.
Most cs1|2 templates appear in reflists which reduce text size to 90% so a font size of 70% (already smaller than allowed for accessibility; see MOS:SMALL) is just harder to read.
Also, certainly not Unicode subscripts because the already-hard-to-read Unicode subscript characters are harder-to-read when made smaller in reflists.
Trappist the monk (talk) 21:50, 18 September 2021 (UTC)[]
OK, that leaves the TeX-like syntax and HTML sup/sub tags. The Tex-like solution isn't ready yet, and presumably the COinS citation code could process simple <sub>...</sub> tags and friends cleanly? A rule like "use HTML sup/sub tags instead of Unicode subscripts and superscripts" would be easy to follow and easy to enforce, so I'm thinking maybe do that for now?
What about fractions like movie reviews of Naked Gun 33⅓: The Final Insult? Is it OK to use {{frac}} and {{sfrac}}? -- Beland (talk) 03:29, 20 September 2021 (UTC)[]
I discussed {{frac}} above at my 11:46, 14 September 2021 post.
Templates inside cs1|2 parameter values are expanded before cs1|2 gets the value so when an editor writes:
|title=Naked Gun 33{{sfrac|1|3}}
cs1|2 gets:
|title=Naked Gun 33'"`UNIQ--templatestyles-000000AC-QINU`"'<span role="math" class="sfrac tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">3</span></span>
The templatestyles stripmarker refers to Template:Sfrac/styles.css which defines the classes: sfrac, tion, num, den, and sr-only. As with {{frac}}, none of that styling is available to readers who consume the citation through the metadata so for them, the markup is just meaningless clutter.
Trappist the monk (talk) 13:33, 20 September 2021 (UTC)[]
Not sure where the above discussion landed, exactly. It seems we could either put in code to strip that stuff out, or we could make a clean template. How about a {{citefrac}} that just does 12 (<sup>1</sup>&frasl;<sub>2</sub>)? If we decide later that COinS conventions have shifted and Unicode fractions are preferred, we can simply change that template rather than all the articles that use it. Actually, if we do universally adopt some sort of Tex-like syntax, having {{citefrac}} would also make it easy to switch over to that, too.-- Beland (talk) 01:00, 23 September 2021 (UTC)[]
Trappist and I suggested that we could attempt to filter/cleanup/simplify the HTML before we create the title metadata. Removing anything CSS-related, unnecessary attributes, empty elements, etc. This would not be a solution for complicated HTML, but would allow to have at least simple HTML markup in the title.
In addition to "simplified HTML" and the \( ... \) solution for math, I continue to maintain that we need something like an optional |descriptive-title= (or |text-title= per David) as a fallback, so that editors can use fancy stuff in |title= for pretty local display purposes (without compromising for COinS), while still being able to exactly match a title, if known, as it may be used in an external database (regardless of what representation or transliteration may be used there) so that it can be used as search pattern there as well.
--Matthiaspaul (talk) 08:42, 23 September 2021 (UTC)[]
A filter/cleanup/simplify solution may not be sufficient. In my sandbox I've hacked some code that removes:
  • stripmarkers
  • <br /> tags (used in {{chem2}})
  • class= attributes from <span> tags
  • style= attributes from <span> tags
  • title= attributes from <span> tags
  • extraneous whitespace
  • <span> without attributes and its matching </span>
For the simple cases:
Naked Gun 33{{code|{{sfrac|1|3}}}}
Naked Gun 33'"`UNIQ--syntaxhighlight-000000B3-QINU`"'
Naked Gun 331/3
we get:
{{#invoke:Sandbox/trappist_the_monk/math|span_test|1=Naked Gun 33{{sfrac|1|3}}}}
Naked Gun 33<span role="math">1/3</span>
Naked Gun 331/3
but for complex cases:
{{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}}
<span class="chemf nowrap">[{(η<sup>5</sup>-C<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />5</span>Me<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />4</span>)SiMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span>(η<sup>1</sup>-NCMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>)}(PMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>)Sc(μ<sub>2</sub>-H)]<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span></span>
[{(η5-C
5
Me
4
)SiMe
2
1-NCMe
3
)}(PMe
3
)Sc(μ2-H)]
2
we get:
{{#invoke:Sandbox/trappist_the_monk/math|span_test|1={{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}}}}
[{(η<sup>5</sup>-C5Me4)SiMe2(η<sup>1</sup>-NCMe3)}(PMe3)Sc(μ<sub>2</sub>-H)]2
[{(η5-C5Me4)SiMe2(η1-NCMe3)}(PMe3)Sc(μ2-H)]2
Maybe that's good enough, I don't know, but is this good enough?
{{chem2|C2H3O2(-)}}
<span class="chemf nowrap">C<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span>H<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>O<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;">−<br />2</span></span>
C
2
H
3
O
2
and stripped of markup:
{{#invoke:Sandbox/trappist_the_monk/math|span_test|1={{chem2|C2H3O2(-)}}}}
C2H3O−2
C2H3O−2
Trappist the monk (talk) 14:05, 23 September 2021 (UTC)[]
Not sure if this would be reasonably safe for the general case, but in the examples above the result could be further improved if we would insert a &thinsp; when a <span role="math"> gets eliminated, and when the text before and after a <span>x<br/>y</span> to be eliminated would be framed in <sub>y</sub> and <sup>x</sup> (perhaps only if inside a class="chemf"?).
--Matthiaspaul (talk) 20:13, 23 September 2021 (UTC)[]
I've been thinking about your {{chem2|C2H3O2(-)}} example a bit, and ideally, the stripped markup in that example should look just like the input. The the "2" subscript should bind closer to the "O" than the "-" charge.  — sbb (talk) 01:22, 24 September 2021 (UTC)[]
I'm sure this could be further improved, but I've hacked a "CS1/CS2-compatible" version of {{chem2/sandbox}} [4], which creates hidden metadata reproducing the input, see modified chem2 (this isn't the best possible metadata that could be created, but it was trivial to implement for our illustration purposes here). This is similar to how metadata is embedded into SVG and LaTeX math (which the current implemention of CS1/CS2 can extract already). CS1/CS2 templates could be easily made aware of this extension, so they could extract this data as well and use it for their metadata. This way, templates like {{chem2}}, which produce really difficult output for the HTML simplifier, could actively assist CS1/CS2 in their metadata creation. Over time, more templates could be enhanced this way and thereby be made "CS1/CS2-compatible".
--Matthiaspaul (talk) 10:01, 25 September 2021 (UTC)[]
If this is to be adopted and used by cs1|2, it would probably be best to not anchor-encode the {{chem2/sandbox}} input. Why anchor encoding? Before cs1|2 parameter values are added to the metadata, they are percent-encoded so, in its present form, what the metadata will get is:
&#91;Cl4Re\qReCl4&#93;(2−){{chem2/sandbox|[Cl4Re\qReCl4](2−)}} – anchor encoding
%26%2391%3BCl4ReqReCl4%26%2393%3B%282%E2%88%92%29 – percent encoding of the anchor-encoded input
when the metadata should get:
%5BCl4ReqReCl4%5D%282%E2%88%92%29 ← [Cl4Re\qReCl4](2−) – percent encoding
But, that's not wholly correct because the \q is treated as an escaped q so the result is missing the \ (%5C). This particular {{chem2}} input needs to be tweaked to escape the back slash:
%5BCl4Re%5CqReCl4%5D%282%E2%88%92%29 ← [Cl4Re\\qReCl4](2−) – percent encoding
And, I gotta wonder, are the input symbols that {{chem2}} accepts standardized so that consumers of the metadata will know what they mean when the metadata are decoded? If not then those symbols need to be replaced with the actual thing that they represent, don't they?
Trappist the monk (talk) 12:09, 25 September 2021 (UTC)[]
Yeah, this is still a demo for illustration purposes. Anchor-encoding isn't optimal here (but was handy for the quick demo). We might switch to a more suitable encoding. Either case, the extractor would have to decode it back before further processing, otherwise we would get the overencoded results as illustrated by you above. The encoding would have to ensure that no spaces remain in the string. " would be a forbidden character as well. IIRC, the allowed charset for class names is (or was) limited in some HTML versions (would have to look this up), so we would have to make sure to not use other reserved characters as well.
(Also, I think, the scheme could be further improved if we would not only embed the desired metadata output (i.e. MeTaDaTa-OuTpUt:), but optionally also the (parameter) input (i.e. MeTaDaTa-InPuT:). This might allow the extractor not only to replace the complete output of a template by its metadata (as in the current {{chem2}} example) but allow metadata fragments to be inherited from internally called templates instead of having to handle everything monolithically on the level of the outer template (example: {{chem}}, which internally uses {{su}} - still thinking about the details...)
are the input symbols that {{chem2}} accepts standardized so that consumers of the metadata will know what they mean when the metadata are decoded? I guess, this very much depends on the template, so even if this would be a standard notation in this particular case (I don't know if it is), it probably won't be in the general case. However, this is still a demo with the main purpose to illustrate how easy it would be to enhance templates in general. In a proper implementation, {{chem2}} would probably not just forward its own input as metadata, but actually generate the metadata by processing the input (like it does for its normal output, but) in a form which would be text-only or use only very simple markup. What can be considered to be the best metadata very much depends on the purpose/function of the template. The advantage of this approach would be that the developers or users of the template probably know best what is the optimal text-only metadata that can be generated from the input (developers would program the template to generate the optimal metadata for the context the template is used in, and users would always be able to override it using the |metadata= parameter), whereas the generic HTML simplifier in CS1/CS2 has no knowledge on the context and semantics and can only simplify based on universal structural rules.
--Matthiaspaul (talk) 13:53, 25 September 2021 (UTC) (updated 09:33, 26 September 2021 (UTC))[]
I've meanwhile simplified the magic and changed the encoding from anchor-encoding (which was shorter and more human-readable, but also combined various different space characters into one type and therefore was not fully reversible) to a combination of text-decoding (to level the playing-field also for input containing HTML entities) and percent-encoding (for transparent transportation of the metadata, in particular to encode the invalid space and quote characters). HTML 4 seems to have had more restrictions on the character set used in class names (including the percent-sign which is used by percent-encoding), but they have gone with HTML5 (they are still valid for CSS, but we don't use this "MeTaDaTa:" dummy-class for CSS purposes, so it doesn't affect us).
(BTW. mw.text.decode() has a bug as it properly processes &ThinSpace; but ignores &thinsp;. I have added a workaround at least to the wrapper: Module:DecodeEncode.decode.)
--Matthiaspaul (talk) 12:10, 26 September 2021 (UTC)[]
Also not a general solution out of the box, but one that could be used to make template output metadata-safe:
We could add code to critical templates like {{chem}} or {{chem2}} so that they issue their input in a HTML title= attribute. We could then use this instead of the actual HTML for metadata purposes (similar to what we do with math SVG and LaTeX extraction). Given that the HTML title= might be used by the template for other purposes already, and that it is also shown to users as tooltip (which might not be desirable if it contains stuff like "[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2"), I am using the title= attribute only for illustration purposes here and we might find another HTML attribute or establish a special "steganographic" notation where/how we could transparently hide those entries for possible extraction by CS1/CS2. Templates might even have a standardized optional parameter like |metadata= to override what the template would otherwise use for this. Templates enhanced this way could get a sticker like "CS1/CS2-compatible" or such. Sure, this would work only for those templates which have been enhanced this way, but all we would have to do now is to specify a standard for this and implement a generic extraction mechanism which would take over whenever CS1/CS2 finds this special HTML attribute/notation in a citation's title. Over the years more and more templates could be adapted accordingly.
--Matthiaspaul (talk) 12:19, 24 September 2021 (UTC)[]
To further illustrate this, this could be a span framing the normal template output of a template like {{chem2}} (following a similar idea as COinS, but for our internal purposes only):
<span class="MeTaDaTa::[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2">normal_template_output</span>
If our template metadata extractor would run into something like this (triggering on the "MeTaDaTa" magic), it would replace the whole span including normal_template_output (and, if present, also the corresponding stripmarker) by what follows the :: following the MeTaDaTa (which probably needs to be encoded in an actual implementation). For a template call like {{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}} this would result in [{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2. Would the template be called like {{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2|metadata=This is a text-only transcription of the chemical formula}} instead, it would result in This is a text-only transcription of the chemical formula. |metadata=off/none would disable the metadata (nothing would be following the "::" then). If the extractor does not find the triggering magic, or if the extracted data would be an empty string, it would proceed with the HTML simplification demoed above...
--Matthiaspaul (talk) 12:50, 24 September 2021 (UTC) (updated 09:33, 26 September 2021 (UTC), updated 18:40, 6 October 2021 (UTC))[]
This is how a CS1/CS2-compatibly modified {{frac}} template [5] could look like:
{{frac/sandbox|1|2|3}}
'"`UNIQ--templatestyles-000000CD-QINU`"'<span class="frac MeTaDaTa::%E2%80%891%C2%A02%2F3" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>
Visual rendering: 1+23
Extractable metadata: " 1 2/3"
{{frac/sandbox|1|2|3|metadata=Custom-Metadata}}
'"`UNIQ--templatestyles-000000D1-QINU`"'<span class="frac MeTaDaTa::Custom-Metadata" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>
Visual rendering: 1+23
Extractable metadata: "Custom-Metadata"
{{frac/sandbox|1|2|3|metadata=off}}
'"`UNIQ--templatestyles-000000D5-QINU`"'<span class="frac MeTaDaTa::" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>
Visual rendering: 1+23
Extractable metadata: "" so it will be ignored
Same for {{sfrac}} [6]:
{{sfrac/sandbox|1|2|3}}
'"`UNIQ--templatestyles-000000D9-QINU`"'<span role="math" class="sfrac MeTaDaTa::%E2%80%891%C2%A02%2F3 ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>
Visual rendering: 1+2/3
Extractable metadata: " 1 2/3"
{{sfrac/sandbox|1|2|3|metadata=Custom-Metadata}}
'"`UNIQ--templatestyles-000000DD-QINU`"'<span role="math" class="sfrac MeTaDaTa::Custom-Metadata ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>
Visual rendering: 1+2/3
Extractable metadata: "Custom-Metadata"
{{sfrac/sandbox|1|2|3|metadata=off}}
'"`UNIQ--templatestyles-000000E1-QINU`"'<span role="math" class="sfrac MeTaDaTa:: ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>
Visual rendering: 1+2/3
Extractable metadata: "" so it will be ignored
Similar for {{chem2}} [7]:
{{chem2/sandbox|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}}
<span class="MeTaDaTa::%5B%7B%28%5Ch%7B5%7DC5Me4%29SiMe2%28%5Ch%7B1%7DNCMe3%29%7D%28PMe3%29Sc%28%5Cm%7B2%7DH%29%5D2"><span class="chemf nowrap">[{(η<sup>5</sup>-C<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />5</span>Me<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />4</span>)SiMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span>(η<sup>1</sup>-NCMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>)}(PMe<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>)Sc(μ<sup>2</sup>-H)]<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span></span></span>
Visual rendering: [{(η5-C
5
Me
4
)SiMe
2
1-NCMe
3
)}(PMe
3
)Sc(μ2-H)]
2
Extractable metadata: "[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2" (could be further improved by improving the metadata generated in the {{chem2}} template)
{{chem2/sandbox|C2H3O2(-)}}
<span class="MeTaDaTa::C2H3O2%28-%29"><span class="chemf nowrap">C<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />2</span>H<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;"><br />3</span>O<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:-0.4em; line-height:1.2em; font-size:70%; text-align:left;">−<br />2</span></span></span>
Visual rendering: C
2
H
3
O
2
Extractable metadata: "C2H3O2(-)" (could be further improved by improving the metadata generated in the {{chem2}} template)
And for {{nowrap}} [8].
--Matthiaspaul (talk) 22:40, 24 September 2021 (UTC) (updated 11:45, 26 September 2021 (UTC), updated 18:40, 6 October 2021 (UTC))[]
An example of a variant of this rudimentary "inter-template communication model" using special tokens instead of or in addition to providing alternative metadata can be found illustrated for a modified sic template.
--Matthiaspaul (talk) 19:48, 6 October 2021 (UTC)[]
I don't know that there is sufficient support to proceed. Editor David Eppstein objects to the \(...\) markup so that may go away. Removing certain html markup may or may not be adequate; I don't know, I'm not a chemist so I don't know if the resulting output to the metadata would be at all useful.
Trappist the monk (talk) 14:05, 23 September 2021 (UTC)[]
This appears to be the thread of misunderstandings... I didn't understood David as if he would object the \(...\) at all, quite the contrary. He was concerned that issueing a visible error message would upset people, but that was before we discussed alternatives.
Regarding HTML cleanup, I'm no chemist either, but even if it might not be good enough to allow for really nasty things such as {{chem2}}, it would certainly be an improvement for many of the simple cases like the example:
Theory of free, spin-<span class="frac" role="math"><span class="num">1</span>⁄<span class="den">2</span></span> tachyons
Theory of free, spin-1⁄2 tachyons
--Matthiaspaul (talk) 16:11, 23 September 2021 (UTC)[]
Perhaps we should just change {{frac}} to use <sup> and <sub> instead of <span>s? The sup/sub can be styled for on-Wiki use, and stripped of class attributes that are meaningless to COinS consumers.  — sbb (talk) 01:26, 24 September 2021 (UTC)[]
Frac deliberately uses spans because sub and sup do not match the intent of their content. Do not abuse HTML please. IznoPublic (talk) 14:40, 26 September 2021 (UTC)[]

Format citations differently than body text

I don't see a contradiction between rendering a title as it appears in the work, and avoiding Unicode. The two are unrelated. Exact rendering in citations does not mean exactitude in presentation items like typefaces. It does include items with semantic significance. A formula will be recognized as such regardless of the typeface used, including the easy-to-read sans-serif typefaces traditionally used in citations. There is an issue with items such as subscript/superscript readability, but I believe it is minor, and there are ways around it.
The main thing is this: I would not use WP:MOS or any other Wikipedia wikitext formatting guideline as yardsticks. Citations are not wikitext, and should be formatted according to their own requirements. Whether the cited material is a science item or not makes no difference. 64.18.9.208 (talk) 00:04, 19 September 2021 (UTC)[]
Though the above examples do render in different typefaces, that's beside the point. Behind the scenes they use different representations. Though "₂" and "2" might look like the same number in different fonts, in fact they are different Unicode characters, and correctly interpreting the second one requires parsing HTML.
It's fine if there are special cases like coping with COinS, but suspending all MOS rules when it comes to citations would make the encyclopedia look quite unprofessional, increase skepticism, and make it a little harder to read. It would have far-reaching implications, and I don't think that's within the scope of what's being proposed. -- Beland (talk) 03:29, 20 September 2021 (UTC)[]
Wikipedia is un-professional, in both meanings of the term. First, as a general-purpose encyclopedia for non-expert readers. Secondly, as a project whose majority of content is unverified and therefore, drivel. As was remarked in another discussion here, the so-called "good articles" are a miniscule minority. So this is a project that unflinchingly publishes information that fails to pass its own mark. Which brings up the question of whether any "good article" criteria such a project decides upon can be trusted.
With such basis, it is imperative imo that citations stand apart, as the only way of turning the garbage heap into reliably usable information. They should not at all resemble wikitext body. They should stand out as its proof. Keeping in mind the target audience, they should be clear, unadorned, and easy to read, so that they can be easily found. It doesn't matter to a reader exactly how a subscript is rendered, only that it is. Use any easy-to-understand rendering, even if it is literal ("subscript 2"). Experts may cringe, but Wikipedia's audience will probably thank you.
Users (editors) I assume have similar expectations of the developers, but that would be a separate comment. 66.108.237.246 (talk) 13:05, 20 September 2021 (UTC)[]
OK, I guess we just have different goals, then. I'm working toward a professional-looking, credible, well-referenced, and verified encyclopedia. Writing something like "subscript 2" not only looks horrible, it's harder to understand (especially for students) than simply having a 2. Doing a search in a journal article database on "subscript 2" will almost certainly give bad results. -- Beland (talk) 00:47, 23 September 2021 (UTC)[]
The use of the literal "subscript 2" was offered only as an example of a non-expert reader's pov, and not as a concrete suggestion. Obviously the proper way would be the title verbatim, semantically, and this is a discussion that should end with the technical minutiae, not start with them. To again point out the obvious, no student should be using Wikipedia for anything related to their work. It is normally (in the statistical sense) unreliable, improperly or not all referenced, badly edited, and of dubious neutrality. And this is just the reader-facing pages. Any work outside of fixing these is just dressing up garbage in a pretty dress. May I suggest a beginning? Remove the "good articles" category and project. Assuming for the moment that the present "good article" criteria are valid, "good articles" are such a dismal minority, it is embarrassing. Instead add a warning to all other articles. Because the normal, obvious expectation of an encyclopedia is that it publishes good articles. Making clear (on a prominent and continuing basis) the fact that this is currently an unprofessional project is the greatest possible service to readers. And it is going to put everyone interested in fixing it in the right frame of mind. 64.18.9.196 (talk) 02:27, 23 September 2021 (UTC)[]

Moving toward a resolution

Are there any objections or comments on doing the following to get the ball rolling:

  • Use <sub>...</sub> and <sup>...</sup> instead of {{chem}} and {{chem2}} for chemistry formulas in citations.
  • Use {{citefrac}} instead of {{frac}} or {{sfrac}} for vulgar fractions in citations.

?

I don't often see more complicated math in citations, but would we want to make a {{citemath}} that uses <math>...</math> for now and can be switched over to \(...\) when that change is ready to be deployed? (And then easily changed again later if handling of TeX-like math formulas needs to change.) -- Beland (talk) 01:19, 23 September 2021 (UTC)[]

Follow WP:MOS, if COinS chokes, COinS chokes. Headbomb {t · c · p · b} 02:32, 23 September 2021 (UTC)[]
Well, the question is what the MOS should recommend. It seems like these techniques would allow us to keep a consistent style with body text without changing the MOS recommendation for that, and without causing COinS to choke. -- Beland (talk) 00:36, 24 September 2021 (UTC)[]
I might be missing the point, but if we want to make as little compromises regarding COinS-compatibility as possible, I don't see how something like {{citefrac}} would actually improve the situation in general (besides that it is nice to know if a template is CS1/CS2-safe or not). As far as I understood you, this is meant to be a "lightweight" version for vulgar fractions to be used in citations. But while being lightweight it may produce more COinS-compatible output (which is good), it will also produce less nice-looking titles in citations (which is not so good)...
IMO it is (more) desirable (because more flexible and universal) to try and clean up the HTML automatically, as demonstrated above. This won't work in all possible cases, but the results shown by Trappist above are already quite good IMO, and with a few more tweaks could become quite useable for our purposes. This and the \( ... \) trick for math are IMO a significant improvement over the current state of affairs. For those cases where the processing would not be desirable and we would want to pass the title to the metadata unchanged, we have our ((accept-this-as-it-is)) markup. For those cases, where we have both, a nice-looking title for local display and a (not so nice looking) alternative title used in external databases we want to match exactly to improve searches, we would have |descriptive-title= (which would also be useful for many other purposes, as mentioned further above). With this in place, we may need only a few general recommendations how to provide titles instead of having to address this explicitly in the MOS.
However, given that some significant developer efforts have been trashed by the "mob" recently, and thereby precious developer resources burnt, it would be great if those who agree with these proposals could actually indicate this instead of just remaining silent (as it happens to be the case here so often). This would help to convince the developers that it is worth to devote their volunteering time on these and other things.
--Matthiaspaul (talk) 11:41, 24 September 2021 (UTC)[]
@Matthiaspaul: Well, if some day the code is implemented to make regular {{frac}} COinS-friendly, we could always just drop the exception from the MOS and redirect {{citefrac}} to it or bot-substitute. If someone wants to say, "hey I'll have that code done in the next couple weeks", I'm happy to wait. If not, then while we're waiting for "some day" it would be good to make progress cleaning up on all the existing Unicode superscripts and subscripts in citations that no one seems to want. You did mention this solution produces "less nice-looking titles". I'm trying to make a lightweight solution that looks exactly the same as {{frac}}. Could you explain what differences you see, maybe with an example? Maybe there's a lightweight fix. -- Beland (talk) 18:20, 24 September 2021 (UTC)[]
Let's have a look at what Trappist's demo further above can do already:
Example:
{{frac|1|2|3}}
produces this non-sensible code in the citation's |title=, prompting the current implementation to throw a stripmarker error message:
'"`UNIQ--templatestyles-000000EA-QINU`"'<span class="frac" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>
which would be rendered by a browser as part of a citation in Wikipedia as:
1+23
The proposed generic "HTML simplifier" would derive the following code for metadata purposes, which could be passed on as COinS-metadata:
<span role="math">1+2&frasl;3</span>
or with a bit more tweaking:
<span role="math">1+2⁄3</span>
or even:
1+2⁄3
This is not perfect for human consumption but much better than the original code already. A user would be able to make sense out of it (although it may not necessarily match the work's title used in external databases, for which we would need |descriptive-title=). Assuming the COinS consuming entity would be able to process HTML, a HTML engine at their end would make this out of the simplified HTML:
1+2⁄3
Let's assume the {{frac}} template would have been made "CS1/CS2-compatible" following my proposed "template internal metadata" demo above, the metadata extractor could, for example, get this even more text-only result:
 1 2/3
for which no HTML engine would be needed at the receiver's end.
Regarding existing Unicode superscripts and subscripts, while I agree that the HTML sub- and superscripts look nicer if used in formulas and are generally to be preferred, in non-scientific articles an occasionally interspersed Unicode super- or subscript character in citation titles might not be a bad idea at all. At least they are COinS-safe out of the box and neither require a HTML engine at the receiver's end nor a TeX-savy human to be decoded. I would not use them in technical articles, but also would not want to ban them in non-technical articles. So, it all depends on the context IMO. What does this mean in regard to MOS or more-citation related guidelines? We could offer some generally recommended best practises there, but we should not rule out any of the possible formats in general. And what does that mean in regard to CS1/CS2? We will have to cope with whatever editors throw at us, therefore we probably need all, special \( ... \) markup, HTML simplifier, template internal metadata, and |descriptive-title= to cope with all possible cases optimally.
Regarding "hey I'll have that code done in the next couple weeks", the next CS1/CS2 update isn't scheduled yet but I guess it could be in mid-October.
--Matthiaspaul (talk) 22:04, 24 September 2021 (UTC)[]
To reiterate what was stated a couple of times above, this is looked at from the wrong end. The only resolution to this is the one that maximizes the utility of the citation to the average reader. Experts, practitioners and students in every academic field have vast resources available to them, resources that are properly vetted. The average person would mostly or only have Wikipedia, but here's the tendency to make this one resource too some sort of experts' preserve (albeit an unvetted one). Why not start from what the reader sees? Make that as clear and faithful to the original as possible. Then decide on the tools/guidance that editors should have in order to implement the reader requirements. Keep the guidance straightforward and tight. This is only a set of special cases of a single parameter in a sprawling module collection. Largesse in editor choices cannot be afforded in everything. Editors will have to learn to throw what the guidance states. Once the tools and guidance for editors is decided, the module could theoretically be developed in a hopefully carefully designed, rational, bugfeee way. But all development is theoretical. Because there are unresolved issues regarding any CS1/CS2 development. 68.173.76.118 (talk) 00:07, 25 September 2021 (UTC)[]
Everywhere else I can think of, instead of making formatting appear similar to where we're quoting from or citing, we make the formatting consistent on the Wikipedia side. That's what professional publications generally do unless they're showing an actual picture of the original. If we weren't doing that, we wouldn't have MOS guidance on fractions at all, and pages would look somewhat messier. -- Beland (talk) 07:39, 15 October 2021 (UTC)[]
@Matthiaspaul: It's mid-October. Any update on {{frac}} being made COinS-friendly? I'm not sure what you said above explained why {{citefrac}} looks not as nice as {{frac}}, but perhaps I'm missing something? -- Beland (talk) 07:39, 15 October 2021 (UTC)[]
Did you see my proposal to let known-to-be-problematic templates like {{frac}}, {{sfrac}}, {{chem}}, {{chem2}} etc. actively assist CS1/CS2 in its metadata creation (because the local developers of these templates know best how to translate whatever these templates are designed for in plaintext or simple HTML)? This would not replace the "general HTML simplifier" for those templates which have not been enhanced with this "template internal metadata" feature, but at least those templates which were enhanced accordingly would then produce perfectly nice output for display purposes and perfectly simplified but semantically correct plaintext (or simple HTML) as metadata. I proposed a general structure for this and also illustrated how this would be future-compatible and flexible enough to be further enhanced in other, semantically more abstract ways in the future.
IMO this, combined with the other proposed bits (the general HTML simplifier, the \(...\) markup and the |descriptive-title=), would allow us to address all aspects of the problem in the best-possible way without putting restrictions on users which templates or math markup they can use in citations, so that they can use what is best (based on their editorial capabilities) to produce the desired nice-looking output in rendered citations, but still would produce (or at least allow to produce) perfectly simplified and semantically correct metadata at the same time.
The \(...\) markup and general HTML simplifier have been implemented by Trappist already, although both could be further improved (as discussed). I have shown a "mockup" of the hidden "MeTaDaTa" feature. It would be ready for actual implementation, but I don't want to spend time on it if I get reverted by one of those ninja fighters who either don't participate in the discussions seeking for solutions or only complain about inadequacies without proposing better solutions to the problems. My limited time is too precious for this. Waiting for positive feedback...
--Matthiaspaul (talk) 12:56, 15 October 2021 (UTC)[]

metadata and accept-this-as-written markup

Discussion at Help talk:Citation Style 1 § HTML markup caused me to notice that the accept-this-as-written markup is preserved when |title= is added to the metadata. I have fixed that:

{{cite book |title=((Title))}}
Title.
'"`UNIQ--templatestyles-000000F7-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%28%28Title%29%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book/new |title=((Title))}}
Title.
'"`UNIQ--templatestyles-000000FB-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

I have not looked into the other places where accept-this-as-written markup may be used.

Trappist the monk (talk) 23:18, 15 September 2021 (UTC)[]

It's good that you mentioned this because I am sure I checked this in the past and your comment made me recheck it again now. Turns out, we have the same problem with |doi=, |issn=, |eissn=, |pmid= and |volume=.
--Matthiaspaul (talk) 17:37, 22 September 2021 (UTC)[]
|volume= fixed:
{{cite journal/new |title=Title |journal=Journal |volume=((12345))}}
"Title". Journal. 12345.
'"`UNIQ--templatestyles-000000FF-QINU`"'<cite class="citation journal cs1 cs1-prop-long-vol">"Title". ''Journal''. 12345.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.volume=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
Accept-as-written markup is documented for these identifiers: |doi=, |eissn=, |isbn=, |issn=, and |sbn= – the |sbn= value, even when valid, is not made part of the citation's metadata. For all other identifiers, invalid values are not made part of the citation's metadata even when wrapped with accept-as-written markup. A simple fix ensures that all valid identifier values wrapped with accept-as-written markup, and invalid |doi=, |eissn=, |isbn=, and |issn= values that are wrapped with accept-as-written markup do not include the accept-as-written markup in the citation's metadata. I have applied that fix:
{{cite journal/new |title=Title |journal=Journal |doi=((12345))}}
"Title". Journal. doi:12345.{{cite journal}}: CS1 maint: ignored DOI errors (link)
'"`UNIQ--templatestyles-00000103-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[doi (identifier)|doi]]:[//doi.org/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft_id=info%3Adoi%2F12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored DOI errors ([[:Category:CS1 maint: ignored DOI errors|link]])</span>
{{cite journal/new |title=Title |journal=Journal |eissn=((12345))}}
"Title". Journal. eISSN 12345.{{cite journal}}: CS1 maint: ignored ISSN errors (link)
'"`UNIQ--templatestyles-00000107-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[eISSN (identifier)|eISSN]]&nbsp;[//www.worldcat.org/issn/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.eissn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISSN errors ([[:Category:CS1 maint: ignored ISSN errors|link]])</span>
{{cite journal/new |title=Title |journal=Journal |isbn=((12345))}}
"Title". Journal. ISBN 12345.{{cite journal}}: CS1 maint: ignored ISBN errors (link)
'"`UNIQ--templatestyles-0000010B-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/12345|<bdi>12345</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.isbn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISBN errors ([[:Category:CS1 maint: ignored ISBN errors|link]])</span>
{{cite journal/new |title=Title |journal=Journal |issn=((12345))}}
"Title". Journal. ISSN 12345.{{cite journal}}: CS1 maint: ignored ISSN errors (link)
'"`UNIQ--templatestyles-0000010F-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[ISSN (identifier)|ISSN]]&nbsp;[//www.worldcat.org/issn/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.issn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISSN errors ([[:Category:CS1 maint: ignored ISSN errors|link]])</span>
Trappist the monk (talk) 23:04, 24 September 2021 (UTC)[]
Thanks. Lua was now throwing a "Lua error in Module:Citation/CS1/Utilities/sandbox at line 42: attempt to index local 'str' (a nil value)." for various template calls on Help_talk:Citation_Style_1/Archive_78.
This might have been caused by the changes above or other recent changes around the has_accept_as_written() function. I have fixed this by catching the str == nil special case, but have not yet checked if a more general change on a higher level (that is, not to call the function with nil values in the first place) might be a better fix.
--Matthiaspaul (talk) 11:14, 28 September 2021 (UTC)[]
Yep, tweaked a bit.
Trappist the monk (talk) 12:01, 28 September 2021 (UTC)[]

Dates were moved?

Maybe my memory is failing me, but has CS1 always output dates like this:

McClure, Tess (16 September 2021). "Aukus submarines banned from New Zealand as pact exposes divide with western allies". The Guardian. Retrieved 16 September 2021. (source)

I never remembered the dates being in parenthese like that. Is that new? –MJLTalk 18:06, 16 September 2021 (UTC)[]

This has always how it's been unless you have none of the authorship parameters: "Main Page". Wikipedia. 2021., and this case has an outstanding request for change since half a decade ago that is non-trivial to implement. Izno (talk) 18:45, 16 September 2021 (UTC)[]

hyphen_to_dash() moved

Because of a conversation at Template talk:Sfn § Add automatic endash for page number range?, I have moved hyphen_to_dash() from Module:Citation/CS1/sandbox to Module:Citation/CS1/Utilities/sandbox. The move allows Module:Footnotes/sandbox to have access to all of the necessary functionality without unnecessary code duplication.

Trappist the monk (talk) 20:12, 16 September 2021 (UTC)[]

Umm, no. It is not a good idea to be adding stuff to the cs1|2 module suite that is not used by cs1|2. It is the responsibility of {{r}}, {{rp}}, and {{ran}} to use the output from hyphen_to_dash() as-it-is, to modify that output as necessary to suit their needs, or do what needs doing on their own. The cs1|2 module suite is not all things to all templates. I am going to revert.
Trappist the monk (talk) 18:55, 25 September 2021 (UTC)[]
Well, then we must have misunderstood each other, because that's what I was talking about in regard to the functional differences between the implementations at Template_talk:Sfn#Add_automatic_endash_for_page_number_range?. ;-)
Unfortunately, if we don't want that extra parameter in CS1 (since we don't need it in CS1), we can't merge the two functions because {{r}} and friends depend on this. But no problem, the current merge still had a bug anyway which I was in the process of fixing.
--Matthiaspaul (talk) 20:18, 25 September 2021 (UTC)[]
Perhaps, perhaps not. I was thinking that something like this in Module:String2 would do what you want:
function p.hyphen2dash (frame)
	local utilities = require ('Module:Citation/CS1/Utilities/sandbox');		-- import functions from cs1|2
	local str, accept = utilities.has_accept_as_written (frame.args[1]);		-- strip accept-as-written markup if present
	local spacing = frame.args[2];

	if str and not accept then													-- string not wrapped in accept-as-written markup
		str = utilities.hyphen_to_dash (str);									-- convert hyphens to dashes
		if spacing then															-- when set
			str = str:gsub (', ', ',' .. spacing):gsub ('; ', ';' .. spacing);	-- override default spacing
		end
	end
	return str;																	-- and done
end
Trappist the monk (talk) 21:51, 25 September 2021 (UTC)[]

Volume/Issue not compatible with many journals

I don't know how to describe many journals, especially non-English, which don't identify "volume", but are usually marked as issue/year and/or issue from beginning. "Issue" field displays at the end and des not accept any other text. Pibwl ←« 12:34, 20 September 2021 (UTC)[]

Could you provide an example. 66.108.237.246 (talk) 12:38, 20 September 2021 (UTC)[]
You can omit |volume=. It is not required. – Jonesey95 (talk) 13:24, 20 September 2021 (UTC)[]
Okay, after some research I know, that what I really meant is a magazine, not journal, with template:Cite magazine. And indeed, "issue" field works well here. However, it would have been much easier, if "issue" and "volume" fields were included in "Most commonly used parameters" section on template:Cite magazine page. Thanks. Pibwl ←« 15:09, 20 September 2021 (UTC)[]
Go forth and edit the documentation. Izno (talk) 17:06, 20 September 2021 (UTC)[]

Place holder title "Subscribe to read..."

Some of the placeholder titles for websites that have content behind a paywall/subscription have their subscription advertisement (e.g. "Subscribe to read | Financial Times") as the placeholder title. Tanaya001 (talk) 13:04, 21 September 2021 (UTC)[]

At least this one says it was added with reFill 2. Kanguole 13:12, 21 September 2021 (UTC)[]
Not really a cs1|2 issue because cs1|2 can only render what it is given. If editors choose to use that hopelessly broken, unmaintained tool and then don't cleanup after it leaves a mess, someone else will have to do the cleanup. cs1|2 does aid in the cleanup by emitting an error message when it detects certain bogus article titles:
{{Cite web|url=https://www.ft.com/content/0029e6e2-7344-11ea-95fe-fcd274e920ca|title=Subscribe to read | Financial Times|website=www.ft.com}}
"Subscribe to read | Financial Times". www.ft.com. Cite uses generic title (help)
Beyond that, little can be done by cs1|2.
Trappist the monk (talk) 13:38, 21 September 2021 (UTC)[]

Proposal: Use the document icon instead of the external link icon for documents

Following up from this VPR discussion, I'd like to propose that we change the external link icon for CS1 citations in which |format= is set to a document file type such as .xls so that it uses the document icon () rather than the external link icon (). This will give a more appropriate signal to readers that clicking on the link will download a file for them, rather than taking them to a website page.

In technical terms, I'm told by SD0001 that we would do this by modifying Module:Citation/CS1/styles.css similar to what it already does with links to Wikisource. Thoughts? {{u|Sdkb}}talk 04:11, 22 September 2021 (UTC)[]

Not a good idea. We should train users so they understand that clicking anything with the external link icon is external and a potential security hazard (it might not be a hazard now, but could be in a couple of years when scammers get hold of the website). A friendly document icon tells the unwary that this link is blessed by Wikipedia. Johnuniq (talk) 05:27, 22 September 2021 (UTC)[]
We already have a separate PDF icon for PDFs, among others; this isn't really any different than that. {{u|Sdkb}}talk 07:09, 22 September 2021 (UTC)[]
Clicking on an online document will not necessarily explicitly download it. As is often the case with the useless pdf icon (I wonder if the majority of Wikipedia readers know what it signifies), browsers may use an embedded pdf viewer. Just like every other webpage, that item will be downloaded in local cache by default >90% of the time. The templates use the format parameter where the literal extension name with a wikilink to an explanation can be entered. Without any need for fancy icons that may break in a future MW iteration, or CSS workarounds. Instead of interminable ideas about minor presentation details, may I suggest, with all respect, to work towards adding proper citations to the vast majority of articles that need them. 64.18.9.196 (talk) 12:30, 22 September 2021 (UTC)[]
It's difficult to indicate two independent properties in one symbol.
I, too, consider it important to tell users they are about to click on an external link for security/privacy reasons, but I also think that it is useful for them to know if the external link content typically can be processed with built-in browser capabilities or needs some plug-in or external program to be viewed, or if it is text, graphical, audible, animated, as, depending on the environment the user is in, it may be technically difficult or inappropriate to consume (i.e. when loading an image using a text browser, or when loading a sound file on a computer without sound, or where sound may disturb other people).
It might be possible to superimpose the "external link" and various types of "document" icons to indicate some of these properties at the same time.
Alternatively, we could override MW and stop showing the PDF icon for external PDF files and consistenty show the external link icon for any kind of external links instead. The file format can be specified by |format= which adds some "(format)" text. CS1/CS2 even has some code to auto-detect PDFs based on the file-extension - we could add a few more common file types (per above criteria) to that list.
--Matthiaspaul (talk) 19:50, 23 September 2021 (UTC)[]
The PDF does not originate from MW. It is entirely a local en.wp customization. IznoPublic (talk) 14:35, 26 September 2021 (UTC)[]
The quantity of Excel sheets cited is probably insufficient to support a different icon in these modules. Moreover, I doubt an Excel sheet could be classified as a reliable source, anyway. IznoPublic (talk) 14:38, 26 September 2021 (UTC)[]
Izno, if for example a government publishes census data in an Excel sheet, why wouldn't that be reliable? — Alexis Jazz (talk or ping me) 21:19, 3 October 2021 (UTC)[]
We use such reluctantly as it is not generally secondary. Izno (talk) 21:23, 3 October 2021 (UTC)[]
The thing that matters for reliability is the source, not the format. There are plenty of legitimate uses of Excel spreadsheets if they're published by reliable sources or used for WP:ABOUTSELF information. {{u|Sdkb}}talk 21:55, 3 October 2021 (UTC)[]
Support - passing this info along to users in a natural and unobtrusive way makes total sense. Clicking a link that goes to an excel file feels like a total bait and switch unless I know about it ahead of time. Retswerb (talk) 03:23, 13 October 2021 (UTC)[]

cite news documentation

Should there be some text added about the general lack of need for the use of editors for newspapers and such. In many cases, the editors probably had nothing to with the article. AManWithNoPlan (talk) 16:00, 24 September 2021 (UTC)[]

No, if authors and/or editors are specified, they belong into the citation, no exceptions. --Matthiaspaul (talk) 16:36, 24 September 2021 (UTC)[]
Is there any publication out there that formats citations that way? 207.161.86.162 (talk) 04:48, 1 October 2021 (UTC)[]
Newspaper/newsagency (and less frequently) magazine articles may not carry a byline, and also there may be cases of newspapers/magazines with the same name. There is some merit in adding the editor, to find quickly the right news source, especially when the publisher/location is unknown/absent. Another consideration would be when articles are reprinted under different editors (in the same or another news source). In the unlikely case of differences in original vs. reprint, the respective editor should be indicated. Also, all reference databases for news sources include the editor and sometimes sub-index the works by that field, which means the source could theoretically be found quicker by adding the editor info. 65.88.88.91 (talk) 16:40, 24 September 2021 (UTC)[]
I am thinking more like the newspaper the new york times. AManWithNoPlan (talk) 16:48, 24 September 2021 (UTC)[]
I would not add the editor in such cases unless of course the item is signed by her/him or perhaps, in the case of citations of editorials. Afaik, the NYT has an "editorial board", so maybe the correct way to depict this would be to use |department=editorial. 65.88.88.91 (talk) 16:56, 24 September 2021 (UTC)[]
Matthiaspaul, are you saying that every reference cited to The Guardian needs to include the name of the editor of The Guardian? -- Alarics (talk) 20:55, 24 September 2021 (UTC)[]
If the editor is actually specified as "The Guardian" that would be appropriate, but in most such cases, staff writers are not mentioned at all, and "The Guardian" would be just the name of the news outlet. For staff writers we typically write something like |editor=<!-- staff writer, no byline --> (although I personally don't like this very much (for its bad machine-readability) and instead propose to standardize the case by introducing a special keyword like |editor=staff for it, which could be (actively) ignored by the template for now, but could also be evaluated if we would happen to run into a use case for this in the future - without |editor= (the template can't see the HTML comment), we never know if no editor was specified in the publication or if the author providing the citation was just too lazy to add it.) --Matthiaspaul (talk) 21:26, 24 September 2021 (UTC)[]
There are enough valid use cases for adding editors to periodical citations that I definitely wouldn't want this to be an error, even though it's usually not the right thing to do. One that comes to mind is when the periodical publishes a special issue or special section (which you can name using the |department= parameter) and you want to cite both an individual title and author within that section or issue, and the editors of the whole section or issue. —David Eppstein (talk) 08:00, 25 September 2021 (UTC)[]
Here's an example of a citation in this style that I used today:
Here, if you go to the DOI you will get a collection of mini-articles, collected into a single journal article, edited by Stewart, from which I wanted to cite the mini-article by Williams. I think this formatting is a reasonable way of doing that, although the ordering of metadata by the template leaves something to be desired (it should more clearly indicate that the author-title and editor-department are paired, rather than shuffling them in an ordering author-editor-title-department that makes less sense). —David Eppstein (talk) 07:38, 29 September 2021 (UTC)[]
Re the order of display. I believe it has been discussed previously. It has to do with the editor role applying to the entire work (journal) not parts of it. Previous discussions about adding editor roles to in-source locations went nowhere. It may be easier to do something like |others=Editor (column ed.) which is a bit clunky. Btw, it would perhaps be more accurate to use the |contributor= set here, but it is not available for journals. 71.247.146.98 (talk) 11:53, 29 September 2021 (UTC)[]
I actually think WP editors do a relatively bad job of including periodical editors anyway and would not super such a change. IznoPublic (talk) 14:34, 26 September 2021 (UTC)[]

[Template:Cite book] hyperlink for second editor

Is there no way to add a WP hyperlink for a second editor at Template:Cite book? Veverve (talk) 05:44, 25 September 2021 (UTC)[]

Of course there is. |editor2-link=. You should be splitting out your editors into separate parameters (|editor2-last= and |editor2-first=, or at least |editor2=) to make this work. —David Eppstein (talk) 07:55, 25 September 2021 (UTC)[]

Errata problem

Recent edits at Fea's tree rat and Common remora have produced "Lua error in Module:Cite_iucn at line 180: attempt to concatenate a nil value". That is seen by previewing the following.

{{cite iucn
|author=Smith
|title=Example
|errata=2017
|volume=2015
|page=1
|doi=10.2305/IUCN.UK.2015
}}

Johnuniq (talk) 10:00, 25 September 2021 (UTC)[]

Thanks. Fixed.
Trappist the monk (talk) 11:07, 25 September 2021 (UTC)[]
From Rock tapaculo, {{cite iucn|year=2016}} gives "Lua error in Module:Cite_iucn at line 124: attempt to index field 'title' (a nil value)." Johnuniq (talk) 07:05, 26 September 2021 (UTC)[]
Thanks. Fixed.
Trappist the monk (talk) 11:39, 26 September 2021 (UTC)[]

Page, pages, total pages, page range

I generally use the {{sfn}} citation style, with the sources in an alphabetical list at the end of the article. This lets me cite different pages in each source at different places in the article. In the {{sfn}} I give the page or pages being cited, e.g.

{{sfn|Smith|2001|p=19}}
{{sfn|Jones|2002|pp=12–13}}

In the source definition, I would like to give the total number of pages, and in the case of a journal article, the page range, e.g.

*{{citation |title=Precise citations |last=Smith |year=2001 |total-pages=248}}
*{{citation |title=Recent citation style changes |last=Jones |year=2002 |journal=Modern Pedantics |page-range=9–39 |total-pages=31}}

This would display something like

  • Smith (2001), Precise citations (248 pages)
  • Jones (2002), "Recent citation style changes", Modern Pedantics, pp.9–39 (31 pages)

Any problem with introducing this? It must have been discussed before. Aymatth2 (talk) 13:19, 25 September 2021 (UTC)[]

Add that information after the citation template if you must, as you have done above. It is not a typical or encouraged practice in the English Wikipedia, even though it appears to be common for other languages. Also, you don't need "31 pages" when the complete page range is already listed. – Jonesey95 (talk) 14:26, 25 September 2021 (UTC)[]
(edit-conflict) It has been discussed before. There are users who think that the total page information does not belong into a citation, but there are also users who requested it.
In fact, it is rarely given in citations, although I have seen examples where it was actually given. Above you give the example of a bibliography, this is another example where the total number of pages is actually quite common to be given.
Personally, I always provide the information when I have it available from a reliable source (the publication in front of me, not some Amazon or Google books listings as they are very often wrong), because I actually find this information quite useful myself when I find it in a reference. It helps to get a grip on if the publication is substantial enough to be worth the trouble of getting a copy in general, and it allows to quickly verify the (often inaccurate) page range info and estimate copying and postage costs when obtaining a work from a library.
Since CS1 does not have a parameter for this yet, so far I add the information following the citation in parentheses (like (xi+425 pages)), just like you do, but I would prefer to have a dedicated |total-pages= parameter for this, because this would ensure a consistent format instead of each editor having to invent his own nomenclature. It would be machine-readable, thereby we would also help to correct the many incorrect total-page info entries in the wild. There even is a COinS entry for this (&rft.tpages), also indicating that this is sometimes useful info to have. Wikidata has d:Property:P1104 for this and {{cite Q}} is already prepared to support this once CS1/CS2 would add support for it. Some citation templates in other language-entities of Wikipedia have a parameter for this as well.
--Matthiaspaul (talk) 14:31, 25 September 2021 (UTC)[]
The French w:fr:Modèle:Ouvrage has |passage= and |pages totales=. I suppose technically there is a difference between a citation, where we say "this is where this information comes from" and a bibliography entry, where we say "here is what we know about this source." The citation could be short {{sfn}}, giving the page and pointing to the bibliographic entry, which is the style I prefer. Giving both page range and total pages is redundant, but that is what JSTOR does, e.g. [9]. Aymatth2 (talk) 16:22, 25 September 2021 (UTC)[]
The JSTOR approach maybe a hold-over from older days, where such approaches would be used in articles that did not have continuous pagination, and the ToC was not useful in inferring the page range of an article. The actual page range in a biblio entry may not have been an unbroken range at all, just the article's first and last pages. The page count would be useful in showing the actual number of pages the article occupied, since the ToC would not be able to show it. In books, the total pages are shown in bibliographic/reference databases, but this is for reasons other than citing sources. Even the most used trade references (Nielsen's Bookdata, Bowker's Books In Print) in my experience do not show the total pages (or bytes, or running times) unless you drill down into a record's "Detail View". 65.88.88.126 (talk) 16:53, 25 September 2021 (UTC)[]
So a 4-page article could be spread over 6 pages by full-page ads. Simpler maybe to show pp.7–12 (4 pages) than the more accurate pp.7,9–10,12 (4 pages). Aymatth2 (talk) 20:51, 25 September 2021 (UTC)[]
For another example, the German citation template de:Template:Literatur has |Umfang= for this.
You are right, there is a difference between a citation and a bibliography entry, but CS1/CS2 templates are intended and designed to be used for both purposes.
--Matthiaspaul (talk) 17:10, 25 September 2021 (UTC)[]
The main argument for not adding |total-pages and |page-range parameters is it would make the template documentation even longer to support information most editors would not bother to provide. The reasons for adding them are that it ensures consistent formatting and supports greater mechanization in generating or checking bibliography entries. Aymatth2 (talk) 20:51, 25 September 2021 (UTC)[]
The total number of pages is irrelevant. This has been brought up several times before, see the archives of this page. --Redrose64 🌹 (talk) 21:35, 25 September 2021 (UTC)[]
@Redrose64: A citation identifies the source, and as you say the total number of pages in the source does not help with that. But as Matthiaspaul points out, CS1/CS2 templates are intended and designed to be used for bibliography entries as well as citations. In Konstantine Lortkipanidze#Publications it is reasonable to list the number of pages in the subject's works. The template renders "|pages=303" as "p. 303", which does not look like a page count. (303 pages) would be more obvious. In Konstantine Lortkipanidze#Sources there is perhaps less value in giving the page count, but there seems no reason to omit the information if available. Aymatth2 (talk) 00:36, 26 September 2021 (UTC)[]
p. 303 is obvious, it's a single page. p. 303-310 is equally clear as a range of pages. It's a red herring to say 303-310 might only be 3 pages interspersed with adverts as the point of the template in either a citation or a bibliography is to identify, for the reader, where to find the information. It is not to comment, directly or by inference, on how voluminous the author's work is. Nthep (talk) 06:47, 26 September 2021 (UTC)[]
The purpose of a bibliography entry is also to identify the source, and the total number of pages is not relevant to that. A list of an author's works is a special case, and I would argue that it does not justify adding a parameter that should not be used elsewhere. There is always the option of adding text after the template. Kanguole 08:51, 26 September 2021 (UTC)[]
Wikipedia probably contains several hundred thousand lists of authors' works. A bibliography in a book or scholarly article often gives the total number of pages. I suppose a minimalist would say all that is needed is page number and DOI, while a maximalist would say we should describe the source as fully as possible. It seems to be more a question of taste than of principle. Aymatth2 (talk) 12:35, 26 September 2021 (UTC)[]
I dispute the second claim. The standard style guides (Chicago, APA, MLA) are fairly consistent on what information to include, and none of them recommend the total number of pages. Kanguole 12:47, 26 September 2021 (UTC)[]
I was more thinking of a bibliography holding a list of an authors works. When citing periodical articles the cite would typically give author+page, and the bibliography would give the page range for the article. We can do that with {{sfn}}. But if we are combining the cite and source definition as with <ref>{{citation...}}</ref> at present we cannot give both the page and page range. Aymatth2 (talk) 13:26, 26 September 2021 (UTC)[]
Strong support for |total-pages=. Editors frequently misinterpret |pages= as "total pages". It's such a big problem trying to link online books only to end up displaying the empty last page. The |total-pages= will help reduce (not eliminate) the misuse of |pages= and increase accuracy of the citation. This is evidence-based, the reality of what users do in practice. There is behavioral demand for |total-pages=, if we don't provide it, they will do it anyway, and in such a way that it can only be fixed manually. -- GreenC 15:00, 26 September 2021 (UTC)[]
Disagree, I'm afraid. Assuming the documentation is clear, nobody should be obliged to accommodate whatever editors misinterpret. What is the use-case here? The total pages info is immaterial in a citation. It does not help in locating the source and verifying the wikitext in probably 99.99% of possible cases. That is a fact. If editors insist otherwise when clear guidance is given, they are wrong and there can be no further discussion. There seems to be confusion because some think that these templates are or should be used as bibliography templates. They are not, and using them as such is outside of proper citation usage, which is the urgent and necessary application for them. The templates are complicated enough to use without the added overhead of bibliographical entries. 64.18.9.196 (talk) 15:55, 26 September 2021 (UTC)[]
Sometimes what editors ought to do according to what we tell them to do and what they actually do is interesting. -- GreenC 16:18, 26 September 2021 (UTC)[]
It's the same as with most features, some people need them, others do not. Our general goal here is to set up the best and most comprehensive (and in the long term also most reliable) encyclopedia on earth, and the intent of this talk specifically is to develop citation templates enabling editors to do that as they see fit in the most convenient way imaginable.
Over the years an uncountable number of people have asked for this feature here and in many other places at Wikipedia. Other Wikipedias have it for long, Wikidata has it, COinS has it, some style guides ask for it, including some English ones (i.e. the NLM Style Guide [10]). So, this is a missing piece of infrastructure not only for users but also for machines.
Since enabling this feature does not hinder anyone to work just as before, but not enabling it hinders other users to work optimally, as they always had to find workarounds for it before, I have added the |total-pages= parameter to CS1/CS2 templates now. When specified, the info is displayed in parentheses following the other page info. As the use of this feature is entirely optional, users, who don't need it, can simply continue to not use it as before, but users, who always wanted to have this facility, can now finally use it through documented means. This will make this encyclopeia more convenient to edit, more consistent in its appearance, more machine-readable, and eventually more reliable to use. Since the total number of pages are automatically also reported as part of the COinS metadata we generate, external parties can take advantage of it as well. In the mid- to long run, this will help to fix an uncountable number of incorrectly stated total numbers of pages in external databases (Google Books and Amazon Marketplace come to my mind immediately). So everyone wins.
Examples:
--Matthiaspaul (talk) 22:06, 26 September 2021 (UTC)[]
I don't particularly care one way or the other but: Over the years an uncountable number of people have asked for this feature; really? Uncountable? I'd be very surprised if Google Books and Amazon Marketplace use our metadata when composing their pages about some book. Seems to me that you are struggling to find an argument that will convince those who oppose inclusion of |total-page= to switch their position.
I think that if we are going to keep this parameter, the supporting code in Module:Citation/CS1/sandbox should be made part of format_pages_sheets(). I have done that, added error detection, and other cleanup.
Further examples:
{{cite book/new |title=Title |total-pages=1 |no-pp=yes}}
Title. {{cite book}}: Unknown parameter |total-pages= ignored (help)
{{cite book/new |title=Title |total-pages=2 |no-pp=yes}}
Title. {{cite book}}: Unknown parameter |total-pages= ignored (help)
{{cite book/new |title=Title |total-pages=a}}
Title. {{cite book}}: Unknown parameter |total-pages= ignored (help)
{{cite book/new |title=Title |total-pages=[//example.com 1]}}
Title. {{cite book}}: Unknown parameter |total-pages= ignored (help)
Trappist the monk (talk) 23:11, 26 September 2021 (UTC)[]
Okay, strike "uncountable", set "many". ;-) Over the years there were many people asking for it, giving good arguments.
Regarding Goggle and Amazon, what I meant is not that they use our data (at least not directly - although indirectly Google probably does), but that their database entries contain a large number of errors. When I write down references for articles I always try to find an online source for the convenience of the readers. Sometimes I end up at Google Books (not Amazon) and when I compare their info with the publication in my hands I very often find their info to be incorrect in some ways (after verifying that we are actually talking about the same edition), the total number of pages is wrong in probably 20–30% of the cases. I don't know where they derive their data from, but it can't be only from manual entry during scanning. Sometimes the entries seem to be the result of mixing up several different editions of a work. So, even if Google would not be among those who harvest our data directly, providing accurate info will help other parties which do harvest us, and through data exchanges/comparisons/synchronizations, this will in the long term help to reduce the amount of errors everywhere.
Regarding the new error checking, thanks for adding this (this would have been on my list as well in one of the next few iterations).
--Matthiaspaul (talk) 09:55, 27 September 2021 (UTC)[]
I'm surprised that you added this in the middle of a discussion in which people were disagreeing with you. Please revert. Kanguole 23:28, 26 September 2021 (UTC)[]
A big improvement. Now when I am translating a French page and hit |passage=132|pages totales=269 I do not have to drop information. Great! A useful step towards supporting meaningful bibliographies. Aymatth2 (talk) 00:31, 27 September 2021 (UTC)[]
We are here to find and implement solutions to solve problems, not to keep problems unresolved forever. If you don't need a feature, simply don't use it. Other people have a use for the feature and are adding (and were always adding) total page info anyway when they found it appropriate to include it in the entry - it is just that they had to append it at the end of the citation so that it did not show up alongside the other page info where some style guides recommend to put it and that they had to invent their own nomenclature. This caused an inconsistent look and made the entries more difficult to maintain (like Green pointed out). Now, they can do it in a structured and consistent way. Makes it easier to handle for everyone, humans and machines. Fewer errors, and easier to correct.
--Matthiaspaul (talk) 09:55, 27 September 2021 (UTC)[]
There is absolutely no demonstrated consensus for the addition of |total-pages=. This must be reverted. The rationale behind your argument is flawed and the opinions expressed debatable. This is a disruptive edit in the middle of a discussion. 64.18.9.196 (talk) 02:53, 27 September 2021 (UTC)[]
This change isn't live, just in a sandbox. Nthep (talk) 08:22, 27 September 2021 (UTC)[]
Yep.
--Matthiaspaul (talk) 09:55, 27 September 2021 (UTC)[]
If there is anything that is disruptive, it is the totally inappropriate drama board tone you use. What is also disruptive to the process and project is to try to hinder constructive and productive editors to work more efficiently out of some strange dogmatics. It boils down to WP:DONTLIKEIT. See problems from multiple perspectives and think solution-oriented (solutions to solve everyone's needs, not only your own ones) and not ideologically.
--Matthiaspaul (talk) 09:55, 27 September 2021 (UTC)[]
What goes in the sandbox is test cases of what is decided here. Not your notions of what should be. They don't belong in the modules' sandboxes. As has been pointed out many times this parameter has nothing to do with discovering sources in order to verify wikitext. The ideology here is coming from you, consistently. Instead of making of citations something they are not try fixing the existing problems. Polluting the sandbox with whatever fancy notion or non-applicable request anyone comes up with is hardly constructive. 64.18.9.197 (talk) 12:04, 27 September 2021 (UTC)[]
What benefit is provided in a reference telling the reader it is page 437 out of 1131? Absolutely none that I can envisage? The only possible use is in a bibliography where there are no page or page ranges mentioned and even then I am dubious that there is any real benefit. Neither do I accept the metadata argument for the same reasons given by Trappist. I'm not here to build a machine-readable work but a human-readable one. Nthep (talk) 08:22, 27 September 2021 (UTC)[]
In the book example, as a reader, the total page number tells me that this is a substantial work on the topic which might be worth obtaining, and it will also give me a first clue on its weight and consequently the shipping costs which would be significant, for example, when you have to import the book because it is a foreign language work. In a bibliography the entry would typically not carry an individual page number cited but just the total number of pages, because this is information given quite regularly in a bibliographical list. As our citation templates are designed to be used for referencing just as well as for bibliographical lists, it is desirable for editors who want to add this info to be able to do so in a well-defined way instead of having to resort to workarounds - why should they?
In the journal example, the total page info is somewhat redundant with the page range info, but as has been pointed out, some databases only list the first (and the last) page, not the actually covered pages (often enough, the last page is not even given, so a database entry might appear to be for a single-page article whereas it actually covers multiple pages), and so, when an article is spread over multiple pages, the total number of pages might be smaller than the difference between the start and end pages. This is particularly common in magazines and newspapers with advertisments, not so much in actual journals, so perhaps I should have given a magazine example rather than a journal example. So, the entry can be helpful to verify the other page info entries (see Green's comment above). Just like in the book case, it will also help to quickly estimate if an article is substantial or just a short note. This may help in deciding if it is worth to obtain the article from a library and the costs involved for copying, shipping and handling. Libraries can be quite expensive and charge on a per-page-basis, so this is important info to know. Sure, if the other page info is complete (including the end page) and accurate, the number of total pages can be derived from there as well, but, as said, often enough it is not, and if the pages entry is, i.e. |pages=23–24, 27, 29, 30–35, 37, 39, 41–43, 60 (real example from a magazine article) it is easier for the reader to get it from something like |total-pages=18.
You wrote I'm not here to build a machine-readable work but a human-readable one That's fine. You do not need to be here to build a machine-readable work, and nobody is hindering you to continue to focus on humans only, if you want to. However, others are here to make our contents available to anyone, and for me, this also includes machines (although not primarily). Wikipedia is part of the emerging semantic web. And that's not for the purpose of itself, but for the convenience of the readers as well as the users of the information elsewhere. There are lots of services by third-parties which are basically fed by data from Wikipedia. We don't target them primarily, but anything that serves them (and does not go into our own ways of doing things) will indirectly help us as well as consumers of these services and as researchers and writers of other articles. Total number of pages alone don't matter, but COinS as a whole does, and the more complete and accurate the info, the better.
--Matthiaspaul (talk) 09:55, 27 September 2021 (UTC)[]
Sorry but the first reason is complete rubbish, citations are not there to help work out shipping costs and/or copying costs but to verify content, period.
You want to make things more machine friendly then again that's fine but I'd suggest that those efforts ought to be concentrated in places like Wikidata where you can add all the machine relevant data you want without it having to become more visual bloat for human readers. Also putting information into Wikidata might aid editors like Aymatth2 as they won't have to translate citation information just pull in the bits they want from Wikidata.
I'd be prepared to compromise on total pages being in but only if the style guide is that they are only used in bibliography lists and not in citations but first preference would be to move it all to Wikidata. Nthep (talk) 11:40, 27 September 2021 (UTC)[]
I think that is a reasonable compromise, assuming use of total pages applies both to bibliographies of the subject's works, where it is important, and to bibliographies of works cited by or relevant to the article, where it is interesting. It is good to have attributes like this in Wikidata, but challenging to most editors to get it there. The most practical way is for the editor to put it in a structured template in Wikipedia, then have a bot migrate it. The French seem ahead of us on use of Wikidata. I am starting to see infoboxes that just display Wikidata attributes, e.g. w:fr:Honoré Bouche (click on "Modifier le code"). Aymatth2 (talk) 13:20, 27 September 2021 (UTC)[]
I'll be clear about what I think is acceptable use of total pages - a list of works by the subject, whether that is an article in itself or a section of an article about the author.
Not acceptable - any work used to reference the article or in a further reading section. So anything that goes in <ref></ref> tags or is in a sources section where an article uses {{sfn}} or any other referencing system is not to use total number of pages, nor is it a way to get round this by not citing a work but listing it as further reading.
But I repeat, moving as much details about books, journals, webpages etc to Wikidata and pulling the information from there is much more preferable to having amounts of bloat in Wikipedia. Migrating existing data to Wikidata is fine, adding more into Wikipedia to export it to Wikidata is not ok. Nthep (talk) 16:48, 27 September 2021 (UTC)[]
(edit-conflict) Nthep, regarding your without it having to become more visual bloat for human readers. I wonder where you see the visual bloating. I mean, it is not that this info wasn't present in articles so far and would now suddenly start to appear. Editors have always been adding total page info to (some) citations and (some more) bibliographic entries where they found it appropriate, and that is perfectly okay per CITEVAR. I consider it more visually displeasing (and also inconvenient) having to append the info at the end of a citation template and seeing this information formatted variously because each editor chooses his/her own styling then to have it included where some style guides recommend to put it, that is, alongside the other page info, and before the identifiers. However, the exact place is certainly debatable, the point is that if the info is included it should be formatted consistently.
I don't expect editors now suddenly starting to add the info all over the place, if that is what you are afraid of, it's just that they now can do what they always did in a structured way without having to worry about how to style it (that's one of the very purposes of templates).
Like you I think that it will be mostly used in bibliographic entries and only occasionally in citations, just like before. So, there is at least some agreement there. But the details of what is appropriate in a particular context is to be discussed, if necessary, by the individual contributors and article editors, not by us. We just provide the tools to enable our editors to work more efficiently and produce more consistent output more reliably. I could understand some concerns when we would be changing the syntax and some users would have to change their long-trained habits just because of a new feature they personally don't need or understand, but in this case nothing changes for them. They can simply ignore it. Occasionally they will see the total page info in articles, but that's not different from the situation now - they always saw them, just in free style notation. So, this really should be a non-issue and no-brainer. If we don't add it, the next good faith editor will come around and ask for it in a couple of months, like they did for years. The fix to the issue is to finally address it, not to ignore it (or the editors asking for it).
There is obviously a reason, why people come here asking for it, there is a reason, why it's recommended in some style guides, and why it is part of COinS, and Wikidata, and is supported by citation templates in other Wikipedias. They can't be all wrong. Smart people try to learn from other people's experiences and habits.
--Matthiaspaul (talk) 15:30, 27 September 2021 (UTC)[]
Which style guides recommend it? Kanguole 16:49, 27 September 2021 (UTC)[]
For your convenience here are some examples:
  • NLM [11][12][13][14][15][16][17][18][19][20] (for books, conferences, technical and scientific reports, dissertations, theses, bibliographies, maps, web, media)
  • AMS [21] (for books, theses, reports, memos, notes)
  • NCBI [22] (for some)
  • IWC [23] (for books, chapters, articles, reports)
  • KNE [24] (for books, conferences, reports, dissertations, theses)
  • CSE [25] (for journal articles)
  • AR [26] (for books, conferences, bulletins, theses)
  • UVLF [27] (for books, conferences)
I have also personally seen this style studying the references and bibliography sections of French, Russian, Polish, Czech and German publications, including some older books. Reportedly, this style is particularly common in France.
There are many more, but this quickly collected list should already prove that this is a real-world issue and that these requests emerge from actual use cases (not something someone made up as some inhere appear to believe just because they haven't seen it personally - there is a world outside the bubble... ;-)
See also:
--Matthiaspaul (talk) 19:35, 27 September 2021 (UTC)[]
I think there are editors who will start to add it all over the place, simply because the parameter is there. Populating it with what though? Yes, there are going to be conscientious editors who will go from physical copies or good online libraries containing accurate reproductions of documents but there are others who won't and will use figures taken from Google books, Amazon marketplace - which you appear to admit are not entirely accurate. Then we're not improving any quality just reinforcing the status quo. Smart people try to learn from other people's experiences and habits - yes they do, but sometimes the answer is to question back "what benefit do you think this adds to Wikipedia?" and that's what I'm doing. I've not seen any argument that either convinces me that it is necessary or beneficial (just because we could doesn't mean we have to or should do) nor convinces me that it won't be misused. I can see a very limited use case but I still think that it is of negligible benefit to (the quality of) Wikipedia but one I am prepared to compromise on if those pushing for it to be included recognise that others have concerns about it's use and that these need to be discussed - not on an article by article case - but more generally about where total pages is appropriate or not. Nthep (talk) 17:17, 27 September 2021 (UTC)[]
Even if there is irrationality in Wikipedia (including in this thread ;-) I ultimately believe in the conscientiousness of the majority of our contributing editors (otherwise this whole project would have long collapsed rather than emerged into the quite impressive although still imperfect form it has found already). So, if someone would "abuse" the feature, they would be corrected. Ultimately, the decision to include or not include the information is up to the editor working on the article, just as it is now already (hence the need to potentially talk it out on the article talk pages in case of disagreements). We can't dictate anything here, but what I think might be useful to add to the documentation of this feature is an appeal that editors should use their "common sense" in applying it and not use unreliable sources.
All in all, I think, this feature will help to reduce errors in Wikipedia, not increase them. For one, because it would keep people from abusing the |page= and |pages= parameters for the count of pages (Green reported this as a common problem, I have seen it as well many times, and even two participants of this thread (one supporter and one opposer) admitted that they abused the |page= parameter for this - this will create incorrect metadata (COinS rft.pages), so the error is carried on. Switching to |total-pages= would not only eliminate the distribution of incorrect metadata, but even start to add the correct metadata (rft.tpages). Secondly, it will also help to find other incorrect usages of the |page=/ |pages= parameters, which are quite common, where, for articles spanning over multiple pages, only the start page is given and people assume the publication to be a one-pager, or only the lowest and highest page, rather than the actual range, which might be non-continuous. All this will improve the reliability of our information and not only help third-parties, but directly help our readership, i.e. as it will reduce the number of incorrect library orders based on our pagination data.
--Matthiaspaul (talk) 12:11, 28 September 2021 (UTC)[]

Page, pages, total pages, page range: break

The biggest problem Wikipedia has is its unreliability. Obviously, it will never become reliable, as its contributors are anonymous and of uncertain expertise. But it can become less unreliable, by a focus on publishing articles that are based on fact, or on articles that explicitly present currently accepted opinion as such, with space also given to major counter-opinions. In order to do that articles must be verified. A first step towards that is to base wikitext on easily verifiable (by humans) citations, and then verify these citations as appropriate to the article. In the sprawl of current Wikipedia, not even the first step of the first step is anywhere close to conclusion. Instead, add-ons such as Wikidata take precious development resources. What this does, is proliferate unreliability. Because the base data is unreliable. Treating citations as bibliograhic entries unfocusses development from the essentials and adds complexity. This thread and others are proof. Citation templates are there for citations easily readable and verifiable by humans and not software, a necessary and urgent requirement. They are not there for whatever one thinks they can cram into them. The total pages info does not belong in a citation. This is a massive waste of time. 65.88.88.46 (talk) 15:10, 27 September 2021 (UTC)[]

I have started many articles about authors, always include a bibliography (usually called "Works" or "Publications" to avoid confusion with the article bibliography), use the {{citation}} template for the entries and show the number of pages or journal page range where available. But the format is awkward:
This is not a reference to page 1089, but an attempt to show that the book has 1089 pages. If total-pages were available I would use it, and the bibliography entry would be clearer. Are there in fact 1089 pages in this book? I think there are, but perhaps the source is wrong. The only way to eliminate all errors from Wikipedia is to eliminate all articles. Making it easier to format information does not make errors more or less likely. Some books are cited by several articles. If the metadata for such a book were held in Wikidata and reflected mechanically in Wikipedia articles it could be verified once. The articles that cite it would all show the same verified metadata. Aymatth2 (talk) 17:57, 27 September 2021 (UTC)[]
None of the above is disputed. Here's where the dispute lies:
  • The citation system is used for citations. If it is used for anything else, including bibliographies, it is beyond the system's scope and concerns. Use it for biblio entries if you must; I have done so. But I don't come here with requests for unsupported use. I have to live with what is around, until proper inline biblio forms (ie not infoboxes) are available. I use |no-pp=yes and |pages=nnn pp..
  • Yes, in theory Wikidata is going to be a good thing. Sometime. In the meantime, garbage in/garbage out. If the original book information (including any citation) is unverified and unreliable, so is Wikidata. It is also magnifying the unreliability through reuse, making things worse.
104.247.55.106 (talk) 18:32, 27 September 2021 (UTC)[]
If an article uses {{sfn}} to point to source definitions at the back formatted by {{citation}}, that is long-established practice, good practice when several different pages are being cited from one source. The list of sources is a bibliography and the {{citation}} entries are bibliography entries. They do not give page numbers – those belongs in the {{sfn}} entries – but they describe the source, and could give total pages or page range if known. We have a standard template for formatting information about books, papers, periodical articles etc., and it is called {{citation}}. We do not need a another template for articles that use {{sfn}} and a third for lists of works by the subject of the article. Aymatth2 (talk) 19:38, 27 September 2021 (UTC)[]
We are going in circles, I believe. Is it understood that Wikipedia is a novel project that cannot be compared with established practice of any sort? There has simply never been a similar project of anonymous, unvetted contributors serving the general public. What would suffice in a professionally edited work by an approved/vetted known author geared to a particular demographic is inadequate here. Is it so hard to understand that a novel project may require novel thinking? Here, everything must be proven. The citation system that helps bring this about must be efficient, clear and easily understood. Topical citations with sources not known to be unreliable, and the fastest, easiest way to apply them for verifiability. The issue is not {{sfn}} or the full citation templates. Needed are correct sources (that is the so-called "work" patameter) and a fast, easy way to locate them (that is all the other citation parameters that point in some way or other to the work's location). "Total pages" does not contribute to that. 64.18.9.197 (talk) 22:17, 27 September 2021 (UTC)[]
Most Wikipedia users find articles to be well-written, useful and accurate, because the articles most users look for are carefully edited. At the other extreme, there is a mass of articles that start off with "The village headman is the most Honorable Amrit Singh who has selflessly conferred many great benefits..." Only those who think covid vaccines contain tracking chips pay any attention to these ones. In between there is a wide band of articles on more or less obscure subjects that are often useful and sometimes excellent, although they may rely on sources that are not entirely accurate. Even the most pompous academic papers often contain errors. We will never achieve perfect accuracy. But we should make it easy for editors who are concerned about quality in citations and bibliographies to record relevant data about sources in consistent format using standard templates. Aymatth2 (talk) 00:41, 28 September 2021 (UTC)[]
The audience of an encyclopedia are its readers, not its editors. It should be made easy for readers to verify whatever nonsense editors write. It is nonsense until verified. That is only the first step. But it is absolutely necessary because the next steps depend on it. Also, several fictional items were mentioned: how would "most users" know that articles are "accurate"? They are not "useful" otherwise. And if they are "well-written", unless verified, they are well-presented garbage. How can anyone tell that the articles "most users look for are carefully edited"? And how can an article be "useful" and "sometimes excellent" if they depend on sources that "are not entirely accurate"? One could surmise that such vague, unproven, and self-contradictory language comes from people who insist (absent any proof) that vaccines contain tracking chips. Another fictional item above is the notion that citations are about achieving accuracy. They are not. They are about providing the most efficient, clear way to verify claims made in wikitext. Citations are agnostic otherwise. A citation from a source not known as unreliable that verifies wikitext is a good citation no matter if the claim it verifies is later proved inaccurate or biased. These concern further steps in verification, beyond the purview of citations. But they cannot happen unless first, the citations are there. And it is easy to see, by randomly picking any Wikipedia article, that proper citations are a very distinct, small minority. But it gets worse. For a time I was reading designated so-called "good articles". I was not surprized to find they were often poorly cited and badly edited, using language that should have been flagged as non-neutral. 64.18.9.199 (talk) 03:30, 28 September 2021 (UTC)[]
It is hard to know what sources to trust. Maybe the vaccine is indeed full of chips. I think I saw something on Twitter about that. Let's hope the new |total-pages parameter helps clear up the confusion. Aymatth2 (talk) 22:00, 28 September 2021 (UTC)[]

Citation++

One possibility would be to repurpose the deprecated {{source}} template for use in bibliographies. It could wrap {{citation}}, then add a few descriptive elements to the end: |total_pages= |page_range= |folio= |binding= etc. It would refer to {{citation}} for description of all the other parameters. It would give a sort of escape valve for those who prefer more complete bibliographical information without adding complexity to the citation templates. Just possibly, some obscure parameters from those templates could be migrated to the new {{source}}. Aymatth2 (talk) 18:20, 26 September 2021 (UTC)[]

Citation tool for Google Books - Server Error

http://reftag.appspot.com/ does not seem to be working? Chesdovi (talk) 13:41, 26 September 2021 (UTC)[]

See Help_talk:Citation_Style_1/Archive_78#Reftag_error_messages
--Matthiaspaul (talk) 14:23, 26 September 2021 (UTC)[]
This is not something we can help you with here. Moreover, this has been reported in the correct places onwiki (the tool creator's talk page). IznoPublic (talk) 14:30, 26 September 2021 (UTC)[]

Unlikely authors

Previous discussion: User talk:GreenC#Does your bot fix author parameters?

I sometimes see online works attributed to prolific authors such as Mr. Privacy Statement, Ms. Cookie Policy and Dr. Submitted Content, which have clearly been scraped in a semi-automated way from the website. (Samples) Are they generated using some tool which could be improved? Certes (talk) 16:42, 26 September 2021 (UTC)[]

Thanks. I have added them to the list of bogus names:
Mr. Privacy Statement. Title. {{cite book}}: |author= has generic name (help)
Ms. Cookie Policy. Title. {{cite book}}: |author= has generic name (help)
Dr. Submitted Content. Title. {{cite book}}: |author= has generic name (help)
--Matthiaspaul (talk) 18:54, 26 September 2021 (UTC)[]
Thanks! They usually seem to appear in first-last pairs as |first=Privacy |last=Statement – I'm not sure whether Module:Citation/CS1/Configuration is invoked when they're split that way. Other regular contributors include:
  • "About Us"
  • "Contact Us"
  • "Content" (but beware of genuine author Thomas Content)
  • "Content Team"
  • "Home Page"
  • "Media"
  • "Privacy Policy"
  • "Site Admin"
  • "Site Name"
  • "Sponsored Content"
  • "Sponsors"
  • "Staff Directory"
  • "Staff Writer" (but more commonly something like "Daily Blurb Staff/Sports/Film/Obituary Writer", so possibly too complex)
Is it possible or desirable to look for individual words such as privacy, admin, content, etc. within longer names? Beware that we cite a few genuine authors with matching names, such as Cookie Lommel. Certes (talk) 19:40, 26 September 2021 (UTC)[]
"Staff writer" or "Admin" would be functional names, not bogus ones. It would be okay to state them in a citation if they are given this way in the publication. "Content Team" and "Sponsors" could be valid functional names as well, although unlikely. BTW, we have a similar list for bogus titles.
--Matthiaspaul (talk) 19:59, 26 September 2021 (UTC)[]
So far we only sense(d) for individual words, but I have now added "Contact us", "About us", "Home page" and "Site name" as double-word patterns because I felt "Contact", "About", "Site", "Name", "Home", "Page" and "Us" could be (unusual) surnames in some languages as well. If we can rule this out, the patterns could be improved. We can also search for actual patterns.
This is a new feature, so we are still collecting patterns and as we find similarities between them this will likely see many detail refinements in the future. While it is possible to override the check using our ((accept-this-as-is)) syntax, we still must be careful to only generate a neglectible (that is, near zero) number of false positives. --Matthiaspaul (talk) 20:19, 26 September 2021 (UTC)[]
Thanks again. I discussed "Content Team", etc. with a couple of editors and found a weak consensus not to show them, but I see the advantage of erring on the side of caution by leaving them in. Certes (talk) 21:34, 26 September 2021 (UTC)[]
@Certes: If you'd like to give me some examples, I'll sic BattyBot 24 on them. Thanks! GoingBatty (talk) 19:27, 27 September 2021 (UTC)[]
I got rid of a few hundred cases with JWB but here are a few which I missed or are new:
I can trawl more carefully if you need more bot fodder. Certes (talk) 20:10, 27 September 2021 (UTC)[]
@Certes: BattyBot has fixed these four, and is looking through the last database dump for more instances. Feel free to send more examples of frequently used patterns. GoingBatty (talk) 21:37, 27 September 2021 (UTC)[]
@GoingBatty: Well done! "About the Author" is a polymath, cited on a dozen topics ranging from LGBT rights in Ghana to Charlie's Burgers. Less common ones include:
Most of the errors I fixed would be hard to delegate to a bot, often of the form |first2=Ivor Penn Chief Sports |last2=Writer, or a mishmash of non-persons such as ref 5 in Bioethics Bowl. Certes (talk) 23:34, 27 September 2021 (UTC)[]
@Certes: Fixed! GoingBatty (talk) 04:03, 28 September 2021 (UTC)[]
@Matthiaspaul: Is there a category for those bogus names? Will you be adding a Help:CS1_errors#generic_name section? Thanks! GoingBatty (talk) 04:03, 28 September 2021 (UTC)[]
Sure, the category name will be Category:CS1 errors: generic name. I have added some provisional text now, but, as I wrote, this is a new feature, which will be fully activated with the next general template update.
See also:
--Matthiaspaul (talk) 10:40, 28 September 2021 (UTC)[]
Thanks to GoingBatty for the fixes and to Matthiaspaul for the links. I didn't realise this was a perennial request, but hope we've added a few more strings that can usefully be matched. Certes (talk) 13:41, 28 September 2021 (UTC)[]
|author=/|first=/|last= parameters with dates or years in them could be tagged as well. GoingBatty (talk) 14:16, 28 September 2021 (UTC)[]
Category:CS1 maint: numeric names: authors list (16,548)
Category:CS1 maint: numeric names: contributors list (0)
Category:CS1 maint: numeric names: editors list (0)
Category:CS1 maint: numeric names: interviewers list (0)
Category:CS1 maint: numeric names: translators list (0)
Trappist the monk (talk) 14:25, 28 September 2021 (UTC)[]
The current test would not find something like
{{cite book |title=Title |author=28 September 2021}}
28 September 2021. Title.
If this is a reasonably common error, we could add a check if the name value is in one of our recognized date formats, and if it does, emit an error as well. April, May and June may need special cases. ;-) Well, probably not because as a date, they would not come without a year and/or day, so they would pass through correctly.
{{cite book |title=A Green Meadow |author-first=April |author-last=Appleyard |date=15 May 2021}}
Appleyard, April (15 May 2021). A Green Meadow.
--Matthiaspaul (talk) 14:44, 28 September 2021 (UTC)[]
I think that the problem that results in "About Us", "Contact Us", "Home Page", "Privacy Policy" (and similar terms) being yielded is sometimes caused by the original URL no longer being available, and the website's servers are redirecting it to a generic landing page. For some websites this can happen for pages that require a subscription to view. --Redrose64 🌹 (talk) 15:02, 28 September 2021 (UTC)[]

Requesting edit in Template:Cite journal

Please change Doi (identifier) to Digital object identifier to avoid redirect. Thanks. 2604:3D08:4E7F:F7E0:38AB:63B4:498:69DB (talk) 18:12, 26 September 2021 (UTC)[]

No, this is deliberately coded this way to avoid the clutter at "What links here" (read: make it useable again) and improve reverse lookup/filter capabilities in general.
--Matthiaspaul (talk) 18:41, 26 September 2021 (UTC)[]

kerning

The other day I stumbled upon Barbus sp. nov. 'Pangani' as an article title:

{{cite journal |title=''Barbus sp. nov. 'Pangani''' |journal=Journal}}
"Barbus sp. nov. 'Pangani'". Journal.

I have modified kern_quotes() to properly render that title:

{{cite journal |title=''Barbus sp. nov. 'Pangani''' |journal=Journal}}
"Barbus sp. nov. 'Pangani'". Journal.

While I was doing that, I simplified the whole of the function:

without leading or trailing quote marks:
{{cite book/new |chapter=[[neither]] |title=Title}}
"neither". Title.
{{cite book/new |chapter=neither |title=Title}}
"neither". Title.
simple wikilinks with leading, trailing, or both quote marks:
{{cite book/new |chapter=[['leading]] |title=Title}}
"'leading". Title.
{{cite book/new |chapter=[[trailing']] |title=Title}}
"trailing'". Title.
{{cite book/new |chapter=[['both']] |title=Title}}
"'both'". Title.
complex wikilinks with leading, trailing, or both quote marks:
{{cite book/new |chapter=[[example|'leading]] |title=Title}}
"'leading". Title.
{{cite book/new |chapter=[[example|trailing']] |title=Title}}
"trailing'". Title.
{{cite book/new |chapter=[[example|'both']] |title=Title}}
"'both'". Title.
plain text with leading, trailing, or both quote marks:
{{cite book/new |chapter='leading |title=Title}}
"'leading". Title.
{{cite book/new |chapter=trailing' |title=Title}}
"trailing'". Title.
{{cite book/new |chapter='both' |title=Title}}
"'both'". Title.

Part of the simplification was to use 'empty' <span class="cs1-kern-left"></span> and <span class="cs1-kern-right"></span> tags instead of splitting the title apart and wrapping part of it in <span>...</span> tags:

live:
{{cite book |chapter='leading |title=Title}}
"'leading". Title.
'"`UNIQ--templatestyles-00000157-QINU`"'<cite class="citation book cs1">"<span class="cs1-kern-left">'</span>leading". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=%27leading&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
sandbox:
{{cite book/new |chapter='leading |title=Title}}
"'leading". Title.
'"`UNIQ--templatestyles-0000015B-QINU`"'<cite class="citation book cs1">"<span class="cs1-kern-left"></span>'leading". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=%27leading&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Trappist the monk (talk) 15:31, 27 September 2021 (UTC)[]

Nice. Does module kerning apply to |quote= as well? I don't remember. If it does, I believe there are additional kerning cases there. Just something to keep in mind for whenever. 65.88.88.69 (talk) 22:12, 28 September 2021 (UTC)[]
No, but not really necessary because |quote= is a free-form parameter that does not contribute to the citation's metadata. When quoted text begins with single- or double-quote marks, editors can use:
{{-'}}
{{-"}}
and when when the quoted text ends with single- or double-quote marks, editors can use:
{{'-}}
{{"-}}
Trappist the monk (talk) 22:34, 28 September 2021 (UTC)[]
Kerning is applied for readability. I've no idea what that has to do with metadata. Also, for consistency's sake the output of this field (kerning included) should match the other fields automatically delimited with quote marks. As stated above there could theoretically be more kerning cases to |quote=. 64.18.9.199 (talk) 23:13, 28 September 2021 (UTC)[]
The kerning code was written because all titles that cs1|2 wraps with quote marks contribute to the citation's metadata. We don't want editors using {{-'}} and the other kerning templates in those titles because those templates emit styling that has nothing to do with the source's title:
<span style="padding-left:0.15em;">&#39;</span>{{-'}}
At some point in the now long-forgotten past, the decision was taken to wrap the value assigned to |quote= in <q>...</q> tags. No doubt, if you seek through the archives you will discover that decision. The css that supports the <q>...</q> tags is here.
Trappist the monk (talk) 23:32, 28 September 2021 (UTC)[]
Not helpful. Editors were using the kerning templates, and other tricks (I was one of them), in order to make citations legible to readers. You know, the constituency for which citations exist. The fact that the crude metadata scheme used here chokes on it is of no concern to the consumers or producers of citations. I am glad that you took the time to implement this some years back. It is still a metadata development issue, not a citation development one, but anyway. The quotation marks were added as automatic delimiters to a number of fields (title, chapter, quote etc.) because they are significant information that must be quoted verbatim, and because human editors were occasionally forgetting to do so, or would omit the close etc. Again, I don't understand why the tags are mentioned. Nobody is questioning the tags' suitability. This is about adding kerning to a value that is tagged already. 64.18.9.197 (talk) 00:01, 29 September 2021 (UTC)[]

Location parameter

Should the location parameter be used for the location of an archive? See [28] and [29] for context. DrKay (talk) 17:40, 27 September 2021 (UTC)[]

Option 1: Whitney, Philip. The Story of WFVA/WBQB: 1939–1996. WINC Collection, 1616 THL, Stewart Bell Jr. Archives, Handley Regional Library, Winchester, Virginia: Handley Regional Library. p. 1.CS1 maint: location (link)
Option 2: Whitney, Philip. The Story of WFVA/WBQB: 1939–1996. WINC Collection, 1616 THL, Stewart Bell Jr. Archives, Handley Regional Library, Winchester, Virginia. p. 1.
Option 3: Whitney, Philip. The Story of WFVA/WBQB: 1939–1996. Winchester, Virginia: WINC Collection, 1616 THL, Stewart Bell Jr. Archives, Handley Regional Library. p. 1.
Option 4: Whitney, Philip. The Story of WFVA/WBQB: 1939–1996. p. 1 – via WINC Collection, 1616 THL, Stewart Bell Jr. Archives, Handley Regional Library, Winchester, Virginia.

The location of the information, which is in paper form, is WINC Collection, 1616 THL, Stewart Bell Jr. Archives. That's the name of the collection, the room number, and the name of the archives department at the library itself. The library asks you, on their website, to "Cite As: WINC Collection, 1616 THL, Stewart Bell Jr. Archives, Handley Regional Library, Winchester, VA, USA." So, the publisher is, technically, Handley Regional Library. I am just required by them to cite it in such a way. I'm not being an asshole, I'm following their citation rules. If that puts the article in a clean up category, there's nothing I can do about that. That is the genuine location of the information. - NeutralhomerTalk • 17:53, 27 September 2021 (UTC)[]

Oh, by the way, there is no "Page 1" within this collection. It's just a mass of all sorts of different things. - NeutralhomerTalk • 17:54, 27 September 2021 (UTC)[]
Perhaps {{cite archive}} is a better choice? In cs1|2 ({{cite book}} etc) |location= is the physical location of the publisher.
Trappist the monk (talk) 18:03, 27 September 2021 (UTC)[]
{{cite archive}} works just fine. Give me a couple minutes to move the references around. :) - NeutralhomerTalk • 18:18, 27 September 2021 (UTC)[]
Corrected. :) I think we can mark this as closed. - NeutralhomerTalk • 18:34, 27 September 2021 (UTC)[]

|quote= fix

in the live module, |quote= works properly but standalone |script-quote= and |trans-quote= do not include the <q>...</q> tag:

{{cite book |title=Title |quote=quoted text}}
Title. quoted text
'"`UNIQ--templatestyles-00000164-QINU`"'<cite class="citation book cs1">''Title''. <q>quoted text</q></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book |title=Title |script-quote=ja:script-quoted text}}
Title. script-quoted text
'"`UNIQ--templatestyles-00000168-QINU`"'<cite class="citation book cs1">''Title''. <bdi lang="ja" >script-quoted text</bdi></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book |title=Title |trans-quote=trans-quoted text}}
Title. [trans-quoted text]
'"`UNIQ--templatestyles-0000016C-QINU`"'<cite class="citation book cs1">''Title''. &#91;trans-quoted text&#93;</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

fixed in the sandbox:

{{cite book/new |title=Title |quote=quoted text}}
Title. quoted text
'"`UNIQ--templatestyles-00000170-QINU`"'<cite class="citation book cs1">''Title''. <q>quoted text</q></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book/new |title=Title |script-quote=ja:script-quoted text}}
Title. script-quoted text
'"`UNIQ--templatestyles-00000174-QINU`"'<cite class="citation book cs1 cs1-prop-script">''Title''. <q><bdi lang="ja" >script-quoted text</bdi></q></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
{{cite book/new |title=Title |trans-quote=trans-quoted text}}
Title. [trans-quoted text]
'"`UNIQ--templatestyles-00000178-QINU`"'<cite class="citation book cs1">''Title''. <q>&#91;trans-quoted text&#93;</q></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Trappist the monk (talk) 14:42, 28 September 2021 (UTC)[]

Is there a parameter for "advisor" in cite thesis

There is a citation in the article artificial intelligence where the thesis advisor is notable person. Is there a parameter to list the thesis adviso in {{Cite thesis}}? Should I use {{{others}}}? ---- CharlesGillingham (talk) 22:02, 28 September 2021 (UTC)[]

There is no parameter for the advisor role. I'm not convinced that there should be such a parameter. Did the advisor contribute to the thesis in a material way or was the advisor filling an administrative function? If the former then name the advisor as an additional author; if the latter, leave the advisor out of the citation.
Trappist the monk (talk) 22:26, 28 September 2021 (UTC)[]
There is not. |others= would be fine if you believe the advisor merits addition to the citation for whatever reason. IznoPublic (talk) 22:30, 28 September 2021 (UTC)[]
If there is a use-case for this (the advisor seems to be present in dissertation metadata), I would propose an alias to "editor" with suffix (adv.). But |others= seems fine. 64.18.9.197 (talk) 23:30, 28 September 2021 (UTC)[]

i18n |script-<param>= error message supplements

|script-title= and the like have error message supplements that specify the the reason for the error message. There are four of these which are embedded in the main module. In the sandbox, I have moved these supplemental messages to Module:Citation/CS1/Configuration/sandbox:

Cite book comparison
Wikitext {{cite book|script-title=ja:|title=Title}}
Live Title. Invalid |script-title=: missing title part (help)
Sandbox Title. {{cite book}}: Invalid |script-title=: missing title part (help)
Cite book comparison
Wikitext {{cite book|script-title=ac:script-title|title=Title}}
Live Title ac:script-title. Invalid |script-title=: invalid language code (help)
Sandbox Title ac:script-title. {{cite book}}: Invalid |script-title=: invalid language code (help)
Cite book comparison
Wikitext {{cite book|script-title=es:script-title|title=Title}}
Live Title script-title. Invalid |script-title=: unknown language code (help)
Sandbox Title script-title. {{cite book}}: Invalid |script-title=: unknown language code (help)
Cite book comparison
Wikitext {{cite book|script-title=script-title|title=Title}}
Live Title script-title. Invalid |script-title=: missing prefix (help)
Sandbox Title script-title. {{cite book}}: Invalid |script-title=: missing prefix (help)

Trappist the monk (talk) 11:43, 1 October 2021 (UTC)[]

Changes to Cite news/doc

48Pills: in this edit, alias of 'Lay summary' is not correct. Please change it back to the actual parameter name. – Jonesey95 (talk) 05:24, 3 October 2021 (UTC)[]

We should just deprecate and remove |lay-date=, |lay-format=, |lay-source=, and |lay-url=. I have marked these parameters as deprecated in the ~Whitelist/sandbox and will change our documentation to reflect that state.

Of course, now that I've done that, I expect that somebody's knickers will get in a twist and I'll all end up at some drama board. Those parameters are not amenable to replacement by bot because some human must decide if they are important to the en.wiki article and then create a separate cs1|2 template for those sources. Creating a maintenance category is possible but very, very few of us even know that maintenance categories exist so it will be years before the last |lay-<param>= is removed (if ever).

Trappist the monk (talk) 12:16, 3 October 2021 (UTC)[]

I've reverted them, for the second time now. 48Pills, you must gain consensus for these changes, otherwise they will be reverted again. Changing the standard parameter presentation order without good reason is not acceptable. Headbomb {t · c · p · b} 13:59, 3 October 2021 (UTC)[]

QID

Are there any plans to link the citation templates with Wikidata? I was thinking of 2-way connections:

  • The citation templates would accept a |qid= parameter pointing to a Wikidata entry for the source book, magazine, website, whatever. This would pull in values from Wikidata for attributes that were not given in the template. In some cases only the QID and page number would have to be supplied to get a complete citation
  • A bot would periodically migrate attribute values from Wikipedia to Wikidata. The articles would now get the attribute values from Wikidata, which can be maintained centrally.

To confirm practicality, I made a very crude template at User:Aymatth2/citeQ to pull values from Wikidata. There is no error checking, but it seems to work:

Code Renders
{{User:Aymatth2/citeQ |Q25169 |page=123}} Douglas Adams, Eoin Colfer (1979), The Hitchhiker's Guide to the Galaxy, p. 123
{{User:Aymatth2/citeQ |Q4386569 |page=34}} Beatrix Potter (October 1903), The Tailor of Gloucester, Frederick Warne & Co., p. 34
{{User:Aymatth2/citeQ |Q313030 |page=456}} Edward Gibbon (1776), The History of the Decline and Fall of the Roman Empire, p. 456

The advantage would be complete and consistent source descriptions rendered from a single vetted Wikidata entry. The citations would be the same across all articles that use the source apart from page number. Error messages or hidden categories could be generated when the Wikipedia values did not match the Wikidata values, so they could be tracked down and corrected. I am sure there are all sorts of complexities: Books have different editions, journals get new publishers, articles are spread over multiple magazine editions, etc.. But is there any reason why we would not work towards implementing something like this? Or is it in the works already? Aymatth2 (talk) 14:03, 3 October 2021 (UTC)[]

Umm, {{cite Q}}?
There are no plans to link cs1|2 templates to Wikidata.
Trappist the monk (talk) 14:09, 3 October 2021 (UTC)[]
More or less, there's a lot of WP:BEANS/Vandalism-related reasons for why using Wikidata for citations is undesirable, as well as several style reasons for why we don't want to do that either. We killed {{cite doi}}/{{cite pmid}} etc... because of it, and {{cite Q}} is likewise not widespread for the same reason, and should be removed from articles whenever found. Headbomb {t · c · p · b} 14:19, 3 October 2021 (UTC)[]
Aymatth2: See the talk page for {{Cite Q}} for the reasons why that template is not widespread. It causes CITEVAR problems, primarily because of author name formatting, and needs to be used carefully, if at all. – Jonesey95 (talk) 17:32, 3 October 2021 (UTC)[]
Looks like that was not such an original idea. I had no idea {{cite Q}} existed, but used an almost identical name! I can't see any style problems, since it would just wrap {{citation}}. Vandalism seems no more likely if the information is held in Wikidata – which could be semi-protected to minimize risk. The current Template talk:Cite Q looks like steady progress is being made on resolving issues. One problem that I can see is that I prefer first and last names separated which does not seem to be Wikidata standard. This is mainly to keep {{sfn}} entries short. The benefits generally seem to outweigh the drawbacks. Aymatth2 (talk) 17:45, 3 October 2021 (UTC)[]

dead link : add "url-status=dead", and then WHAT? And where is intelligence gone?

Extended content

Hello. Found a dead link (in Álava, section "Demography and rural landscape"). So:
1) waste some 20 mns foraging in the irekia.araba.eus trying to find the "Su poblacion" page despite rather poor Spanish (un-)fluency. Nada, no surprise as it's a government site. 2) look for template for "cite web", which cheers me up a bit coz unlike the french wiki it can be found without having to add "template:" before writing "cite web", well done to yous.
2) find the "url-status= dead / archive-url=" thingie without excessive aggro, again well done to yous.
3) add this to the ref.
4) reload the page, expecting to find something like a string of options such as what is found in the Fr wk with "lien brisé= [input said broken link]", which then allows one to click on one of the options (usually "archive.is") to access the archived doc; from which one can either (a) find the new relevant page by copying some essential suit of words and searching for it on the web; or, failing that, (b) at least have in the ref that string of options including "archive.is" which, in most cases except PDFs, gives access to the archived page and thus access to its link which can then be added to your "archive-url=".
5) Nada again.
6) waste quite some more time coming here to detail the pbm, being thoroughly pissed off by then - as shown by what follows. HtF* are we supposed to find links of archived pages if you don't provide the means for it? No I do NOT want the answer to that question. I want anyone who comes on wk with a modicum of good will to be able to find the damn thing with minimum aggro and without having to become a *** I.T. expert, and in theory so do yous. Thus I, and in theory so should yous, want the ""url-status= dead" to provide the same thing as what "lien brisé= [input said broken link]" does in the Fr wk: an option that gives direct access to the archived page and therefore to the link that's supposed to be added to "archive-url=".

Where is inte-l-lingence gone?

I am REALLY annoyed: the way this template is geared up at the moment is a sure sign of yous having lost touch with two essential things, just as governments do :

  • the basics = the majority of people. You've forgotten how it is for them / "us" as a pronoun that does not include yous.
  • intelligence, in its etymological sense = inter + ligare, meaning that you not only have forgotten how it is for us: to top it up you don't even know / remember how to get back in touch. Ligare, link, assemble, bind. Yeah, yous link among yourselves to ask each other what the others of your little group think of that can improve whatever. So it's a sort of brainstorming, meaning it's debated only among the very few people whom you are in touch with and who already more or less know about the subject. That's a ridiculously microscopic portion of the less than 0.3% of the accounts holders who are themselves regular editors[1].

Asking help from your tiny minute group of mateys here is no proper inte-l-ligence at all but the opposite of it. It's also very likely a reason why there are so few registerees who edit[1]. To develop intelligence yous must ask precisely these people who are no regular editors; and for that you have to get out and look for them, which you clearly do not do. Instead you expect them to find you/s!
That, is why i don't come here exposing the technical problem and meekly asking that please cn yous sort it out. Fk that: I do not give meekness to unintelligence and I neither expect nor want it in return. In return I want intelligent intelligence. I want yous, all of yous, to become inte-l-ligent: change your ways and start asking people who do not know anything but the very basics about technical shenanigans, who have no time for them nor interest in them. There are many such people who do nevertheless have knowledge that would be good here. So get out of your comfort zone, out of your little narrow circle. Appeal for help. That, is real, true and proper cement that gets ppl to-gether/gather more and deeper than any "social event", as technocrats call these. Why: because it has meaning and a goal. It takes a miracle for any kind of "social event" to have any of these two components and by then it's not called "social event" but "revolution".
It's exactly 20 yrs since i did my first edit in wk. At that time we were happy if ppl would just put even only a raw link between the <ref> </ref> thingies, the [link title] was 3-tier wedding cake with a crown on it. In 20 yrs the refs templates have become increasingly complicated, even more so in the En wk. Well done people: you have now reached the point where it starts becoming unusable even by regular users. What's wrong with humans that they keep doing again and again and again that very same mistake ever since Upper Palaeolithic times, for heavens' sake? There is no animal I can think of that's a stupid as that. Haven't you had enough time to learn? We're all in the same boat, dammit. So bloody well learn to ask others beyond your comfort zone or we'll all be fucked once more. That doesn't apply only here, obviously, but it'd be a good start.

one solution could be...?

I regularly see banners announcing various events which are all supposedly aiming at "making the community strive", every one of those being so totally irrelevant to me that I never ever even look at them. Plus, they reinforce the "select" idea, thus doing the exact opposite to what they're supposed to do. Gatherings : gotta have enough money and time to get there. Photos: gotta have a decent camera. Etc etc etc incl. voting which only ever helps the establishment maintain a facade but does not help us editors for one iota, same as in all politics. What would interest me are appeals for help in such matters as what's described here, saying what the problem is about + link to page that'd give more details and where to say our bit on things that impact every single edit. I definitely would read these, and if the debated matter was smthng that I have come across, yes of course I'd open the page and take the time to say how, where, why, and/or whatever idea's come from it if any. Plus I'd have the pleasure of participating in something directly useful, which is the one thing above all other things that brings people together.
There are many of these issues. Starting with the banner that irrelevantly comes up in this very page if I put the {{references}} underneath that section so as to keep the note nearby and it not ending up at the bottom of the page where it's disconnected from its origin; + of course that banner offers no solution to that nonsense.

I shan't come back on this page nor shall I talk about the subject anywhere else on any wk: I've said all I have to say and detailed all there was to detail from where I stand, both about the technical problem and about the absence of proper inte-l-ligence. Talking more about it would only make me "part of" and there's no way that's gonna happen, not as things are so far. I've said what I want and want no other thing.
As for the form it's taken, unintelligence as described is one of those things that cannot be uprooted without significant bottock-prodding. I verily don't give a fig about being banned: 1) it would only give another proof that what I've said is even truer than what's said; 2) it sure won't stop me editing just as I've done for longer than most of yous; 3) it won't cut me from any crowd, i'm no part of any such thing. So, definitely no apologies: I'm not the one who should be sorry. Sod the bien-pensants outragés and other wikiatollahs of the same vein, I'm not one of yous and yous sure don't own any single bit of me. Keep your curses for your mirror where they belong. In fact, that telling off has brought me a handsome reward: a neighbour's just dropped one of the largest packages of goodies i've ever received for my chicken, worth a good week's supply of treats that's taken me longer to sort out than writing this has taken. So I definitely must have been doing something right there. A bon entendeur salut.

References

  1. ^ a b "42,295,232 Wikipedia accounts, of which 125,882 are actively editing" (en.wikipedia.org) = 0.29% of account holders become regular editors.
    Out of interest, I also find : "As of January 2021 there were 4.66 billion active internet users worldwide - 59.5 percent of the global population. Of this total, 92.6 percent (4.32 billion) accessed the internet via mobile devices." (Internet users in the world 2021 | Statista). Regular editors probably don't edit mainly from their mobiles - if they do they deserve a medal: editing here from a mobile is a real pain in the fundament, not least because of the technical bits such as what I mention above. Still, that's a hell of a number to think of as potential contributors.

Signed : a VERY thoroughly annoyed Pueblo89 (talk) 14:35, 3 October 2021 (UTC)[]

Summary

Since this is a very long-winded rant with, the basic summary is this

And that (understandably) greatly annoys the user above. Headbomb {t · c · p · b} 14:53, 3 October 2021 (UTC)[]

Thank you for the summary. It has occasionally been an issue where users are confused how to mark a cite dead where they use |url-status=dead as a flag for a dead link when they should use {{dead link}}. -- GreenC 16:21, 3 October 2021 (UTC)[]
I don't know that anyone has ever suggested that cs1|2 should create a list of archive-site search links when |url-status=dead (or its predecessor |dead-url=yes) is present and |archive-url= is missing or empty. Could be done I suppose, but there are a lot of archive sites; which of those would we include? which of those would we omit? Would a better solution be a dedicated page with an input box that accepts the 'dead' url and then somehow creates and displays a list of archive-site search urls? I don't know if that is even possible...
Trappist the monk (talk) 16:58, 3 October 2021 (UTC)[]
It could open a page like BookSources and display all possible archive URLs for the passed source URL using something like memento or memgator. The archive date is a problem as that would also need to be given. Theoretically it could be generated for every citation even those without an explicit archive url. Users can then pick out the best archive URL and fill it into the citation. -- GreenC 18:03, 3 October 2021 (UTC)[]
Isn't |url-status= dependent on |archive-url=? What is the issue here? 72.89.161.42 (talk) 18:16, 3 October 2021 (UTC)[]

EventStream API

In capturing URLs for saving at Wayback Machine via EventStreams API (page-link changes), some URLs are not being captured and trying to figure out why. For example |pmc=1248180. This is hard to test and I don't know how cs1|2 injects/expands URLs but if anyone has any experience or thoughts that would be great. -- GreenC 16:21, 3 October 2021 (UTC)[]

For most identifiers, cs1|2 concatenates a prefix onto the value assigned to the identifier parameter. For |pmc=1248180 the prefix is //www.ncbi.nlm.nih.gov/pmc/articles/PMC which gives //www.ncbi.nlm.nih.gov/pmc/articles/PMC1248180. Prefixes are available in Module:Citation/CS1/Configuration in the id_handlers{} table (currently at line 1903 for |pmc=).
There are some identifiers that are more complicated:
|asin= has |asin-tld= (Module:Citation/CS1/Identifiers line 726)
|ol= modifies the url according to the value in |ol= (Module:Citation/CS1/Identifiers line 1081)
there may be others.
Trappist the monk (talk) 16:47, 3 October 2021 (UTC)[]
Sounds like they are rendered strings like everything else in the module which wouldn't explain why EventStreams is not (possibly) seeing them. -- GreenC 17:49, 3 October 2021 (UTC)[]
I would be very leery of auto-capturing any Wikipedia citation or any citation element for archiving without first verifying it for applicability and reliability. This is manageable when human editors preemptively archive a source with a discrete edit. A mass of unverified archives just adds another platform for suspect, a priori-low quality information. 72.89.161.42 (talk) 18:28, 3 October 2021 (UTC)[]
Huh? That's the entire point of InternetArchiveBot, which has wide consensus to operate. Izno (talk) 19:06, 3 October 2021 (UTC)[]
Yes. I happen to think that the consensus is wrong, for the reasons stated earlier. I don't think that it is impertinent to occasionally remind that this issue was not tackled then, or since. 72.89.161.42 (talk) 19:24, 3 October 2021 (UTC)[]

Questionable Sources

How does one tag a ref as potentially not being reliable, is there a parameter in the template to check? Did a quick search in the archives and saw a bunch of old conversations but guessing someone knows the answer. - Indefensible (talk) 04:50, 4 October 2021 (UTC)[]

That's not something that is done with these templates. See Wikipedia:Reliable sources and the documentation for {{Unreliable source?}} as a good place to start. – Jonesey95 (talk) 05:41, 4 October 2021 (UTC)[]
Thanks for providing that info, was looking for that. - Indefensible (talk) 05:52, 4 October 2021 (UTC)[]

Journal template & sic

I raised this in a Phabricator task however it was basically closed as "functions as designed" and I was pointed here. Would be interested in hearing any comment.

Within a CS1 {{cite journal}} template if a {{sic}} template (with 'nolink' option used) is attempted within the text within the |journal= parameter then an error is produced indicating that Italic or bold markup not allowed..... If a {{not a typo}} template is used instead then this is accepted and does not produce the error.

An example can be found here. https://en.wikipedia.org/w/index.php?title=Multiway_number_partitioning&diff=prev&oldid=1048226979

What happens?:
Note the reference to 'markup not allowed'.

Walsh, Toby (2009-07-11). "Where are the really hard manipulation problems? the phase transition in manipulating the veto rule". Proceedings of the 21st International Jont [sic] Conference on Artifical [sic] Intelligence. IJCAI'09. Pasadena, California, USA: Morgan Kaufmann Publishers Inc.: 324–329. Italic or bold markup not allowed in: |journal= (help)

What should have happened instead?:
I would have expected that the following would be valid syntax.

<ref name="Walsh 324–329">{{cite journal|last=Walsh|first=Toby|date=2009-07-11|title=Where are the really hard manipulation problems? the phase transition in manipulating the veto rule|url=https://dl.acm.org/doi/abs/10.5555/1661445.1661497|journal=Proceedings of the 21st International {{sic|Jo|nt|nolink=y}} Conference on {{sic|Arti|fical|nolink=y}} Intelligence |series=IJCAI'09|location=Pasadena, California, USA|publisher=Morgan Kaufmann Publishers Inc.|pages=324–329}}</ref>

I can't say that I have tested other citation styles however there are others such as {{cite web}} where the sic template seems to work fine. If this is regarded as FAD and no intention to fix then the documentation requires updating. Happy to do that. - Neils51 (talk) 03:07, 5 October 2021 (UTC)[]

I doubt this is a FAD item. This is a bug. {{sic}} is a necessary utility template that can indirectly affect verification, even when it is understood that citation elements are presented verbatim. I did not look at the code to see exactly why this returns an error in |journal= but not in other {{cite xxx}} templates. But there are several issues with the module code, so it is not surprising. The bottom line is, this should be fixed. Citation-wise this is not frivolous. All such templates should be compatible. 71.247.146.98 (talk) 11:47, 5 October 2021 (UTC)[]
This does not depend on the {{cite xxx}} template, but happens with any CS1/CS2 citation template, if you put italic markup in one of the parameters for periodicals (|journal=, |magazine=, |newspaper=, |periodical=, |website=, |work=). {{sic}} does that, {{not a typo}} doesn't. The obvious fix would be to correct the two typos in the name of the periodical. --Matthiaspaul (talk) 13:20, 5 October 2021 (UTC)[]
They are not typos. That is the function of the {{sic}} template, to make that obvious. This is a bug of the module that should be fixed, and very easily. The bug is based on bad module design. The citation modules should not return errors unrelated to citations. This is very easy to implement. These "errors" and their discussion belong to the COinS pages, not here. As it is now, it can be argued that they indirectly impede verification by limiting legitimate editor choice and making citations less exacting. 64.18.9.201 (talk) 13:39, 5 October 2021 (UTC)[]
One really does have to wonder about the quality of a source when the publisher can't be bothered to spell-check the title of its offering. And why are you using {{cite journal}} to cite conference proceedings? We have {{cite conference}} for that.
Did you not see it? Right at the top of the {{sic}} template documentation is a message box that has this image: Stop hand nuvola.svg. That message box is there because {{sic}} produces output that is not suitable for inclusion in cs1|2 citation metadata. Instead, avoid the issue entirely: perhaps use {{text}} or {{not a typo}} to mark the spelling errors and prevent auto-spelling correctors from fixing the misspellings and to produce correct metadata:
|book-title=Proceedings of the 21st International {{text|[Jo|nt]}} Conference on {{text|[Arti|fical]}} Intelligence
Walsh, Toby (2009-07-11). "Where are the really hard manipulation problems? the phase transition in manipulating the veto rule". Proceedings of the 21st International [Jont] Conference on [Artifical] Intelligence. IJCAI'09. Pasadena, California: Morgan Kaufmann Publishers. pp. 324–329.
Or, silently fix the spelling because it is pretty obvious that joint and artificial are the intended words ...
And why does {{sic}} italicize its output? The brackets aren't sufficient to set it apart from the rest of the text? As a loanword, per MOS:FOREIGN, sic should not be italicized (italicized here because MOS:WORDSASWORDS) – I find it in my 1974 Webster's New Collegiate Dictionary which satisfies the rule-of-thumb for loanwords.
Trappist the monk (talk) 14:07, 5 October 2021 (UTC)[]
This is an obvious typographical error that should be silently corrected, per MOS:CONFORMTITLE and MOS:SIC. If you as an editor insists on shaming the publisher by reproducing the typo, that editor should use {{not a typo}}. – Jonesey95 (talk) 14:35, 5 October 2021 (UTC)[]
Are you responding to me?
Trappist the monk (talk) 15:04, 5 October 2021 (UTC)[]
No, of course not. Sorry for being unclear. Personal pronoun struck. – Jonesey95 (talk) 15:09, 5 October 2021 (UTC)[]
This is a case of misapplied pedantry. Firstly, {{cite conference}} is the appropriate template, as the cited material is conference proceedings, not a journal. Secondly, the name of the conference is not "21st International Jont [sic] Conference on Artifical [sic] Intelligence", it is "21st International Joint Conference on Artificial Intelligence". The typos are not in the name of the work, they are in ACM's digital library referring to (see use-mention distinction) the conference proceedings. So the appropriate place for {{sic}} would be in some putative body text, "ACM's digital library refers to IJCAI'09: Proceedings of the 21st international jont [sic] conference on Artifical [sic] intelligence ...", not the cite.
The citation used in the article is just ACM's abstract. Why not go to the source and get the actual paper for free, not just an abstract?:
{{cite conference |last= Walsh |first= Toby |date= 2009-07-11 |title= Where Are the Really Hard Manipulation Problems? The Phase Transition in Manipulating the Veto Rule |pages= 324–329 |url= https://www.ijcai.org/Proceedings/09/Papers/062.pdf |conference= Twenty-First International Joint Conference on Artificial Intelligence |publisher= [[International Joint Conference on Artificial Intelligence|IJCAI Organization]] |location= Pasadena, California |conference-url= https://www.ijcai.org/proceedings/2009 |df= dmy}}
Walsh, Toby (11 July 2009). Where Are the Really Hard Manipulation Problems? The Phase Transition in Manipulating the Veto Rule (PDF). Twenty-First International Joint Conference on Artificial Intelligence. Pasadena, California: IJCAI Organization. pp. 324–329.  — sbb (talk) 14:45, 5 October 2021 (UTC)[]
The paper is part of the proceedings and as such, its title in the template should not be italicized. The proceedings title should be italicized and since it is nominally the same as the title of the conference, |conference= is not necessary. So:
{{cite conference |last=Walsh |first=Toby |date=2009-07-11 |article=Where Are the Really Hard Manipulation Problems? The Phase Transition in Manipulating the Veto Rule |pages=324–329 |article-url=https://www.ijcai.org/Proceedings/09/Papers/062.pdf |title=Proceedings of the Twenty-First International Joint Conference on Artificial Intelligence |publisher=[[International Joint Conference on Artificial Intelligence |IJCAI Organization]] |location=Pasadena, California |url=https://www.ijcai.org/proceedings/2009 |df=dmy}}
Walsh, Toby (11 July 2009). "Where Are the Really Hard Manipulation Problems? The Phase Transition in Manipulating the Veto Rule" (PDF). Proceedings of the Twenty-First International Joint Conference on Artificial Intelligence. Pasadena, California: IJCAI Organization. pp. 324–329.
I used |article= here because there isn't a |paper= parameter (probably should be ...).
Trappist the monk (talk) 15:04, 5 October 2021 (UTC)[]
And nothing of the above has to do with the fact that the usage of {{sic}} is not an error and should not be flagged as such, regardless of the citation template, and also regardless of how {{sic}} outputs. The COinS notice at the {{sic}} page is irrelevant. Instead of forcing human editors to comply with limitations of software that has nothing to do with citing sources, the offending software should be fixed. All else is obfuscation, and as far as citations are concerned, a bug. 65.88.88.126 (talk) 15:26, 5 October 2021 (UTC)[]
Not a bug. {{sic}} outputs HTML character entities. That is not allowed in COinS-generating fields.  — sbb (talk) 15:54, 5 October 2021 (UTC)[]
(edit-conflict) You are correct that this is not a bug. But since, I think, there is still something we could, possibly, improve in our template's behaviour, I'd like to point out that what triggers the error message here is the italic markup issued by {{sic}}, not the HTML character entities. The reason for why the template does not allow italic markup here is because this is typically an attempt to override the citation styling applied by the template itself (and one of the very purposes of these templates is to take the burden of styling away from editors and let the template do this work for them).
It could be argued, however, that matching pairs of italics in the middle of the parameter value might be "other markup" that should be accepted by the template. However, this would raise the question how to render it when the template applies italicization by itself as well. At present, the template removes italics and boldface from the parameter value before applying its own italicization.
Given that, applying italics (directly or through {{sic}}) in the parameter value would not cause any COinS problems - it's automatically stripped off...
What is a bit ironic here is the fact that the HTML entities, which are also produced by {{sic}}, can, while not causing the template to throw an error message, cause some mild issues for COinS consumers (so the red warning sign at {{sic}}'s documentation page is still appropriate), because what is transmitted as metadata could be considered to be overencoded:
%26%2332%3B%26%2391%3Bsic%26%2393%3B
for
&#32;&#91;sic&#93;
which will be correctly displayed by a HTML engine at the receiver's end as:
[sic]
It would be better if we would carry out this decoding of HTML entities into Unicode before we make it part of the metadata, so that, percent-encoded, we would just transmit:
%20%5Bsic%5D
and the receiver could read the data as plain text and would not have to use a HTML engine to decode it. Also, we could (almost) consider {{sic}} to be a CS1/CS2-compatible template then, which, although not necessary in this specific example case, would still be an improvement in the general case.
Almost, because the template would still complain about the italics markup created by {{sic}}. Since the citation template sees the output of templates like {{sic}} rather than the template itself, the only direct fix for this would be to allow italics markup in the middle of parameter values which would not accept it when applied to the value as a whole. Another possible solution could be to make templates such as {{sic}} "visible" to CS1/CS2 through a tricky variant of the "template internal metadata" scheme proposed in another thread: For this, a template like {{sic}} would emit some special kind of invisible metadata, but not to improve CS1/CS2's COinS output but simply to communicate a message like "Hi CS1/CS2, the italics markup you are seeing right now is not user-generated, but was issued by me, sic. You do not need to issue an error message for it, my output is known to be CS1/CS2-compatible." Perhaps this sounds complicated, but implementation-wise it could be a simple <span> setting an invisible flag. CS1/CS2 would just strip off the span, when present, and take advantage of the hidden information provided by subordinate helper templates like {{sic}} to improve its own behaviour.
--Matthiaspaul (talk) 22:21, 5 October 2021 (UTC)[]
Of course, this would not work in cases where the real parameter value would actually contain HTML entities like a hypothetical title "Study on HTML entities like &szlig; in citation templates", which the template would then interpret as "Study on HTML entities like ß in citation templates" instead of leaving it as it is. The question is how likely it is for parameter values to mean HTML entities verbatim rather than them being the result of some (unnecessary or deliberate escape-)encoding earlier down the chain. In parameter fields like those for periodicals (as in the OP's example here) I think it is extremely unlikely that a HTML entity string would be meant as plain text rather than as the character it encodes, whereas in a |title= field there is a higher possibility that it might occur as text, although still rarely. So, if we'd implement this "HTML entity decoding before percent-encoding", the HTML decoding should probably depend on the actual parameter the HTML entity was found in or be disabled when ((accept-this-as-it-is)) syntax is used as well. If we would want to improve the compatibility with specific templates (like {{sic}}) only it would also be possible to try and change them to not issue HTML entities in the first place. This might not be possible for all such templates, but in the specific case of {{sic}} it seems as if it could just issue [sic] instead of &#32;&#91;sic&#93;. This would not be an improvement for the general case, though.
--Matthiaspaul (talk) 09:55, 6 October 2021 (UTC)[]
While this does not improve the general case, I have meanwhile modified {{sic}} so that it no longer emits any HTML entities (except for, newly, &nbsp; which CS1/CS2 converts into a normal space internally, so it doesn't show up as a HTML entity in the metadata). Since CS1/CS2 also strips off italics ('') and boldface ('''), {{sic}} could now be considered COinS-safe.
However, CS1/CS2 doesn't "know" that and (unnecessarily) still throws an error for the italics issued by {{sic}}. Unless we would want to allow matching pairs of italics markup in the middle of parameter values which do not allow italics markup for the value as a whole, there is no way for CS1/CS2 to detect this, as it does not "see" {{sic}}, only its output. To illustrate my "communication through metadata" proposal I have changed sic's sandbox ([30]) so that it issues an invisible metadata span:
<span class="MeTaDaTa:safe-italics::"> normal_output_of_template_sic </span>
containing the special token "safe-italics" which would tell CS1/CS2 that these particular italics are okay to accept and that it should not issue the error message. If we would enhance CS1/CS2 to look for this and strip off the span when found before further processing, {{sic}} could be made fully compatible with CS1/CS2.
In this particular case, we do not need to issue alternative metadata text, hence the metadata text that was following the "::" in the other examples above is empty. In other cases, we may need to support a number of other tokens (TBD), so the "MeTaDaTa" string could accept a list of optional tokens in addition to the actual metadata. The general syntax could be something like: <span class="MeTaDaTa[:token1][:token2]...::[metadata]"> normal_output_of_template </span>
IIRC, % was not an allowed character in a class name in HTML4, so if we would still have to support HTML4, we would have to replace all % in the percent-encoded metadata by one of the (few) allowed chars (not used for other purposes already). On the other hand, if we can assume HTML5, this precaution would not be necessary and we could further improve the token syntax (i.e. to become K/V pairs, look nicer and be easier to parse). TBD.
--Matthiaspaul (talk) 19:37, 6 October 2021 (UTC)[]
I've never come across that. AFAIK in both HTML 4 and HTML5, the only character that can't be used in a class name is the space, because it's the separator in a list of class names (e.g. class="wikitable sortable" is two classes, not one). Some other characters shouldn't be used in class names because they may have special meaning elsewhere - for example, if you want to use a class name in the selector of a CSS rule, that class name shouldn't use characters that have special meaning in selectors, and percent is not among those. --Redrose64 🌹 (talk) 13:00, 7 October 2021 (UTC)[]
Thanks, Red, for your feedback. I, too, haven't run into this in practice, but in HTML 4, the allowed characters in a class name were still severely limited at least in the spec (letters, digits, "-", "_", ":", "." per [31]) whereas in HTML 5 there are almost no restrictions any more. There are still limitations for CSS, but they won't affect us. Would there be restrictions in conjunction with JavaScript (not a use case at present either, but could be one in the future)? Still, the main question is if we need to worry about HTML 4 at all or can just assume that the browser will support HTML 5.
--Matthiaspaul (talk) 17:41, 7 October 2021 (UTC)[]
I think that you are reading the entry for ID and NAME tokens as if it is a continuation of the entry for CDATA. It's separate. --Redrose64 🌹 (talk) 19:45, 7 October 2021 (UTC)[]
Am I? Now I'm confused. ;-) Basically I read:
"ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".")"
--Matthiaspaul (talk) 21:15, 7 October 2021 (UTC)[]
Yes, I thought as much. That's the part relevant to the id= and name= attributes, not the class= attribute, for which only the CDATA bullet is relevant. See section 7.5.2. --Redrose64 🌹 (talk) 22:33, 7 October 2021 (UTC)[]
Now I want to try defining some class names that include character entities! ;-) isaacl (talk) 23:03, 7 October 2021 (UTC)[]
COinS-generating fields should adjust their behavior to the requirements of human editors, and not the other way around. {{sic}} provides a common way of flagging significant information (apparent but not actual editor typos), used in citation systems from way before software metadata was even a concept. If the facility (the template {{sic}}) exists but it does not work, it is a bug as far as citations are concerned. 65.88.88.91 (talk) 19:30, 5 October 2021 (UTC)[]
Then since CS1/2 templates generate COinS metadata, and COinS data fields can't take HTML markup, and the base requirement seems to be able to use arbitrary templates you want in citations, the conclusion is to not use {{cite xxx}} or {{citation}} templates, and manually format citation data. Those templates are not required to be used.  — sbb (talk) 20:00, 5 October 2021 (UTC)[]
It doesn't follow. A more obvious solution is not to use COinS, since it generates false citation errors. 65.88.88.91 (talk) 20:27, 5 October 2021 (UTC)[]
You can choose not to use COinS by not using CS1/2 templates. Meanwhile, I hope that CS1/2 templates continue to support (and improve their support for) COinS.  — sbb (talk) 22:10, 5 October 2021 (UTC)[]

I don't think this is how it works at all. Citation modules & templates are there to support citations in order to apply Wikipedia policy. They don't exist to support COinS or any other scheme. Artificially limiting editors of citations because some foreign code has problems is contrary to both spirit and letter of policy. The citation system has enough issues of itself. It certainly does not need the additional problems brought on by external code. 68.173.76.118 (talk) 00:46, 6 October 2021 (UTC)[]

What external code are you talking about? All that COinS is is a metadata format encoded as an attribute to an HTML <span> tag. CS1/2 templates generate COinS metadata based on the content of certain fields. That's it. There's no external code. Wikipedia is probably the largest generator of COinS metadata for citations on the web. External sites and projects are COinS consumers of WP's data. Wikipedia has chosen to take on the responsibility of producing machine-readable citation data, and it only makes sense to support it when CS1/2 citation data is already declared as sets of key-value pairs.  — sbb (talk) 02:09, 6 October 2021 (UTC)[]
Of course there is external code, the metadata format add-on. Which is fine, as long as it doesn't interfere with the data itself. And here, there is interference. It is not right for the data to be secondary to metadata. Secondly, the responsibility of Wikipedia is to its human readers. The policies afaik are designed with that audience in mind. Machine readers are secondary. That is the platform. If the metadata scheme cannot keep up with these fundamental items it should be either fixed, replaced, or discarded. It's not as if Wikipedia is a restricted property. All native data can be easily accessed. The main thing is, program for humans (non-expert humans) first. I suggest devising a better scheme that follows these priorities. In the meantime, all COinS -generated "errors" should be removed from the CS1/2 UI. We can't wait forever. The status quo is an excuse to never fix what should be fixed. 64.18.9.197 (talk) 11:49, 6 October 2021 (UTC)[]
Hmm. That's really confusing, just reading {{cite conference/doc}}: title: Title of source. .... What you say also appears to contradict the Example case in the docs.
|article= isn't listed in the "Full parameter set in vertical format" list in Usage just before Examples. Also, would |book-title= be the title of the published proceedings? book-title: The title of the published version of the conference proceedings, written in full. May be wikilinked. Formatted in italics. (Not to be confused with conference, below.)
I guess there's 2 ways to use {{cite conference}}: 1. Citing a paper submitted for the conference. I assume this is what's most commonly used. 2. Citing the proceedings itself, as a work. When editing, I generally assume |title= in any {{cite xxx}} template is the title of the work I'm referring to, and I don't care if the title is italicized, quoted, etc. (because the choice of cite template does that for me). So from a principle of least surprise, I would expect to use |title= for this citation (unless, of course, my assumption that use case 1. is not the most commonly-used one).
If possible, I propose that |title= be quoted, not italicized, if |book-title= (or perhaps better named, |proceedings-title=) is also defined. Otherwise, if only one is given, italicize |title=. Is that reasonable?  — sbb (talk) 15:38, 5 October 2021 (UTC)[]
That would make it mirror {{cite encyclopedia}}'s behavior, I guess.  — sbb (talk) 15:46, 5 October 2021 (UTC)[]
For a long time I have been saying that we ought to rewrite {{cite conference}}. Maybe someday we will. In the normal case I wouldn't have rewritten your citation as I did except that you included a link to the proceedings and |book-title= doesn't have a matching url parameter.
When I use {{cite encyclopedia}} I tend to avoid |title= and use |entry= and |encyclopedia=. I can imagine something similar for {{cite conference}} (which perhaps should be {{cite proceedings}}) so |prceedings= and |paper=. |conference= should go away.
Trappist the monk (talk) 22:34, 5 October 2021 (UTC)[]
Is |book-title= where |booktitle= went??! I remembered that booktitle used to work and at some point stopped working, but didn't remember why. This constant churn in parameter names needs to stop. —David Eppstein (talk) 01:45, 6 October 2021 (UTC)[]
Yes, it was deprecated and replaced entirely early in 2021. Unhyphenated multi-word parameters were on their way to complete elimination as part of a multi-year project, and then a small group of loud editors showed up with pitchforks. I think there are six left, out of an original population of dozens of different unhyphenated multi-word parameters and about 300 total parameters. Maybe someday there will be consistency in CS1 parameter naming, but probably not soon. – Jonesey95 (talk) 05:18, 6 October 2021 (UTC)[]

A workaround suggested by Trappist the Monk was

I consider this incorrect. "[Jont]" means that the source wrote something a little different, and the Wikipedia editor saw fit to change it. Such changes are often made when it's necessary to change the capitalization or number of a word at the beginning of a quote.

In this case, "Jont" is what was actually written in the source. If it's necessary to draw attention to the misspelling it should be written "Jont [sic]". If the sic template is misdesigned, why not just write "[sic]". Jc3s5h (talk) 17:43, 5 October 2021 (UTC)[]

The sic template does not seem mis-designed. What is mis-designed is the citation module, which flags errors that have nothing to do with citations. This whole discussion belongs to the COinS pages, not here. As all kinds of inadequate bots and abuse-prone facilities such as AWB and JWB go around "correcting" stuff, it is important for the sic template to be there, since it signals to such software that these are not transcription errors. 65.88.88.91 (talk) 19:36, 5 October 2021 (UTC)[]
{{sic}} is merely a markup template. Nothing more, nothing less. Much like {{em}}, {{mono}}, {{math}}, and hundreds others. The mis-design is in catering to overly simple regex-driven bots to parse both syntax and language. I'm pretty sure bots like MOS Typo Team ignore anything in cites anyways.  — sbb (talk) 19:52, 5 October 2021 (UTC)[]
I agree with Trappist and Jonesey above that this is much ado about nothing. This is the sort of error that should be silently fixed, not proclaimed to the world as an error. We're here to identify references, not to exactly reproduce obvious and minor typographic issues. In this case, the typo isn't even by the conference proceedings publisher (https://www.ijcai.org/proceedings/2009/ lists its name correctly) but in the database of a third party, the ACM digital library. And, as sbb pointed out, the much bigger problem here is the use of the journal citation type for a conference paper. —David Eppstein (talk) 20:01, 5 October 2021 (UTC)[]
Yes, if the typos are not in the original paper but were introduced in ACM's page, we should not be perpetuating that error but going back to the original for the true spellings. --Redrose64 🌹 (talk) 20:21, 5 October 2021 (UTC)[]
Disagree, on the general case. This goes contrary to all citation practice. A typo or any other artifact that is not a transcription error has to be presented as is. It should not be arbitrarily "fixed" for any reason, least of all to comply with inadequacies in programming. What can/should be done so as not to confuse citation readers (and secondarily assorted Wikipedia bots), is to signal the obvious discrepancy. This has been done in citations (and cataloguing) for a very, very long time, using the sic notation in most cases. Also, "fixing" of any field, especially one that is indexed in reference databases, may make the item harder to find. 65.88.88.91 (talk) 20:39, 5 October 2021 (UTC)[]
This opinion should be raised at the talk page for MOS:CONFORMTITLE, not here. In the meantime, I have written to the ACM Library to alert them to the typo so that they can make this issue truly moot. – Jonesey95 (talk) 21:29, 5 October 2021 (UTC)[]
It seems that all the references to citations at MOS:CONFORMTITLE presuppose following the limitations of COinS, which is the actual issue here. Once citations are rid of the so-called COinS-generated "errors", MOS:CONFORMTITLE can be edited to remove the erroneous information. 65.88.88.91 (talk) 21:47, 5 October 2021 (UTC)[]
Fair enough regarding the notes about syntax errors caused by templates in COINS. There are a few dozen different types of templates listed at Category:Templates not safe for use in citation templates, many of which interfere with export of COINS information. Maybe it is COINS that needs to be fixed somehow. I don't know enough about that system to say anything smarter than that about it, though. Is it CS1's job to fix COINS in some way? I don't know. – Jonesey95 (talk) 21:55, 5 October 2021 (UTC)[]

Thanks everyone for your input. A good read. And thanks to Trappist the monk for the red warning reminder. I think that I had forgotten about that as {{sic}} usage in {{cite web}} works so well. Interesting points about it being ACMs error as I was sure I had found a PDF from the conference publishers where all the page footers contained the 'jont' error however can no longer locate. The original paper exists elsewhere and is fine. Jonesey95's request to ACM has had immediate results, they have fixed their typos, so the article link item will need a further edit. When I have made requests to Google to fix, say, book titles, I have often received a quick response from a real person acknowledging the request however there is usually a six month wait before actual correction. I think the point made about the level of reference and error needs further discussion. I have often taken the stance that if the original material is correct then it doesn't deserve to be 'besmirched' by a subsequent incorrect reference by a third-party. Perhaps that stance, 'silently fixing' such errors is incorrect. The point made about the ability to search for a catalogued misspelled reference would seem valid. Quite often the refs in error tend to be newspaper based which may reflect the extensive use of OCR. Neils51 (talk) 11:23, 11 October 2021 (UTC)[]


Related edits to the sic template

@User:Matthiaspaul - pls revert your edit @ this template. The nowiki tag you added is messing things up. I have commented at that talk page too. 65.88.88.69 (talk) 19:45, 6 October 2021 (UTC)[]

Can you please give examples where you saw things messing up?
--Matthiaspaul (talk) 19:56, 6 October 2021 (UTC)[]
The other thread would be Template talk:Sic#sic and CS1/CS2 citation templates, just in case someone would reply there as well. --Matthiaspaul (talk) 20:05, 6 October 2021 (UTC)[]
I don't know if this is the right place to continue this, but the nowiki tag interfered with the processing of optional parameters (now reverted by Izno). 65.88.88.69 (talk) 20:20, 6 October 2021 (UTC)[]
The following would not be processed correctly:
{{sic|wrong spelling|expected=correct spelling|nolink=y}}
65.88.88.69 (talk) 20:24, 6 October 2021 (UTC)[]
What is it (please be more specific) that is not processed correctly?
abc {{Template:Sic/sandbox|wrong spelling|expected=correct spelling|nolink=y}} xyz
abc wrong spelling [sic] xyz
Can't see anything going wrong in the case above and any of my test cases so far... Perhaps some additional trigger condition? On which page did you see things going wrong?
--Matthiaspaul (talk) 20:52, 6 October 2021 (UTC)[]
Please use Template:Sic/testcases for test cases so that everyone can follow along. – Jonesey95 (talk) 21:26, 6 October 2021 (UTC)[]
This template does not need to be edited, there is nothing wrong with it. What needs to be fixed is the metadata scheme. I would direct my energy there, instead of putting out fires whenever a legitimate use conflicts with COinS. Enthusiasm and willingness to tackle issues are commendable, but the execution should match, and solutions should be applied where there are actual problems. This is stated with no sense of criticism. 64.18.9.200 (talk) 23:51, 6 October 2021 (UTC)[]

Specify separate URLs for an encyclopedia and its article?

{{Cite book |title=A Book |section=A Section |section-url=https://example.org/book/section |url=https://example.org/book}}
"A Section". A Book.
{{Cite encyclopedia |work=An Encyclopedia |title=An Article}}
"An Article". An Encyclopedia.

Citing a section or chapter in a book and citing an article in an encyclopedia seem similar, but in the latter case, as far as I see, one can't give a URL for the work as a whole in addition to a URL for the individual article. Is there a way to do so? If not, would it be desirable?

2d37 (talk) 11:00, 6 October 2021 (UTC)[]

Did you try this:
{{Cite encyclopedia |encyclopedia=An Encyclopedia |entry=An Entry |entry-url=https://example.org/encyclopedia/entry |url=https://example.org/encyclopedia}}
"An Entry". An Encyclopedia.
or, do I not understand the question that you are asking?
Trappist the monk (talk) 11:19, 6 October 2021 (UTC)[]
Ah, that is just what I wanted, thank you. I failed to notice |entry= and |entry-url=, which don't appear to be very documented (or maybe I am just continuing to miss them). I'll add an example to the {{cite encyclopedia}} documentation, in case it will help the next editor who wants this. —2d37 (talk) 12:24, 6 October 2021 (UTC)[]
What about {{cite conference}}? |entry= seems to be an alias for |section=. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:55, 6 October 2021 (UTC)[]
Yep, |article=, |chapter=, |contribution=, |entry=, and |section= are all aliases of each other.
The original wikitext version of {{cite conference}} was written differently from {{cite encyclopedia}} (which is different from other cs1 templates). When we converted all of the individual cs1|2 templates to use Module:Citation/CS1, the goal was to be transparent. {{cite conference}} is still more-or-less as it was because no one has taken the time to propose a suitable rewrite.
To make {{cite conference}} link both the paper and the proceedings this works:
{{Cite conference |title=Conference Proceedings |article=A Paper |article-url=https://example.org/encyclopedia/article |url=https://example.org/proceedings}}
"A Paper". Conference Proceedings.
Trappist the monk (talk) 15:45, 6 October 2021 (UTC)[]
Ah, I had been using |title= and |url= for the article and |conference= and |conference-url= for the conference, but I see now that that makes the article title italic, whereas |article= makes the article title quoted, as it should be. —2d37 (talk) 06:42, 8 October 2021 (UTC)[]

Specify multiple URLs for newspaper clippings?

Newspaper stories sometimes span pages. When I make a clipping on newspapers.com, it's of a single page, and I have to make a separate clipping for the continuation of the story on another page. Is there a way to provide both clipping URLs in cite news? Right now, I'm doing a work-around of putting two cite news templates between one set of ref tags, and am just wondering if there's a cleaner method.

Example: <ref name=dart>{{cite news | newspaper=The Los Angeles Times | date=May 9, 1981 | page=30 | url=https://www.newspapers.com/clip/86484817/way-station/ | access-date=October 4, 2021 | title=Bookstore Offers a Way Station for Minds | last=Dart | first=John}} {{cite news | newspaper=The Los Angeles Times | date=May 9, 1981 | page=31 | url=https://www.newspapers.com/clip/86484854/way-station2/ | access-date=October 4, 2021 | title=Bookstore Offers a Way Station for Minds (continued) | last=Dart | first=John}}</ref>

Schazjmd (talk) 15:29, 6 October 2021 (UTC)[]

Link the page numbers in |pages=:
{{cite news |newspaper=The Los Angeles Times |date=May 9, 1981 |pages=30, [https://www.newspapers.com/clip/86484854/way-station2/ 31] |url=https://www.newspapers.com/clip/86484817/way-station/ |access-date=October 4, 2021 |title=Bookstore Offers a Way Station for Minds |last=Dart |first=John}}
Dart, John (May 9, 1981). "Bookstore Offers a Way Station for Minds". The Los Angeles Times. pp. 30, 31. Retrieved October 4, 2021.
Trappist the monk (talk) 15:48, 6 October 2021 (UTC)[]
Brilliant! Thanks, Trappist the monk. Schazjmd (talk) 16:03, 6 October 2021 (UTC)[]

Publisher separates volume/issue numbers from journal name

If a |publisher= is included in {{cite journal}} (as unusual as that may be), it is inserted between the journal name and the volume and issue numbers:

{{cite journal |last1=Uthor |first1=A. |title=Reconsidering gizmos |journal=International Rehashing |volume=45 |issue=123 |publisher=Springervier <!--maybe to distinguish it from the more famous "International Rehashing" journal published by Elsespringer?-->}}
Uthor, A. "Reconsidering gizmos". International Rehashing. Springervier. 45 (123).

Is this a bug? With the bolded volume number I suppose it's not so confusing, but it seems more confusing if there's no volume number:

{{cite journal |last1=Uthor |first1=A. |title=Reconsidering gizmos |journal=International Rehashing |volume=<!--this journal doesn't use volume numbers--> |issue=123 |publisher=Springervier}}
Uthor, A. "Reconsidering gizmos". International Rehashing. Springervier (123).

In that case, there seems to be little cue that the (123) is an issue number. I would expect this placement...

Uthor, A. "Reconsidering gizmos". International Rehashing (123). Springervier.

...but perhaps there's some known problem with that of which I wouldn't know.

2d37 (talk) 09:05, 12 October 2021 (UTC)[]

Is it a bug? Probably not. Before its conversion to {{citation/core}}, the wikitext version of {{cite journal}} rendered your example citations as:
"Reconsidering gizmos" . International Rehashing 45 (123). Springervier.
"Reconsidering gizmos" . International Rehashing (123). Springervier.
yes the author is omitted because that version of the template does not understand enumerated parameters
The next and subsequent versions of the template used {{citation/core}} until the conversion to lua. At the time of the lua conversion, the new lua version of the template was intended to be indistinguishable from the wikitext template and, for your examples, still is:
Cite journal comparison
Wikitext {{cite journal|first1=A.|issue=123|journal=International Rehashing|last1=Uthor|publisher=Springervier|title=Reconsidering gizmos|volume=45}}
Old Uthor, A.. "Reconsidering gizmos". International Rehashing (Springervier) 45 (123). 
Live Uthor, A. "Reconsidering gizmos". International Rehashing. Springervier. 45 (123).
Cite journal comparison
Wikitext {{cite journal|first1=A.|issue=123|journal=International Rehashing|last1=Uthor|publisher=Springervier|title=Reconsidering gizmos}}
Old Uthor, A.. "Reconsidering gizmos". International Rehashing (Springervier) (123). 
Live Uthor, A. "Reconsidering gizmos". International Rehashing. Springervier (123).
Was there discussion that determined the placement of |publisher= in the {{citation/core}} version? Don't know. I suspect that the subject did not come up or if it did, was deemed acceptable because |publisher= use in {{cite journal}} is comparatively rare.
Trappist the monk (talk) 11:23, 12 October 2021 (UTC)[]
A likely answer for the placement of publisher has to do with the |edition=. This is a guess. Normally the edition info would follow the title, and then the edition's publisher would follow. It is not unusual for works to have editions by different publishers. Then the particulars of the edition (volume etc.). 66.108.237.246 (talk) 11:58, 12 October 2021 (UTC)[]

Update parameter?

I'm copying this here as it's a good question:

Is there any guideline on which date to use when a source is updated, in some cases several times? I've searched "Help" in vain. This article, for example, was published on July 30, 2020, and updated on August 20. Do we keep the original date or use the date of the last update? Space4Time3Continuum2x

What should we do? Maybe we need an "update=" parameter? Please ping us. -- Valjean (talk) 15:50, 12 October 2021 (UTC)[]

@Space4Time3Continuum2x and Valjean: WP:SAYWHEREYOUGOTIT indicates that you should cite the date of the document that you read. If it was updated later, it may no longer supports the cited statement or it may support an entirely opposite statement (so cite the earlier date). Similar logic applies if you read it later and it does or does not support a particular statement (so cite the later date). Izno (talk) 16:20, 12 October 2021 (UTC)[]
That makes sense. When using a citation template, how would that work? Is the "access-date=" parameter enough, or would an "update=" parameter be a good thing, since the URL doesn't change when an article is updated. -- Valjean (talk) 16:29, 12 October 2021 (UTC)[]
Use |date=. – Jonesey95 (talk) 17:00, 12 October 2021 (UTC)[]
That parameter is the original publication date and does not account for later revisions and updates. The URL doesn't change. -- Valjean (talk) 17:14, 12 October 2021 (UTC)[]
Incorrect. That is the publication date associated with the work when you read it. --Izno (talk) 17:36, 12 October 2021 (UTC)[]
Is that always the case? It seems that the original publication date stays the same, and sometimes the update date is then added along with the notification of the update/correction, so "incorrect" may not always be true. I don't recall ever seeing an example of the original date being removed or changed. Do you have an example of the exception that proves the rule? -- Valjean (talk) 15:04, 13 October 2021 (UTC)[]
It is not relevant. You claim something in wikitext, and support the claim with a source that verified it on a certain date. If the source was updated and the wikitext claim is still supported as before, then the citation need not be changed. If the update no longer verifies the wikitext, the problem is not the citation, whose original date still supports the claim. In this case the wikitext should be edited: either state that "at a previous date/iteration/etc. such-and-such happened" or edit the wikitext with the updated information and edit the citation by inserting the corresponding version of the source. 65.88.88.46 (talk) 15:32, 13 October 2021 (UTC)[]
That is current practice. I'm suggesting we make that process smoother by including it as a parameter. I recognize that false claims and controversy surround such updates, and that we would, in such cases, still need to note that in the text, but such updates aren't always connected to any controversy. -- Valjean (talk) 15:42, 13 October 2021 (UTC)[]
??? Can you explain what you mean by "smoother"? If you need to present two different versions of events you would need two citations. This gives clarity to the wikitext claims. If you want to present one version of events, use the appropriately dated source. Citations have no continuity, and should not be treated as version repositories. You could always note, outside the citation that the information may no longer be current, but this seems convoluted. Unless the wikitext is historical update it, instead. 65.88.88.46 (talk) 16:12, 13 October 2021 (UTC)[]
In such convoluted cases, where different versions need sometimes-long explanation in the text, it would be handy to use one ref for the first/original version, and another ref for the updated version. That's all. That's what can be done with archived versions. It is actually possible to provide different dates and different URLs for different versions. With normal refs, the URLs don't change, but the ref, with an "updated" parameter, would be different, and should use a different refname. -- Valjean (talk) 18:28, 13 October 2021 (UTC)[]
Again, these convoluted cases are a wikitext issue, not a citation one. If the claims are convoluted, simplify them. If several versions must be included, each one needs a separate citation. There must be a one-to-one relationship between the claim in the text and its verification. You can use one citation to prove many claims (by citing different in-source locations like pages). You cannot use one citation to prove 2 different versions of the same claim, whether using the same date/edition or 2 or more dates/editions. Moving the convoluted aspect to the citation instead of the text where it belongs makes it harder to verify. Obfuscation ensues. 65.88.88.69 (talk) 20:20, 13 October 2021 (UTC)[]
No disagreement. It is the production of the "separate citation" I'm after to make the "one-to-one relationship between the claim in the text and its verification" easier. -- Valjean (talk) 17:21, 14 October 2021 (UTC)[]
I mean, I guess you can argue with me as to the correct use of the parameters, but as you are here asking the original question, that seems somewhat of a bait and switch as to your intent behind said question. :)
Yes, |date= is for the date of the source cited. If it has an amendment date and you read the source after that date, it goes in that parameter. There is 0 need for any additional parameters. Izno (talk) 19:05, 13 October 2021 (UTC)[]
I don't mean to argue with you, and certainly not to trick you. Sometimes tangentially-related ideas get dealt with in the same thread. I'm just trying to learn the right way to do things. I've been here since 2003 and am still learning.
It doesn't make sense for the date in the date= parameter to change with varying versions, except for books, which is not the topic here. I've never heard of that being done. The original date never changes, which is why any updates that affect content here should be noted. Currently, we do that in the text. I'm interested in seeing that done with a new "updated" parameter. Can that be done? -- Valjean (talk) 19:17, 13 October 2021 (UTC)[]
At the end of the day, it's fundamentally just a new edition of the same work, which as with books ends up being a differently dated citation. So your 'except with books' is precisely the case here.
I would oppose a new parameter accordingly.
If you absolutely feel you must have both dates in the citation, put the later date in |date= and the earlier date in |orig-date=, contrary to what you believe it must be used for from 15:41 today. For most news articles those will not be separated by much so I see it as a waste of space in a citation section, but you seem convinced that you must do it the way you want. Izno (talk) 19:28, 13 October 2021 (UTC)[]
Speaking only about the current date= parameter, it's just disturbing to learn that, without knowing it, I might find a ref which gives a different date than the original publication date. That just destroys my trust in the accuracy of references. Do you have an example of a reference where the listed date is not the original date of publication? If you've been editing this way, you should be able to provide such an example. I have always trusted the date to be the original date, and I shouldn't have to look at archived versions at the Internet Archive to figure out the original publication date. The consequences of a discrepancy can be consequential, as news of something happening is normally almost immediate, depending on the topic. It's also important to be able to know which source was the first with the story. Being careless with the date screws up our ability to know what's happened. Should I start an RfC on this topic so we can formally establish the one-and-only proper way to do this? -- Valjean (talk) 20:07, 13 October 2021 (UTC)[]
Well, the only pertinent date is the one used in the version that verifies whatever is in wikitext. Whether that is the original date or not, is immaterial. If I may suggest, you are approaching this from the wrong end. Citations are there to prove that there is an actual source (hopefully reliable) for the wikitext and it is not the wiki editor's opinion or fancy, nothing else. And apart from that, there is always pre-emptive archiving. 65.88.88.69 (talk) 20:36, 13 October 2021 (UTC)[]
Whether I have an example to that effect is basically irrelevant. I do not think a change proposal to include another parameter would be successful. Regardless, there are many editors watching this page and I'm sure some are itching to respond to you, since you are not responsive to what I am telling you.
Your hyperbole in the latter half of the paragraph is noted, without response. Izno (talk) 20:40, 13 October 2021 (UTC)[]

Currently, we have these three, tweakable, basic parameters for website and newspaper articles |date=, |access-date=, |archive-date=. Note that |orig-date= is used for things like books, not for website and newspaper articles.

I am proposing we have an |updated= parameter for use when an update or correction has been made to a website or newspaper article or document. -- Valjean (talk) 15:41, 13 October 2021 (UTC)[]