Your site shows "Öğrenci" where it should say "Öğrenci". Product descriptions have turned Turkish letters into boxes. It looks alarming, but here is the good news: your data is probably intact. It is simply being read with the wrong alphabet.
Character encoding is the rule for which numbers represent which letters. When text is written under one rule and read under another, you get these strange symbols. The problem is translation, not fonts.
Four Links in the Chain
- Database and tables: the encoding and collation where the data is stored.
- The connection: what encoding the site declares when it talks to the database. The most commonly forgotten link.
- The files: what encoding the PHP and template files themselves were saved in.
- The page header: the instruction telling the browser how to read the page.
Align all four and nothing breaks. Let one differ and Turkish characters fall apart. The correct setup today uses a Unicode encoding with four-byte support across all four layers — which also means emoji and rare characters store correctly.
When Does It Show Up?
- During a migration. A backup taken in one encoding and restored in another garbles the text. This is the most common scenario by far.
- Importing content from an old site. Data created years ago under a different encoding becomes unreadable when moved as-is.
- Bulk product imports from Excel or CSV. Excel's default save is often not Unicode; import it directly and thousands of product names break.
- Server or database version changes. Default encodings can shift, so new records start being stored differently from old ones.
Two Kinds of Breakage — Do Not Confuse Them
Type 1: the data is fine, the display is wrong. The text sits correctly in the database but the page is served with the wrong encoding. This is the easy case; fix the connection and page settings and everything falls into place without touching the data.
Type 2: the data really is corrupted. During a bad transfer the characters were stored in their broken form. Fixing the page settings will not help; the data itself has to be converted. That is an irreversible operation and must always be done with a backup in hand.
A practical way to tell: compare the same text in the admin panel and on the front end. Correct in the panel but broken on the front end means Type 1; broken in both means Type 2.
Three Common Mistakes
1. Fixing broken text by hand. Feasible for a few pages, impossible across thousands of records, and pointless while the root cause keeps corrupting new entries.
2. Forcing the page encoding. You may find a setting that renders broken data correctly, but that patch creates new problems in search engines and exports.
3. Converting without a backup. Run a character conversion with the wrong parameters and the data is destroyed irreversibly. Always rehearse on a copy first.
Building a Permanent Fix
The order is: backup first. Then diagnosis — establish which type of breakage you have. For Type 1, correct the connection and page encoding and you are done. For Type 2, convert the data on a copy, verify the result, and only then apply it to production. Finally, pin all four layers to the same encoding so it cannot recur.
Do not forget the URL side: addresses generated from Turkish-character titles can cause problems in the address structure. The right approach is to transliterate Turkish characters in URLs and, when changing existing addresses, redirect the old ones. Unmanaged slug changes make 404 errors inevitable.
When You Need a Professional
If the corruption has reached the database and the record count is high, do not experiment: a wrong conversion turns a fixable problem into permanent data loss. On e-commerce sites, where product names, addresses and invoice details are affected, this is an operational risk rather than a cosmetic one.
Preventing Corruption During a Migration
- Export and import with the same encoding. One encoding on the way out and another on the way in is the single most common mistake.
- Do not blindly trust panel tools. Some backup utilities pick the encoding for you and do not always pick correctly. Testing with one small table takes five minutes.
- Check immediately after the move. Open a few records containing Turkish characters right away. Catching corruption on day one is very different from catching it a month later, when new data has been entered on top.
- Set the encoding at database level, not per table. If only new tables get the correct setting, old ones are left behind and you end up with a mixed structure.
Sorting and Search: The Invisible Effect
Encoding decides more than how letters look — it also governs sorting and search behaviour. For Turkish, the practical consequences are:
- Alphabetical sorting goes wrong. With the wrong collation, "ç" may land at the end of the list instead of after "c" — visibly wrong in product and name listings.
- Search returns incomplete results. Someone typing "ogretmen" may not find "öğretmen" records. This is often why an on-site search feels useless.
- Case conversion breaks. Turkish distinguishes i/İ and ı/I; without the right setting, automatic capitalisation produces odd results.
Encoding is therefore not a cosmetic choice. Set up correctly, display, sorting and search all improve together; patched piecemeal, fixing one breaks another.
What Would It Cost If We Fixed It?
You do not have to guess, and you do not have to ask us. Tick the items you need in the calculator on our site and the total appears instantly. No forms, no waiting for a quote.
