How We Made Korean Business Names Work as Safe Subdomains

The bug looked small at first.

A place name like 카멜커피 11호점 could reach the publish screen and immediately produce a bad default slug. Once the old ASCII-only sanitizer stripped out Hangul, the result could collapse into something like 11.

That failed the product's own minimum-length rule.

So the user saw an invalid subdomain before they had done anything wrong.

Why this was more than a string utility problem

Publishing is the moment where the product needs to feel most certain.

The user has already generated the page. They have already invested time. If the first thing they see on the publish step is an invalid default, it feels like the system does not understand the business name it just worked with.

That is not just a formatting bug. It is a trust problem.

The tempting answer was not the best answer

One obvious reaction would be "just allow raw Korean subdomains everywhere."

We did not take that path.

The product decision was to keep ASCII canonical slugs for publishing, routing, certificates, logs, and validation rules, then improve the candidate generation around that constraint.

That gave us a cleaner product boundary:

• the publish contract stays stable
• backend validation rules stay simple
• users still get meaningful defaults instead of broken ones

In other words, we kept the canonical slug conservative and made the suggestion layer smarter.

What changed in practice

The old flow mostly asked one question:

"What happens if I keep only [a-z0-9-]?"

That works for many English names. It fails quickly for Hangul-heavy names.

The new flow became more deliberate:

1. Generate Korean-aware slug candidates, including romanized forms.
2. Reject candidates that are empty, too short, or obviously weak.
3. Provide a deterministic safe fallback when the name-based options still are not good enough.
4. Let the user pick from visible candidate buttons instead of editing from a broken starting point.

That is a better publish experience than making the user debug slug policy by hand.

Why deterministic fallback mattered

One lesson here was that "best effort" is not enough for publishing defaults.

If a place name produces no strong candidate, the product still needs a usable answer.

That is why the deterministic fallback mattered.

It is not as human-friendly as a great name-based slug. But it is:

• valid
• predictable
• quick to adopt

That is a much better failure mode than an empty or invalid input box.

The UX mattered as much as the algorithm

This change was not only about transliteration.

It also improved the publish step itself:

• candidate buttons made the options visible
• a safe fallback action removed dead-end states
• input alignment made the subdomain easier to read while editing

That matters because users do not experience "slug utilities." They experience confidence or friction at the moment they try to go live.

The trade-off we accepted

The romanization is practical, not perfect.

That is fine.

The goal here was not linguistic purity. It was reducing publish friction without making the infrastructure contract more fragile.

For this kind of feature, a slightly imperfect but stable default is often better than a theoretically broader solution that creates more operational ambiguity.

Closing

Good defaults matter most where users are least interested in the implementation.

Nobody wants to think hard about slug policy while publishing a page for their business.

The product should meet them with a reasonable first answer.

For Place2Page, that meant keeping the publish rules strict and making the suggestion layer much more Korean-aware.