Skip to content

fix: allow non-Latin characters in display names - #1576

Open
culfin wants to merge 1 commit into
apache:mainfrom
Besser-Sehen-Landshut:fix/non-latin-display-names
Open

fix: allow non-Latin characters in display names#1576
culfin wants to merge 1 commit into
apache:mainfrom
Besser-Sehen-Landshut:fix/non-latin-display-names

Conversation

@culfin

@culfin culfin commented Aug 20, 2026

Copy link
Copy Markdown

Problem

Registering with a display name such as Jürgen Müller fails. The form
shows "Erlaubt sind a-z, 0-9, - . _" and the request never succeeds.

Two checks reject it, both relying on \w, which means [A-Za-z0-9_] in
JavaScript as well as in Go:

ui/src/pages/Users/Register/components/SignUpForm/index.tsx:60 const nameRegex = /^[\w.-\s]{2,30}$/
pkg/checker/username.go:25 usernameReg = `^[\w.\- ]{2,30}$`

This affects every language except English — German umlauts, accented
letters in French, Spanish or Portuguese, Cyrillic, Greek. Answer ships
translations for over 40 languages, but a user whose name contains a
letter outside ASCII cannot register under it.

Why the check exists

The second check is not really about the display name. MakeUsername
derives the username from it, and the username appears in a profile URL,
so restricting it makes sense. The restriction is just applied one step
too early — to the display name rather than to the derived username.

Approach

Answer already solves exactly this problem elsewhere: question URLs are
transliterated in pkg/htmltext via unidecode.Unidecode, and
MakeUsername already handles Chinese through pinyin. This change
carries that idea through.

  1. Transliterate the display name before deriving the username, using
    github.com/mozillazg/go-unidecode — already a direct dependency.
  2. Drop what transliteration may leave behind: Ольга becomes Ol'ga,
    and an apostrophe is not a valid username character.
  3. Widen the front-end check to Unicode letters and digits (\p{L},
    \p{N}).

The display name keeps its original spelling. Only the derived username
is transliterated:

Jürgen Müller  ->  jurgen-muller
José García    ->  jose-garcia
Ольга          ->  olga
Ελένη          ->  elene
Straße         ->  strasse
Kerstin Harms  ->  kerstin-harms   (unchanged)

Chinese input is unaffected — pinyin still runs first, and its output
is already ASCII.

Notes

  • No new dependency.
  • gofmt clean.
  • Found while migrating a 26-year-old German optometry forum with 5,479
    member accounts to Answer; roughly one in twenty names carries a
    character outside ASCII.

Registering with a display name such as "Jürgen Müller" fails with
"Erlaubt sind a-z, 0-9, - . _". Two checks reject it, both using \w,
which means [A-Za-z0-9_] in JavaScript as well as in Go:

  ui/.../SignUpForm/index.tsx   const nameRegex = /^[\w.-\s]{2,30}$/
  pkg/checker/username.go       usernameReg = `^[\w.\- ]{2,30}$`

This affects every language except English. The second check is not
really about the display name: MakeUsername derives the username from
it, and the username ends up in a profile URL, so it is restricted on
purpose. The restriction is simply applied one step too early.

Answer already solves this elsewhere. Question URLs are transliterated
in pkg/htmltext via unidecode.Unidecode, and MakeUsername already
handles Chinese through pinyin. This change carries that idea through:

  - transliterate the display name before deriving the username, using
    the dependency the project already ships (go-unidecode)
  - drop what transliteration may leave behind — "Ольга" becomes
    "Ol'ga", and an apostrophe is not a valid username character
  - widen the front-end check to Unicode letters and digits

The display name keeps its original spelling; only the derived username
is transliterated:

  Jürgen Müller  ->  jurgen-muller
  José García    ->  jose-garcia
  Ольга          ->  olga
  Ελένη          ->  elene
  Straße         ->  strasse

Chinese input is unaffected — pinyin still runs first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant