filipedeschamps / tabnews.com.br

Conteúdos para quem trabalha com Programação e Tecnologia.
https://tabnews.com.br
GNU General Public License v3.0
5.3k stars 390 forks source link

Contagem da quantidade mínima de palavras não leva em conta palavras acentuadas #1487

Closed hkotsubo closed 5 months ago

hkotsubo commented 1 year ago

A implementação do PR 1460 não leva em conta palavras acentuadas.

Atualmente é usado .split(/[a-z]{5,}/i) e verifica-se se o resultado tem menos que 6 elementos. Mas caso exista uma palavra com acentos ou cedilha, a contagem a desconsidera, mesmo que tenha mais que 5 caracteres.

Uma sugestão seria usar Unicode Property Escapes, e trocar split por match (assim o valor a ser comparado é exatamente a quantidade que queremos - < 5 em vez de < 6, um detalhe mínimo, mas que na minha opinião deixa mais semântico e diminui as chances de um off-by-one error):

if (newContent.body.match(/(\p{L}\p{M}?){5,}/igu).length < 5) {
    // tem menos que 5 palavras com 5 caracteres ou mais
}

O \p{M}? trata os casos em que a string está em NFD, assim não precisa normalizá-la.

Mas talvez esta solução seja abrangente demais, pois considera letras de outros alfabetos também. Como o site está restrito ao português, podemos considerar apenas caracteres latinos, trocando a regex para /(\p{Script=Latin}\p{M}?){5,}/igu.

Atualmente há um bom suporte dos browsers e runtimes para regex com Unicode Property Escapes, então não deve ter maiores problemas de compatibilidade.

Em todo caso, também poderia ser algo como /[a-záéíóúâôãõç]{5,}/ig. Mas isso não trata os casos em que a string está em NFD, então precisaria normalizar para NFC antes:

if (newContent.body.normalize('NFC').match(/[a-záéíóúâôãõç]{5,}/ig).length < 5) {
    // tem menos que 5 palavras com 5 caracteres ou mais
}

E claro que também poderia remover os acentos para depois fazer a contagem com [a-z], mas acho uma volta desnecessária, pois dá para fazer direto na própria string com acentos.

aprendendofelipe commented 11 months ago

Contagem da quantidade mínima de palavras não leva em conta palavras acentuadas

É verdade, mas isso foi deliberadamente feito assim porque acreditei ser algo simples e que teria um efeito melhor do que a proposta inicial de um "número mínimo de caracteres para ganhar tabcoins" https://github.com/filipedeschamps/tabnews.com.br/issues/1267#issuecomment-1615372170

Apesar de eu não estar considerando os caracteres acentuados, as palavras acentuadas serão contabilizadas se tiverem 5 ou mais caracteres antes (ou depois) do acento. Não há necessidade de exatidão nessa verificação, já que só estamos contando as maiores palavras.

Sobre a quantidade escolhida, eu tentei fazer passar na verificação alguns comentários curtos que vi no TabNews e que continham alguma mensagem útil. Vamos analisar o resultado e, qualquer coisa, mudamos esses limites.

A ideia não foi definir exatamente o que é um texto muito simples, mas criar alguma forma de apresentar a mensagem para os usuários que não estão familiarizados com o que esperamos das publicações no TabNews.

Teve um impacto positivo, por exemplo, nas mensagens de agradecimento que agora tentam também adicionar algo novo nas publicações.

Uma pena é que tem impacto limitado em quem usa o TabNews via API, como quem usa os Apps mobile da comunidade, pois não recebem o aviso para ler a publicação do Filipe, nem ao cair nesse regra, nem mesmo antes de fazerem a primeira publicação:

https://github.com/filipedeschamps/tabnews.com.br/blob/4e4d030cd4c0c2e240c96e5cfea16e43604aa223/pages/publicar/index.public.js#L24-L31

Rafatcb commented 10 months ago

Eu acredito que a solução sugerida newContent.body.normalize('NFC').match(/[a-záéíóúâôãõç]{5,}/ig).length continua sendo razoavelmente simples, então sou a favor de implementarmos, aproveitando para criar uma função que verifica isso e importar ela tanto no frontend quanto no backend.

tiagodavi commented 9 months ago

Lembrando que match pode retornar null quando não da match em nada ao invés do array e isso vai gerar undefined pro length ... undefined.length. Já implementei considerando isso.

aprendendofelipe commented 8 months ago

Turma, deixando um pouco de lado a implementação, qual seria a motivação para a mudança na regra de negócio?

Objetivo principal: Diminuir a quantidade de publicações e comentários que não possuíam valor concreto.

Solução proposta inicialmente #1267:

Problemas da solução proposta inicialmente:

  1. Apenas não creditar TabCoins não ajuda a educar usuários desavisados sobre o que é esperado dos conteúdos no TabNews, consequentemente teria impacto muito limitado.
  2. Considerando apenas a quantidade de caracteres, não foi possível chegar a uma conclusão sobre qual seria a quantidade mínima que nos ajudaria atingir o objetivo de termos mais conteúdos de valor, e que não gerasse tantos falsos positivos ou negativos.

Solução adotada #1460:

  1. Não apenas deixar de creditar TabCoins, mas dar um aviso explicando o motivo e com link para mais informações.
  2. Ao invés de se contar apenas os caracteres, foi considerado usar a quantidade de "palavras úteis". Mas como definição de "palavra útil", foi considerada a sequência mínima de 5 caracteres que contivesse apenas letras e desconsiderando quaisquer caracteres especiais, números, pontuação etc.

Características da solução adotada:

  1. A parte educativa só alcança quem usa a versão web do TabNews. Seria interessante algo que alcançasse os usuários da API.
  2. Obviamente não avalia de forma automatizada o valor concreto da publicação, é apenas uma forma de tentar filtrar o que muito provavelmente está sendo publicado por usuários ainda não familiarizados com o TabNews. Seria interessante usar algum algoritmo fundamentado em estudos para fazer essa avaliação ou, quem sabe mais pra frente, usar alguma IA isso.

A proposta dessa issue

O proposto na issue se parece com uma melhoria na implementação para atender a regra de negócio, mas não, ela é uma solução diferente, não apenas uma implementação diferente para a mesma solução.

A proposta se baseia na afirmação de que palavras acentuadas não são consideradas, o que não é sempre verdade, já que se houver uma sequência de 5 caracteres não acentuados, será uma palavra contabilizada. Não me baseie em nenhum estudo, foi só uma ideia para eliminar sequências de caracteres aleatórios e coisas que não fazem parte do texto principal do conteúdo.

Caso a proposta seja de alteração na solução, então quais seriam as justificativas? O objetivo é diminuir os avisos de "mensagem curta"? Para chegar mais perto do objetivo original, precisamos aumentar ou diminuir o efeito da solução adotada?

Para o futuro

Acredito que as melhorias na solução atual não são urgentes e nem requisitos para a Revenue Share, então se não houverem justificativas para a mudança nas regras, não vejo razão para manter a issue aberta.

Vamos fechar para focar na Revenue Share? 🤝

Rafatcb commented 8 months ago

A proposta se baseia na afirmação de que palavras acentuadas não são consideradas, o que não é sempre verdade, já que se houver uma sequência de 5 caracteres não acentuados, será uma palavra contabilizada

Tudo bem, mas palavras acentuadas que não possuem uma sequência de cinco carácteres não acentuados não são consideradas, esse é o ponto. Conforme foi mencionado no comentário https://github.com/filipedeschamps/tabnews.com.br/issues/1267#issuecomment-1615372170:

usei a verificação abaixo para conferir se existem pelo menos 5 palavras com no mínimo 5 caracteres:

Ou seja, continua sendo uma verificação por pelo menos 5 palavras com no mínimo 5 caracteres. (Sei que foi constatado no mesmo comentário o problema que tentamos resolver aqui, de não considerar todas palavras acentuadas que possuem cinco ou mais caracateres)

Caso a proposta seja de alteração na solução, então quais seriam as justificativas? O objetivo é diminuir os avisos de "mensagem curta"?

Mehorar a heurística atual, e recompensar alguns casos específicos onde o autor está escrevendo as palavras corretamente com acentuação 😅

Para chegar mais perto do objetivo original, precisamos aumentar ou diminuir o efeito da solução adotada?

Para chegar mais perto do objetivo original, acho que não adianta contar nada. Uma recomendação de um livro pode ser muito mais relevante do que três parágrafos de resposta, e automatizar isso é bem mais complicado do que o que foi sugerido nesse issue.

Vamos fechar para focar na Revenue Share? 🤝

Não acho que precisamos fechar um issue de baixa prioridade para focar no revenue share. Um dos pontos positivos de um projeto de código aberto é permitir que outros desenvolvedores trabalhem em algo que, ao mesmo tempo:

  1. Melhora o projeto; e
  2. Atende uma necessidade própria.

A situação é diferente da parte dos mantenedores, onde se espera foco total nos issues do Milestone, além de cuidar do repositório (o que, na maior parte do tempo, é revisão de PR e triagem de issues).

E se você está sugerindo fechar porque não gostou da solução para contar corretamente palavras com cinco caracteres ou mais, então claro que meus parágrafos anteriores não se aplicam (não é um issue de baixa prioridade, e sim algo que, se implementado, será recusado). Se for isso, então realmente o issue deve ser fechado para ninguém gastar tempo implementando ou discutindo sobre.

Edit: Vi a análise do PR após escrever este comentário. Se o problema for apenas o custo de processamento (que não sei se na prática é relevante, precisaria testar), podemos deixar o issue aberto e remover a label good first issue.

Rafatcb commented 5 months ago

Bom, como esta mudança não será implementada, estou fechando o issue. Futuras modificações sobre este comportamento deverão caminhar na direção de melhorar a heurística, ao invés de simplesmente contar caracteres ou palavras.

Agradeço a colaboração de todos que participaram da discussão.