Closed hkotsubo closed 5 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:
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.
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.
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:
Solução adotada #1460:
Características da solução adotada:
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?
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? 🤝
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:
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
.
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.
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
pormatch
(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):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: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.