Um gerador de endereço da Turquia precisa resolver um problema que os geradores ocidentais não enfrentam: a hierarquia administrativa turca tem mais níveis do que a maioria dos formulários ocidentais prevê, e a ordem em que eles são escritos confunde quem vem de um modelo americano ou britânico. Além disso, a língua tem duas letras que se comportam de forma diferente de tudo o que o seu código provavelmente assume, e elas aparecem justamente nos nomes de províncias e distritos. Neste texto, percorremos a estrutura completa de um endereço turco, explicamos por que o código postal sozinho não identifica um lugar, mostramos onde a questão das letras sem ponto quebra ordenação e busca, e fechamos com os limites de uso desse tipo de amostra.
Como se organiza um endereço turco?
Um endereço turco é uma cadeia de unidades geográficas que vai do menor para o maior quando lido no correio, mas que na prática administrativa é preenchido do maior para o menor. A sequência começa pela província, chamada il, depois o distrito, ilçe, e em seguida o bairro, mahalle. Só então aparecem a via, que pode ser sokak ou cadde, o número do prédio, bina no, e o número da unidade dentro do prédio, daire no.
Essa ordem é diferente da que um formulário de origem anglo-saxônica espera. Um sistema que pede a rua primeiro e a unidade depois vai receber os dados fora de ordem quando o usuário turco preencher naturalmente, e é comum que o valor do bairro acabe no campo da cidade. O resultado é um registro que passa em todas as validações de formato e não identifica lugar nenhum.
A solução prática, para quem projeta o formulário, é separar a hierarquia em campos distintos e rotulá-los com o nome local, porque traduzir província para cidade e distrito para bairro cria dependências falsas entre níveis que existem em um modelo e não existem no outro.
Quais são os níveis que o formulário precisa ter?
Província e distrito são os dois níveis que praticamente todo formulário turco precisa aceitar, e são também os dois que aparecem em qualquer consulta de correspondência. O país tem oitenta e uma províncias, cada uma com um código numérico próprio que é usado em placas de veículo, em estatísticas oficiais e na composição de identificadores fiscais.
O bairro é o nível seguinte e costuma ser obrigatório em cadastros de entrega, porque é a menor unidade que o carteiro usa para localizar um imóvel. Um formulário que o trate como campo livre e opcional vai gerar endereços incompletos que ninguém consegue entregar, e o erro não aparece em teste de formato, apenas na operação.
Depois vêm a via e os números. Vale notar que o número da unidade é frequentemente um número puro, sem letra, e que o campo de referência e ponto conhecido é muito usado na prática turca. Ignorá-lo no modelo de dados é uma decisão legítima, mas ela precisa ser consciente, porque é comum que informações úteis cheguem por esse campo.
O que o posta kodu realmente identifica?
O código postal turco tem cinco dígitos e é chamado de posta kodu. O primeiro par de dígitos costuma corresponder à província, o que cria uma relação aproximada entre código e província e permite uma verificação de coerência barata. Não é uma correspondência exata, porque uma província grande pode ter várias faixas, e é aí que muitos formulários escorregam: eles validam apenas o formato de cinco dígitos e aceitam qualquer código com qualquer província.
O que acontece em seguida é previsível. Um registro com província de Istambul e código postal de uma faixa de outra região passa em todo teste de máscara e falha em qualquer verificação de endereço real, e o time descobre o problema apenas quando alguém tenta usar o dado em uma integração de verdade.
Para efeito de teste, o mais útil é gerar o par completo, com o código pertencendo à faixa daquela província, e manter separado um caso negativo com o par deliberadamente trocado. Os dois casos juntos exercitam o caminho de aceitação e o caminho de aviso. No gerador de endereços, o posta kodu sai vinculado à província escolhida, o que evita que a sua bateria de testes acumule combinações impossíveis.
Por que as letras sem ponto quebram a sua busca?
O turco usa duas famílias de letras i que se comportam de forma diferente das do português. Existe o i minúsculo com ponto, cuja maiúscula também é escrita com ponto, e existe o i minúsculo sem ponto, cuja maiúscula é o I comum, sem ponto nenhum. Em português os dois minúsculos não existem como letras distintas e a maiúscula é sempre a mesma, e é essa assimetria que faz a diferença. A conversão de caixa de uma forma para a outra não é simétrica do jeito que a maior parte das bibliotecas assume, e essa diferença aparece com frequência em nomes de províncias, de distritos e de bairros.
O sintoma típico é o usuário que digita um nome de distrito em minúsculas, o sistema aplica uma conversão automática e o resultado não bate com a entrada da lista de referência. A busca por aproximação falha, o autocompletar não encontra nada e a mensagem de erro diz que o lugar não existe, quando o lugar existe e o problema está na normalização do texto.
Há um segundo efeito, menos visível, na ordenação. Listas alfabéticas turcas colocam as variantes de i em posições próprias, e uma ordenação feita com regras genéricas apresenta os resultados em ordem que parece aleatória para quem lê em turco. Se o seu produto tem uma lista de províncias ordenada, vale conferir se a ordem foi definida pelo time de produto ou herdada do banco de dados por acaso.
Para testar isso de forma sistemática, inclua nos seus casos de teste nomes de província e de distrito que contenham as duas variantes de i e verifique três coisas: se a busca encontra independentemente da caixa, se a exibição preserva a grafia correta e se a ordenação final faz sentido para um leitor da língua.
Como o telefone se relaciona com a cidade?
O telefone turco tem dez dígitos depois do código do país, e os três primeiros são o código de área. Esses códigos foram distribuídos por província, então existe uma relação direta entre o prefixo e a localidade: um número com determinado prefixo pertence àquela região, e não a outra.
Isso torna o telefone um campo de verificação cruzada muito útil. Se o seu cadastro pede endereço e telefone, e o registro de teste traz um número com prefixo de uma província e um endereço de outra, o seu sistema está exercitando um caso que nunca acontece com cliente real, e um teste que valide essa combinação vai passar sem provar nada.
A recomendação é a mesma do código postal: o dado de teste deve carregar o prefixo da província escolhida, e o caso negativo deve ser mantido explicitamente separado. Quem precisa entender como esse tipo de campo se comporta em outros países encontra um panorama no resumo sobre prefixo telefônico e localidade.
Quais armadilhas de caractere aparecem no preenchimento?
Endereços turcos contêm letras que não existem no português, como o c com cedilha próprio da língua, o g com breve, o o e o u com trema e o s com cedilha, além das duas variantes de i já citadas. Um formulário que aceita apenas caracteres latinos básicos vai recusar nomes de bairro legítimos, e o usuário não tem como contornar isso sem escrever errado.
Vale testar também o caminho inverso. Muitos sistemas aplicam uma normalização que remove diacríticos para comparar valores, e essa normalização pode fazer dois distritos distintos colidirem na mesma chave. O efeito prático é um seletor de distrito que mostra itens duplicados ou que associa o código postal do lugar errado.
O terceiro ponto é a largura dos campos. Nomes de mahalle e de cadde são longos com frequência, e um campo estreito demais é uma fonte de truncamento silencioso que só aparece quando alguém compara o dado gravado com o que o usuário digitou. Inclua um caso com nome de via longo e outro com combinação de bairro e via longos no mesmo registro, porque o limite de linha total é mais apertado do que o limite de cada campo isolado.
Para que servem esses exemplos, e para que não servem
Os registros gerados são dados sintéticos, construídos para preencher campos com formato local correto e relações internas coerentes. Eles não correspondem a imóveis existentes, não são endereços entregáveis e não devem ser usados em cadastros, entregas ou processos que dependam de uma pessoa ou de um lugar real.
O uso pretendido é o teste do seu próprio software: verificar se o formulário aceita a hierarquia completa, se a validação cruzada entre código postal e província funciona, se a busca tolera as variantes de letras e se a exibição sobrevive a nomes longos. Para calibrar a quantidade de dados disponíveis antes de desenhar o formulário, vale ler o panorama sobre como escolher países para dados de teste e, se o seu caso envolve vários países na mesma tela, o texto sobre formatos de endereço por país mostra onde as suposições de um modelo costumam quebrar.