A Turkey address generator produces Turkish addresses that follow the country’s own postal conventions rather than an English-language approximation of them. The hierarchy runs from the province down to the street, the postal code is always five digits, and the written order puts the largest administrative unit first — a sequence many international forms quietly get backwards.
This guide explains how a Turkish address is structured, how the eighty-one provinces relate to postal codes and telephone prefixes, why Turkish dotted and dotless letters cause real defects in address fields, and what a generated record can and cannot stand in for. By the end you should be able to tell whether a Turkish address in your fixture is merely plausible or actually consistent.
How is a Turkish address ordered?
A Turkish address is written from the largest unit to the smallest, and the postal service expects that order to be respected when the address is presented on one label. The province comes first, then the district, then the neighbourhood, then the street or avenue, then the building number, then the apartment number inside the building, and finally the five-digit postal code followed by the province name again or the district name.
That largest-to-smallest direction is the opposite of the United States and the United Kingdom, where the street line leads and the administrative units follow. Pulling the wrong convention into the wrong country is one of the most reliable ways to produce an address that looks translated. Developers who build one address template for every country tend to write Turkish records in the American order without noticing, because both render as a single plausible-looking line.
The building and apartment elements are separate values rather than one combined unit field. A Turkish address distinguishes the street number from the number of the flat inside the building, and both are usually small integers written without a unit word in the compact form. Street numbers can also carry a letter suffix where a plot was subdivided, so a field limited to digits will reject a valid entrance. Systems that collapse the two numbers into a single field lose information that Turkish couriers and municipalities routinely use.
What do the province, district and neighbourhood layers do?
The first layer is the province, and Turkey has eighty-one of them. Provinces are frequently abbreviated on forms by their two-digit plate code rather than by a name, which means a test suite that only exercises province names will never touch the numeric path. A well-shaped dataset should carry both representations for each province so that either field can be exercised.
Beneath the province sits the district, and beneath the district the neighbourhood or village. The neighbourhood is the level that most foreign address models have no equivalent for, which is why it is the one most often omitted from international forms and then discovered later when a Turkish user complains. Postal codes in Turkey are allocated at a finer level than the province, so the postal code narrows the location considerably once it is paired with the right district.
Because the layers are strictly nested, the consistency rules are also strictly nested. A district belongs to exactly one province, a neighbourhood to exactly one district, and a postal code to a small set of neighbourhoods. Any record where the district and the province disagree is not subtly wrong; it is impossible, and a validator that checks the pair will catch it immediately.
Why the postal code and the province have to agree
Turkish postal codes are five digits, and the first digits carry geographic meaning tied to the province and the wider region. The practical consequence is that a postal code drawn at random from the full five-digit space will almost always point somewhere that has nothing to do with the province in the same record.
This is the same class of defect that appears in every country, and it is worth restating because it is so common: a single field can be perfectly formatted and still be wrong. Five digits is five digits. What makes a Turkish record usable is that the digits correspond to the province recorded alongside them.
Generators avoid this by choosing the province first and deriving the district, the neighbourhood and the postal code from it, never the other way round. When you evaluate any tool that claims Turkish coverage, that derivation order is the thing to probe. Ask for several records for one province and check whether the postal codes cluster sensibly or scatter across the whole numeric range.
The telephone prefix follows the same principle. Turkish landline area codes map onto provinces, so a telephone number that begins with a code belonging to one city while the address names another is a mismatch that a careful test suite should catch. Mobile numbers are different, because they are portable and no longer indicate a region, which means a Turkish test record should only assert the landline relationship. The phone prefix and locality matching article goes into this relationship in more detail.
Which Turkish letters break address fields?
Turkish writes the letter i in two forms. There is a dotted capital and a dotless lowercase on one hand, and a dotless capital with a dotted lowercase on the other, and the two are distinct letters in the alphabet rather than stylistic variants of one character. Case conversion that ignores this will silently corrupt a city or street name.
The failure is quiet and therefore dangerous. Converting a Turkish place name to uppercase with a generic routine turns the dotted lowercase i into a dotted capital, which is the wrong letter for words that contain the dotless one. Addresses then fail to match against the reference list even though the user typed the name correctly, and the resulting bug report says the address is invalid when the real fault is the case mapping. The reverse also happens: lowercasing a dotless capital produces a dotless lowercase in Turkish and a dotted lowercase in most other languages, and code that assumes the second will store a value that cannot be matched later.
Sorting has the same problem from the other direction. Turkish collation places the dotted and dotless letters in different positions from the positions they occupy in English, so a list of provinces sorted with a Latin-1 or English collation will appear scrambled to a Turkish user. If your address dropdown is sorted server-side by an English rule, that is a defect worth fixing before anything else.
The character set itself is also wider than plain ASCII. Turkish place names carry the dotted i, the dotless i, the c with a cedilla, the g with a breve, the o and u with diaereses, and the s with a cedilla. A field that strips diacritics on input will turn some of these into letters that change the meaning of the name, so normalisation has to be lossless in reverse or deliberately conservative.
How should Turkish address forms be structured
Model the address as nested pairs rather than as free text plus a postal code. Province and plate code belong together, district belongs to the selected province, neighbourhood belongs to the selected district, and the postal code is validated against the district rather than in isolation. Each level should be filtered by the level above it, which prevents most invalid combinations before they are typed.
Give the building and apartment numbers their own fields and their own length limits. Turkish street numbers can carry a letter suffix, and apartment numbers can run to three digits in large blocks, so a single-character field will fail on ordinary inputs. Allow the postal code to be entered with or without a separating space, and normalise it after storage rather than rejecting it at the door.
Where you accept an international form, add the neighbourhood field even if your other countries do not use it. Making one field optional for fifty countries and required for Turkey is a small schema cost and a large reduction in support tickets, and a test fixture should include at least one Turkish record with a neighbourhood and one without so that both paths are exercised.
Does a generated Turkish address correspond to a real location
It does not. A generated Turkish address has the correct hierarchy, the correct field order and a postal code consistent with its province, which is everything a form, a parser or a routing rule needs in order to be exercised. It does not identify a real building, it is not registered to anyone, and no courier could deliver to it.
The familiar caveat applies with an extra twist in Turkey, because the intermediate layers are numerous and a plausible-looking combination can be assembled by hand fairly easily. The difference between a hand-built record and a generated one is not the appearance of the fields but the depth of the relationships behind them. A generator derives the lower layers from the upper ones; a person assembling a record by hand is guessing at each layer independently.
Public reference material for Turkish administrative divisions is maintained by the national statistics office, and its published lists are the kind of source a maintained dataset should be traceable to. Knowing where the values came from is what makes it possible to refresh them later without guessing. It also makes the difference between a generator and a spreadsheet visible: a spreadsheet ages silently, while a dataset with a stated source can be checked against it.
What to check before trusting a Turkish dataset
Check the province count first, because a dataset that is short on provinces is short on coverage somewhere else as well. Then check that districts are nested rather than global, and that the record carries a plate code alongside the province name. Then check the character handling: generate a province whose name contains a dotless i, convert the record to uppercase in your own code, and confirm it survives.
Finally, check reproducibility. The same key and the same country should return the same record every time, because an address that changes on every call cannot be used inside an assertion. A generator that shuffles its output on each request is fine for a manual demonstration and useless for a regression test, and the difference only becomes visible once the output is asserted on. The Turkey country page describes how the country data is organised, and the address generator is where records for Turkey and the other supported countries can be produced and exported.
Every record produced this way is synthetic test data. The field order, the hierarchy and the relationships are faithful to the published formats, but the records correspond to no real person, no real premises and no real postal delivery, and they must not be used to impersonate anyone, to receive actual mail, to prove an address, or to pass any identity or residency verification.