Turkish WordPress hosting and the letter that breaks case conversion.
Turkish has a dotted and a dotless i, and they are separate letters. Lowercasing an I in Turkish produces ı, which means comparisons written for English quietly stop matching.
Two letters that look like one.
This is the most famous internationalisation bug there is, and it is still shipping in code every year.
Comparisons that do not depend on locale
Lowercasing under a Turkish locale turns I into ı, so a string that should match stops matching. Case-insensitive comparisons are made locale-independent rather than left to the server's setting.
Slugs that stay stable
A title containing İ or I can produce a different slug depending on which locale generated it. That is a URL that changes for reasons nobody can see, and it breaks links.
Search that folds Turkish letters properly
Visitors type without diacritics, so ş, ğ, ç, ö and ü have to fold for matching while being preserved for display.
KVKK answered concretely
Türkiye's regime asks where personal data is held and under what basis it is transferred. Those are answered as facts rather than as a region name.
Served close to a large market
The audience is big and geographically concentrated, so an origin chosen for it removes latency on every uncached request.
The bug that only appears in Turkish.
A login stops working, a slug changes, a comparison fails. All of them trace to a single letter behaving correctly under Turkish rules and unexpectedly under code written for English.
- Case-insensitive comparisons made locale-independent
- Slug generation kept stable across locales
- Turkish diacritics folded for search
- Storage and transfers documented for KVKK
Fast is not the hard part.
Serving Türkiye quickly is straightforward. What costs time is a class of bug that only reproduces when the locale is Turkish.
What we change for Turkish sites
One letter drives most of this, and it produces failures that look like anything except a character-encoding problem.
| Setting | What we do | Why |
|---|---|---|
| Case conversion | Comparisons performed locale-independently | Lowercasing under a Turkish locale maps I to ı, so a comparison that succeeds everywhere else fails here and the symptom looks like a broken login. |
| Slug generation | Kept stable regardless of the active locale | A title containing an I can yield different slugs depending on which locale ran the conversion, producing URLs that change without an edit. |
| Search folding | Turkish diacritics folded for matching, preserved for display | Visitors omit diacritics when typing, so strict matching fails against correctly spelled content they are looking at. |
| Data disclosure | Storage and transfer basis recorded for KVKK | The Turkish regime asks specifically about cross-border transfer, and that answer has to exist before somebody requests it. |
| Origin placement | Chosen for a large, concentrated domestic audience | The market is big enough that a nearby origin measurably improves every request a cache cannot answer. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
What is the Turkish i problem?
Why did my slugs change on their own?
Do visitors need to type Turkish diacritics?
What does KVKK require?
Fix the bug before it ships.
Move the site across. Migration is free, locale handling checked.