Un generador de direcciones de Turquía permite obtener registros postales completos para probar formularios, procesos de alta y sistemas de envío sin recurrir a datos de personas reales. El país tiene un sistema de direccionamiento muy jerárquico, con más niveles que la mayoría de los países europeos, y esa estructura es justamente lo que hace que los formularios internacionales fallen con tanta frecuencia cuando se enfrentan a una dirección turca. En esta guía se recorren los niveles uno por uno, se explica en qué orden se escriben y se señalan los detalles de mayúsculas, caracteres y prefijos telefónicos que suelen escapar a quien diseña la captura desde fuera. Al terminar tendrás una idea clara de qué campos necesita tu formulario y qué combinaciones conviene probar.
Cómo se organiza una dirección turca por niveles
La dirección turca se construye por inclusión, de la unidad grande a la pequeña. Primero está la provincia, que en turco se llama il y que corresponde a la división administrativa principal; el país tiene ochenta y una. Dentro de ella aparece el distrito, ilçe, que puede ser una zona urbana o un área rural extensa. Por debajo se encuentra el barrio, mahalle, una unidad con nombre propio que en las ciudades agrupa manzanas y en el campo puede abarcar varios núcleos.
El siguiente nivel es la vía, que puede ser una calle o sokak, una avenida o cadde, o alguna de las otras denominaciones que recoge la normativa. Después llega el número del portal, bina numarası, y por último el número interior, daire numarası, que identifica la vivienda o la oficina dentro del edificio. Estos dos últimos niveles se confunden a menudo al migrar datos, porque en muchos sistemas occidentales ambos caben en un solo campo de dirección adicional.
La consecuencia para el diseño de datos es que una dirección turca no cabe cómodamente en el esquema de tres líneas que usan los formularios anglosajones. El barrio y el distrito son dos campos distintos que no se pueden fusionar sin perder información, y la provincia no es lo mismo que la ciudad: hay provincias cuyo nombre coincide con el de su capital y otras donde el centro administrativo se llama de otra manera. La comparación entre modelos nacionales está desarrollada en la guía sobre formatos de dirección internacionales.
¿En qué orden se escribe una dirección en Turquía?
El orden de escritura va de lo general a lo particular, al contrario de lo que ocurre en el uso postal de muchos países europeos. Se empieza por el barrio, la calle y el número, y se termina por el distrito y la provincia, con el código postal en una posición que en la práctica se coloca cerca del final. Ese orden se refleja tanto en los sobres como en los formularios administrativos, aunque en el uso diario mucha gente añada la provincia al principio por costumbre.
Esta diferencia explica por qué un formulario que etiqueta sus campos como línea uno, línea dos y línea tres funciona mal fuera del mundo anglosajón. En una dirección turca, la primera línea suele contener el nombre de la vía con el número, no el nombre del destinatario, y el barrio compite con la calle por el mismo espacio. Cuando el usuario no encuentra dónde poner cada cosa, inventa una distribución propia y el dato se vuelve inconsistente entre registros.
La recomendación práctica es separar los campos con nombre propio en lugar de agruparlos en líneas genéricas. Un formulario que pide provincia, distrito, barrio, vía y número por separado captura el dato de forma comprobable, permite validar cada nivel contra su catálogo y hace posible construir después la línea postal que corresponde. Las líneas de texto libre se reservan para la información que ninguna estructura puede prever, como una referencia de edificio o una indicación de acceso.
El código postal y su relación con la provincia
Turquía usa un código postal de cinco cifras que se llama posta kodu. Las cifras no se reparten al azar: los dos primeros dígitos identifican la provincia o un grupo de provincias vecinas, y los tres restantes distinguen la zona de reparto dentro de ella. Eso significa que existe una correspondencia verificable entre el código y la provincia, y que un código plausible pero mal emparejado se puede detectar sin consultar ningún servicio externo.
Esa correspondencia es la comprobación más rentable que puede hacer un formulario turco. Si la provincia se ha seleccionado en un desplegable y el código postal se introduce a mano, basta con comprobar que los dos primeros dígitos pertenecen a la provincia elegida para atajar una buena parte de los errores. La misma idea se aplica a la inversa: cuando el usuario escribe primero el código, el sistema puede preseleccionar la provincia y ahorrarle una decisión.
Como en muchos países, el código postal no coincide con la frontera administrativa, y hay zonas donde un mismo código abarca varios barrios o donde un distrito grande usa varios códigos. Por eso conviene guardar el código como texto, con sus ceros iniciales intactos, y no derivar de él conclusiones que la estructura no sostiene. La página de Turquía resume qué formatos conviene declarar en cada campo si vas a probar un flujo específico para este país.
¿Por qué la i con punto y la i sin punto rompen un formulario?
El turco usa dos letras que el español no distingue: la i con punto y la i sin punto, que se escriben con caracteres distintos y se comportan de manera diferente al pasar a mayúscula. La i con punto se convierte en İ al escribir en mayúsculas, y la i sin punto se convierte en I. En español, en cambio, la mayúscula de la i es siempre la misma I, y esa asimetría es el origen de una familia entera de fallos.
Cuando un sistema convierte a minúsculas o a mayúsculas usando las reglas del español o del inglés, el resultado deja de coincidir con lo que espera un catálogo turco. Una búsqueda por nombre de barrio que compare cadenas transformadas puede no encontrar nada, aunque el usuario haya escrito el nombre correctamente. Un generador de identificadores que derive una clave del nombre de la provincia puede producir dos claves distintas para la misma provincia según cómo se haya escrito la entrada.
El problema se agrava en las ordenaciones alfabéticas, porque el turco coloca la i sin punto entre la h y la i con punto, y no donde la colocaría un ordenador configurado para otro idioma. Un listado de distritos que se ordena con las reglas equivocadas parece arbitrario al usuario local. La solución es declarar el idioma en la interfaz y usar reglas de comparación dependientes de la configuración regional, en lugar de asumir que todas las letras latinas se comportan igual.
El prefijo telefónico y su coherencia con la ciudad
El teléfono turco añade otra capa de coherencia interna a los registros. El código de país es el noventa, y a continuación se escribe un código de área de tres cifras que corresponde a una zona del país, seguido de siete cifras del número. Los códigos de área están asociados a provincias y ciudades, de modo que un número con un prefijo de Estambul y una dirección en otra provincia es un dato que no cuadra.
Ese desajuste aparece en las pruebas con más frecuencia de la que se espera, porque un generador descuidado toma el teléfono de un catálogo y la dirección de otro. En un sistema de alta real, ese registro incoherente puede impedir una verificación por mensaje y bloquear a un usuario legítimo. En un entorno de pruebas, la incoherencia no rompe nada visible, pero invalida la prueba: se está ejercitando un caso que nunca ocurrirá.
La comprobación entre prefijo y localidad es, además, una de las pocas que se puede hacer con una tabla estática y sin coste. Eso la convierte en una buena candidata para el material de prueba: si el generador mantiene la correspondencia por construcción, tus pruebas pueden verificar tu propia validación en lugar de discutir sobre los datos. El tema se trata con más detalle en la guía sobre coincidencia entre prefijo telefónico y localidad.
Errores de captura que conviene provocar en las pruebas
Más allá de los formatos, hay un grupo de errores que solo se descubren probando con caracteres poco habituales. El turco emplea letras como ç, ğ, ı, ö, ş y ü, que en muchas aplicaciones llegan destrozadas por una codificación mal declarada y se convierten en signos de interrogación o en secuencias extrañas. Si el formulario no declara la codificación correcta, el dato se guarda mal y el problema no aparece hasta que se intenta imprimir una etiqueta.
Otro caso frecuente es el de los números de portal con letra o con guion, que existen en muchas calles y que un campo estrictamente numérico rechaza. Lo mismo ocurre con los números interiores, que pueden incluir una letra cuando el edificio usa una nomenclatura por bloques. Probar estos valores en un entorno controlado es más barato que descubrirlos con un cliente delante.
También conviene probar los nombres de provincia y de distrito con sus caracteres completos, no con una versión simplificada. Un catálogo que solo guarda la forma sin diacríticos parece funcionar hasta que alguien escribe el nombre con todas sus letras y el sistema no lo reconoce. La lista cerrada de ochenta y una provincias es suficientemente pequeña para mantenerla bien y suficientemente grande para que los errores de mantenimiento se noten.
Qué se puede probar con direcciones turcas de ejemplo
Las situaciones en las que este material ahorra trabajo son las mismas que en otros países, con un matiz propio. La primera es el formulario en cascada, ese en el que al elegir la provincia se cargan los distritos y al elegir el distrito se cargan los barrios. Probar esa cascada requiere valores reales de la jerarquía, porque una cadena inventada no permite comprobar que las listas dependientes se actualizan y se vacían correctamente.
La segunda es la coincidencia entre dirección y teléfono, que en el caso turco depende de una tabla de códigos de área relativamente pequeña y por tanto fácil de verificar. La tercera es el tratamiento de mayúsculas, donde el material de prueba debe incluir al menos un valor con i sin punto en posición inicial o tras un separador, porque es ahí donde se manifiesta la diferencia.
En el generador de direcciones de este sitio se elige el país y una división administrativa, y la herramienta devuelve un registro con provincia, distrito, barrio, vía y número tomados del mismo origen, además del código postal correspondiente. Al venir de la misma fuente, los niveles no se contradicen y la prueba mide lo que debe medir. Si necesitas comparar comportamientos entre países, el generador de direcciones de Estados Unidos ofrece el contraste con un modelo mucho menos jerárquico.
Los límites de este material
Conviene recordar qué es lo que se está generando. Los registros son datos sintéticos: respetan la estructura, las longitudes y las correspondencias del país para que el software los trate como trataría una entrada auténtica, pero no pertenecen a ninguna persona ni figuran en ningún registro postal. Que el formato sea correcto no los convierte en direcciones reales, ni permiten enviar nada ni acreditar nada ante un tercero.
Su lugar está en el entorno de desarrollo, en el conjunto de pruebas y en la demostración que se enseña en una revisión de diseño. No sirven para abrir cuentas, para superar una comprobación de identidad ni para hacerse pasar por otra persona, y esa frontera no es una formalidad legal: es la razón por la que este material no crea obligaciones de protección de datos a quien lo usa.
Siguientes pasos
Elige un formulario propio que hoy tenga un solo campo de dirección y decide cuántos niveles necesita de verdad. Si el público incluye Turquía, separar provincia, distrito y barrio es el cambio con mayor efecto, porque permite validar cada nivel y construir después la línea postal correcta. Añade además una prueba con caracteres turcos completos y otra con un prefijo telefónico que no corresponda a la provincia elegida.
Cuando necesites material para esas pruebas, el generador de direcciones de Turquía devuelve registros coherentes en unos segundos. Recuerda el límite: son datos de prueba generados para probar software, no corresponden a ninguna persona ni domicilio real y no sirven para acreditar una dirección.