Como entender tabelas de números em inglês na prática
Achei fácil quando estava estudando e consegui memorizar os padrões básicos, mas na hora de montar planilhas automatizadas para um projeto de integração de dados, percebi que a coisa não era tão simples assim. O problema apareceu quando precisei converter valores de uma tabela em português (R$ 1.234.567,89) para o formato inglês onde vírgula vira ponto e ponto vira separador de milhar. A conversão direta com replace() deu erro feio porque o sistema americano usa vírgula para casas decimais, enquanto nós usamos ponto. Gastei umas duas horas até encontrar a solução correta, que basicamente é normalizar o número para float primeiro, depois formatar com as regras certas de separadores.
O que você precisa saber sobre tabelas de números em inglês antes de começar
Não adianta só decorar as palavras. O segredo tá no padrão de construção. Em inglês, os números seguem uma lógica posicional bem diferente da que a gente tá acostumado. As dezenas de 21 a 99 levam hífen: twenty-one, thirty-five, ninety-nine. Sem hífen fica errado, mesmo que pareça coisa de gramática ultrapassada. Eu já vi bastante gente errando nisso em código porque o regex não reconhecia o padrão sem hífen e quebrava a validação. Os milhões e bilhões têm sua própria tabela de nomes que se repete a cada três ordens. Mil, milhão, bilhão, trilhão. Cada agrupamento segue o mesmo padrão: unidades, dezenas, centenas, mais o sufixo. A parte chata é o "and" que entra depois das centenas nos números britânicos. Um milhão duzentos e trinta e quatro mil e quinhentos e sessenta e sete é como um britânico escreveria, mas americanos tendem a pular esse "and" nas centenas. Se você tá trabalhando com sistemas que precisam suportar variabilidade regional, precisa tratar essas diferenças.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um problema real que ninguém conta nos manuais
Certa vez precisei implementar um validador de cheques numéricos para um sistema bancário que recebia valores tanto em inglês americano quanto em inglês britânico. A pegadinha é que "one thousand two hundred and forty-five" e "one thousand two hundred forty-five" são a mesma quantidade, mas o parser não podia aceitar os dois formatos de forma diferente. A solução foi criar um dicionário mapeando todas as variantes, removendo o "and" opcional antes de processar, e usando uma tabela de referência com todos os números de zero a novecentos e noventa e nove fixos, depois montando os maiores agrupamentos dinamicamente. O detalhe crucial é que números entre zero e cem são os únicos que precisam ser absolutamente garantidos, porque eles são a base de tudo. Depois deles, a construção é recursiva: você pega o multiplicador (thousand, million, billion), divide o número, converte o quociente usando a regra básica, e junta com o resto. Isso funciona até billions, mas acima disso começa a divergir entre o curto scale e o longo scale que britânicos historicamente usavam. Hoje em dia o Reino Unido adotou o curto scale, mas ainda dá para ver resquícios em textos mais antigos ou em contextos jurídicos específicos.
Limitações e quando isso falha completamente
A abordagem manual de construção de tabelas funciona bem para números até bilhões ou talvez trilhões, dependendo do esforço que você quer gastar. Mas quando você precisa lidar com quantias astronômicas ou com precisão extrema de casas decimais, o tamanho da tabela explode. Números com dez casas decimais exigem uma camada extra de complexidade que a maioria das implementações caseiras não suporta. Nesse caso, usar bibliotecas existentes como o `num2words` em Python é muito mais seguro, mesmo que introduza uma dependência externa. Outro ponto crítico é a formatação de output. Se você precisa apenas converter texto para número e vice-versa, tabelas manuais resolvem. Se precisa formatar para exibição com separadores de milhar decimais corretos por região, aí a coisa muda de figura. Um número como 1.000.000 em inglês americano é "one million", mas em notação numérica escrita vira 1,000,000. Já em alemão seria 1.000.000. Então a regra de negócio precisa deixar claro qual convenção está sendo usada antes de qualquer conversão.
