Wikipédia:Esplanada/propostas/Padrão para campos de infobox (13mai2011)

Padrão para campos de infobox (13mai2011)

A falta de um padrão consensual sobre os nomes dos campos de infoboxes muitas vezes dificultam a manutenção das mesmas, por isso proponho o seguinte padrão:

• Em nomes de campos de infoboxes com duas palavras, as palavras devem ser separadas por espaço e a ordem das palavras devem seguir a ordem gramatical correta da língua portuguesa.

Atualmente, muitos campos de infoboxes, quando usam nomes com duas palavras, usam traço "_" e na ordem "sujeito_objeto", provavelmente isso aconteceu durante as traduções das predefinições da anglófona, por exemplo, "flag_size" virou "bandeira_tamanho". Não vejo nenhum motivo para usar o traço, o espaço não cria nenhum problema nem no software nem para a busca dos campos, e é melhor que se use a concordância normal do português, "objeto sujeito", no exemplo seria "tamanho bandeira". ^Danilo.mac_(discussão) 20h45min de 13 de maio de 2011 (UTC)

Não dava para ser mais imparcial? Primeiro introduzir a situação e colocar os dois padrões existentes e só depois dizer a sua opinião sobre o assunto?

• Em nomes de campo de infoboxes com duas palavras, as palavras devem ser separadsa por _ e a ordem das palavras segue o padrão assunto_característica

Assunto_característica: visualmente, qnd se olha o código e vê na esquerda três "imagem" já sabe que ali é o bloco de imagem. E logo depois um bloco de "bandeira", um bloco de "nascimento", de morte, etc. Com o assunto a esquerda os blocos se destacam e fica mt mais fácil de achar os campos vendo assim. Em alguns casos de usa <!--linha de comentário--> para fazer a separação, mas usar isso sempre é inviável. Mts campos andam em pares / trios (valor, data, ref), e colocar uma linha de comentário para cada grupo é divisão em excesso. Isso também segue a recomendação de organização do título das infoboxes como "Info/tema/item" (conforme documentação da {{Info}}).

O _ sendo usado nos campos tb ajuda a identificar o campo em casos que o conteúdo dos campos é grande e fica passando pra linha de baixo. Com várias linhas de texto, procurar um _ é algo fácil de fazer, e onde tem _ tem campo. Iniciar com | pode ajudar mas mt pouco, é muito mais fácil achar um _ que | , sem falar das vezes em que há predefs dentro dos campos como a {{dni}} ou {{dtlink}} (só para citar exemplos) e assim o campo também fica com | , com a linha debaixo podendo também ter o | . O _ também distingue "palavra1_palavra2" como campo e "palavra1 palavra2" como texto normal, simplificando bastante o uso por bots, scripts e outros. Edições automáticas / semi-automáticas que troquem "pal1 pal2" por "pal3 pal4" (por qualquer motivo, como uma tradução, correção de uso indevido, redirect, fusão, criar link interno, remover, sempre pode ter um caso desses) teriam problemas se "pal1 pal2" for um campo da predef, causando erro ou exigindo um excesso de atenção/verificação manual (Ex, colocar sempre link interno em "vila ninja" quando estiver antes da primeira seção, fácil de fazer se isso não puder nunca ser um campo de infobox)

Ser a concordância normal do português pode ser útil mas tem pouco peso, seria algo útil se fosse para escrever os campos mas a maioria esmagadora das vezes se copia o esqueleto não se cria do nada então não faz diferença alguma se segue a concordância normal ou não. Também temos milhares de exemplos de campos que não usam a concordância, usando nomes mais curtos (de 1 / 2 letras apenas), em inglês, maiusculas, temos até os consagrados {{navbox}} que são em inglês e assim são contra as regras mas nem por isso teve sugestão de mudança pq isso tem mt pouco peso. Se for seguir o modo correto de escrever ao invés de "tamanho bandeira" deveria ser "tamanho da bandeira" ou as preposições não são mais parte das regras? E isso entra no problema antigo, é de/da/do ou em/na/no, essas confusões dificultam o uso de campos assim.

Rjclaudio ^msg 21h01min de 13 de maio de 2011 (UTC)

Os campos com uma única palavra nunca têm o "_" e nunca vi ninguém se queixar que isso dificulta na edição. Bem, já deixei a minha opinião, aceito aquilo que a maioria decidir, o importante é definir um padrão para facilitar a manutenção das predefinições. ^Danilo.mac_(discussão) 21h54min de 13 de maio de 2011 (UTC)

Pra que criticar se não há alternativa para campos com uma palavra? O jeito é deixar os scripts mais complexos. Agora se há uma alternativa pra facilitar o trabalho aí sim pode criticar. Rjclaudio ^msg 21h57min de 13 de maio de 2011 (UTC)

Se é melhor que se use o português normal, pq remover as preposições? Pq usar a regra do portugês normal apenas quando há interesse para apoiar uma proposta e ignorar quando vai contra a proposta? Rjclaudio ^msg 21h59min de 13 de maio de 2011 (UTC)

Como você mesmo disse, as preposições poderiam causar problemas, já a ordem eu não vejo motivo para não seguir a concordância correta, eu pelo menos nunca tive nenhum problema em achar os campos, mas se acharem que "assunto_característica" facilita a edição, por mim tudo bem, como eu disse, o importante é ter um padrão. ^Danilo.mac_(discussão) 22h28min de 13 de maio de 2011 (UTC)

Eu não vejo como alguém pode achar que ter "assunto_característica" vai prejudicar a edição de algum jeito. Quem ler vai entender, quem usar vai copiar, quem se acostumar não vai nem notar que está diferente. Não vejo prejuízo, e há pessoas que acham que traz benefício.

Pelo prejuízo zero e possível benefício mais vale usar "assunto_característica" que usar "característica assunto".

Rjclaudio ^msg 22h31min de 13 de maio de 2011 (UTC)

Sinceramente, qual seria a importancia disso? MachoCarioca ^oi 00h04min de 14 de maio de 2011 (UTC)

Em Wikipédia:Coordenação robótica/Localidades estamos juntando correções que devem ser feitas por robôs nas infoboxes sobre localidade, mas antes de qualquer correção precisamos padronizar as infoboxes sobre o assunto para determinar os padrões que o robô deverá seguir. Quaisquer futuras correções também seguiriam o mesmo padrão definido aqui. ^Danilo.mac_(discussão) 00h21min de 14 de maio de 2011 (UTC)

• (Conflito)
• Facilidade para os bots/ferramentas fazerem o trabalho deles. Que por sua vez facilita os usuários a fazerem o trabalho deles.
• Pegando um exemplo da sua área, Info/Astronauta e Info astronauta (redirect de infobox tb atrapalha, infobox com 10 redirects então). Acho que as duas tabelas ajudariam a manutenção.
• Pegando um exemplo prático: astronautas nascidos na década de 1960
• E dá pra variar os critérios de busca / campo. Só que se tiver 10 campos para a data de nascimento o script não funciona. E fazer esse script ler 10 campos pra mesma coisa tornará o script mais lento / complexo.
• Rjclaudio ^msg 00h30min de 14 de maio de 2011 (UTC)

Existem duas infoboxes para astronautas?? MachoCarioca ^oi 00h46min de 14 de maio de 2011 (UTC)

Uma é redirect pra outra. Tem artigo que usa a certa e tem artigo q usa o reedirect. As duas são a mesma mas pro script são diferentes. Mais um problema da falta de padronização. Rjclaudio ^msg 00h54min de 14 de maio de 2011 (UTC)

Gostei de brincar com a tabela. Astronautas que fazem (ou fariam) aniversário hoje. Rjclaudio ^msg 00h55min de 14 de maio de 2011 (UTC)

• Subscrevo os argumentos do Rjclaudio quanto a usar assunto_característica, isto é, "bandeira_tamanho" em vez de "tamanho_bandeira". Creio que tanto a ordem como o traço facilitam a leitura e edição/codificação; não é por acaso que é raro que as linguagens de programação permitam o espaço para nomes de variáveis. --Stegop (discussão) 01h04min de 14 de maio de 2011 (UTC)

Parece-me mais lógico o assunto_característica, pois permite agrupar e assimilar melhor a informação. Já sobre o uso do _, concordo inteiramente com o rjclaudio, é o padrão usado nos maiores projectos precisamente porque trás mais vantagens. Em primeiro lugar, é mais fácil de identificar por exemplo, o erro de dois __ do que dois espaços, e ai o campo não funcionaria, depois, a aplicação do _ transforma várias palavras numa só, em termos de programação, ou seja, para um script, seja ele qual for, independentenemnte das palavras que ai constem, representam somente uma só, facilitanto os scripts que vão procurar esses campos, pois são mais simples. Além do mais, é mais seguro procurar por um assunto_caracteristica, ou vice versa, do que sem o _, porque ao usar o _ transforma quase automáticamente essas palavras num elemento que não pertence ao corpo do texto. Alchimista ^{Fala comigo!} 17h41min de 14 de maio de 2011 (UTC)

Com 3 dias, o Danilo é neutro, prefere o outro modo mas não faz questão, só quer um padrão. Não tem ninguém contra. Estamos quase na metade do tempo, mais 4 dias sem ninguém contra e teremos consenso. Rjclaudio ^msg 01h06min de 17 de maio de 2011 (UTC)

Completamente a favor da padronização de todos os campos possíveis nas infoboxes pelos motivos robóticos já expostos. OTAVIO1981 (discussão) 12h32min de 17 de maio de 2011 (UTC)

Com 10 dias, decreto então o consenso. Atualizando WP:Infobox, que é a mais específica que tem. Alguma outra página que pode conter essa informação? Rjclaudio ^msg 15h01min de 22 de maio de 2011 (UTC)

Pois é e é um absurdo a porcaria do traço pois não faz lá nada a não ser confundir, as defesas para a sua utilização são completamente absurdas e só existem porque os Velhos do Restelo que estão habituados a usar assim não são capazes de fazer de outra maneira e querem impor a forma deles de fazer as coisas, parabéns a todos os intransigentes, fiquem com a criação de todas as predefs e não se admirem do trabalho que isso vai dar. Pelo Poder do Z ^{Alaf Ogimoc} 17h15min de 23 de maio de 2011 (UTC)

O único argumento absurdo que vejo é o seu: "acho inútil", "acho que vai confundir", "acho que é pior". Opiniões pessoais sem base alguma. Todos os argumentos foram bem explicados, e muitos com base (ex: facilitar a automação). Não foi mostrado qual o prejuízo de se colocar o traço. Rjclaudio ^msg 17h28min de 23 de maio de 2011 (UTC)

NÃO NÃO HÁ CONSENSO, pelo simples facto de que primeiro, ainda não passaram 10 dias, segundo que eu saiba isso não é uma obrigatoriedade e terceiro, porque devido ao facto de esta decisão ter grande impacto em toda a wiki, não houve quórum para se poder tomar uma decisão. AGORA ESTAMOS NA DITADURA DAS MINORIAS É? Era só o que faltava que três ou quatro gatos pingados decidissem sobre algo que afecta toda a comunidade. Pelo Poder do Z ^{Alaf Ogimoc} 17h29min de 23 de maio de 2011 (UTC)

Não há necessidade de passar 10 dias, o costume é esperar no uma semana para incluir o fim de semana e permitir que todos os interessados tenham tempo hábil de opinar. Não tem quórum mínimo se ficou na esplanada/propostas pelo tempo necessário. Não se forçar as pessoas a opinar. E afinal qual seria o quorum mínimo pra não ser uma ditadura da minoria? nunca vi esse número em lugar algum. Não é obrigatoriedade enquanto não tiver regra, se tem regra passa a ser obrigatoriedade. A menos que a regra seja apenas uma recomendação, o que não é esse o caso. Rjclaudio ^msg 17h33min de 23 de maio de 2011 (UTC)

Já que dizem que não justifico... Começo por dizer que essa treta que diz ai em cima é outro absurdo, ou seja uma semana é tempo útil, francamente, tudo o que seja menos de 15 dias é absurdo e tentativa de fazer as coisas pela calada, nem todos estão agarrados 24h por dia à wiki como você, e sim, independentemente de não haver pessoas que queiram opinar, quando se mexe com algo desta importância, elas devem obrigatoriamente que opinar, e se não opinam passa-se para uma votação alargada, todas as decisões de fundo devem ter um numero mínimo de participantes senão podem ser contestadas, se não vejamos, neste caso, neste momento eu represento cerca de 20% contra o que é muito para um consenso, e voltando as justificativas, os argumentos para o uso do traço são absurdos pelo simples facto que se baseiam todops em gosto pessoal e não é factores práticos, exemplo: não é por acaso que é raro que as linguagens de programação permitam o espaço para nomes de variáveis, tal não acontece nas linguagens actuais, só acontecia nas antigas devido à incapacidade do compilador gerir mais de um objecto em simultâneo. Querem que eu desmistifique os outros absurdos ou já chega? a única coisa verdadeira nesta lenga lenga é que de facto é mais pratico, e não por nenhuma funcionalidade computacional, utilizar "Assunto Tema", outra que também é só por questão de padronização e não por necessidade computacional é o facto de se escrever apenas com minusculas, etc etc etc. Pelo Poder do Z ^{Alaf Ogimoc} 17h43min de 23 de maio de 2011 (UTC) PS: E parece que estou chateado não é? Não é de admirar, estive doente, não apareço cá por uma semana, e querem alterar tudo à toa e afirmam que 10 dias chegam para um consenso quando não levam em consideração que podem acontecer coisas que levem a que não se venha cá nesse período e mais ainda se contradizem pois ainda não passaram 10 dias e já estão a assumir que houve consenso.

Não existe numero mágico de editores a se apresentarem para dar seguimento com propostas de melhorias. O que se espera é que a discussão seja visível a todos pela esplanada e como não houveram questionamentos ou discordância impeditiva para dar continuidade ao trabalho, a coisa anda pra frente. Já teve proposta aqui aprovada num tempo muito menor e certamente os participantes foram uma minoria da comunidade e nem por isso foram contestadas posteriormente sendo o que interessa é o fundamento dos motivos. Já agora, gostaria de saber do Zorglub qual o impacto significativo para toda a comunidade visto que as infoboxes continuam a ser preenchidas do mesmo jeito, ou seja, nenhum bot irá rodar alterando todos os campos. A presença do maldito traço entre as palavras pode ser considerada inócua mas a importância de um robô entender que tudo que chama-se de data de nascimento é, por convenção, "data nascimento" ou "nascimento data" é de grande valia para automatizar suas funções. Se toda vez que for incluir uma nova infobox numa lista do bot, o script tiver que se curvar às nomenclaturas de cada campo este ficará gigante quando deveria ser exatamente o contrário: independente do nome que se aparece ou utiliza no preenchimento tudo que se entende por "data nascimento" tem o mesmo nome interno na INFOBOX que passa de modo uniforme ao script. OTAVIO1981 (discussão) 19h35min de 23 de maio de 2011 (UTC)

Na verdade, teria que alterar os artigos em si, não apenas a predefinição. Se cada artigo puder ter n variações do mesmo campo a infobox vai receber um valor para cada um dos n campos de nomes diferentes e o script vai ter que verificar os n campos. Rjclaudio ^msg 19h58min de 23 de maio de 2011 (UTC)

Desculpem lá, mas estão a usar scripts do século passado é? Agora anda-se de cavalo para burro? Todas as linguagens informáticas, compiladores e scripts, estão a optar o formato de linguagem natural e vocês querem retroceder para a década de 80? A transição deu-se na década de 90 sabiam? Já ninguém, pelo menos no seu completo juízo, a menos que vivam no passado, utiliza scripts ou linguagens que não suportem linguagem natural, e sinceramente, não acredito que os scripts usados na wiki não o suportem, pois a mesma foi criada já no século XXI, quando já ninguém usava essa treta do traço de ligação. MODERNIZEM-SE Pelo Poder do Z ^{Alaf Ogimoc} 17h28min de 25 de maio de 2011 (UTC)

Zorglub, em primeiro lugar aconselho o uso de linguagem menos agressiva, estamos a debater um assunto importante. Em segundo, creio que não percebes-te a vantagem do uso do _. Nãos e trata de um problema com as linguagens em si ou os seus compiladores, mas sim com a facilidade que trás ao adquirir e tratar a informação. É muito mais fácil, rápido e seguro lidar com elementos da forma "campo1_campo2" do que "campo1 campo2", p regex é mais fácil e simples, e a percentagem de erro é menor, porque é mais fácil visualizar um duplo __ do que duplo espaço. Além do mais, não é totalmente verdade que as linguagens informáticas tenham todas evoluido da forma como indicas-te, repara na tabela da BD da wikipédia, os indices surgem precisamente com o underscore, tal como na generalidade das operações envolvendo índices e valores. Isso acontece tanto no sql, como matlab, fortran, e isto para falar das com que estou mais familiarizado. Ou seja, não há um prejuízo para quem insere a informação, porque normalmente é copiada da página de documentação da predefinição, e há uma vantagem para quem lida com esses dados através de programas, e essa é a vantagem que temos em usar o underscore. Por fim, podes verificar que na en, DE, es, it, fr, ro ou nl não usam espaço nos campos, usam _, - ou simplesmente fazem a concatenação. Ora mesmo para quem possa não perceber explicitamente o porquê da vantagem, pelo menos fica mais fácil de concordar que realmente deve mesmo haver uma razão especial para nos maiores projectos ser prática recorrente pelo menos as principais predefinições e mais sujeitas a data-minning seguirem este formato.Alchimista ^{Fala comigo!} 14h30min de 27 de maio de 2011 (UTC)

Morreu a proposta? Rjclaudio ^msg 04h14min de 16 de junho de 2011 (UTC)