Romanian WordPress hosting where one letter has two encodings.
Romanian s-with-comma is a different character from the Turkish s-with-cedilla, and both end up in Romanian databases. They look identical and never match each other.
Two characters, one letter.
Romanian text arrives from keyboards, imports and pasted documents using two different codepoints for the same letters.
Normalised as it is written
Rather than folding at query time, incoming text is normalised to one form on write. That keeps the stored data internally consistent instead of relying on every reader to compensate.
Existing data reconciled once
A database that has been collecting both forms for years needs a one-time pass. Doing it at migration is cheaper than every query working around it forever.
Sorting that stops splitting words
Two encodings of the same letter sort to different places, so an alphabetical list separates entries a reader considers identical.
EU origin and EU backups
Storage stays in the EU with the location named, and delivery is local enough that latency is not a factor.
Diacritics folded for queries too
Romanian ă, â and î are frequently typed without accents, so matching folds them while display keeps them.
Data that disagrees with itself.
The same product name appears twice in a listing, sorts in two places and matches only one search. Both spellings are visually identical and neither is wrong.
- Incoming text normalised to one encoding on write
- Existing mixed data reconciled at migration
- Sorting no longer split across encodings
- Diacritics folded for matching
One spelling in the database.
Query-time folding papers over the problem for search and leaves sorting, exports and deduplication still broken. Normalising on write fixes all of them at once.
What we change for Romanian sites
One letter existing as two codepoints causes all of it, and the fix belongs at write time rather than in every query.
| Setting | What we do | Why |
|---|---|---|
| Write normalisation | Incoming text normalised to a single encoding | Romanian s-with-comma and the Turkish s-with-cedilla are distinct codepoints that render identically, so a database collects both and nothing matches reliably. |
| Historical reconciliation | Existing mixed rows normalised once at migration | Working around inconsistent stored data in every query is a permanent tax, where a single pass is a one-off cost. |
| Sort behaviour | Verified after normalisation | Two encodings of one letter sort to different positions, so listings separate entries a reader regards as the same. |
| Query folding | Diacritics folded for matching, preserved for display | Romanian accents are commonly omitted when typing, so strict matching fails against correctly spelled content. |
| Origin placement | EU, close to the domestic market | The country is well connected within the union, so latency and residency have the same nearby 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.
Why does the same word appear twice in my listings?
Is folding at query time enough?
Can existing data be cleaned up?
Do visitors need to type Romanian accents?
Store one spelling, not two.
Move the site to an EU origin - migration is free, encoding reconciled.