Skip to content

Transliterate a name that ASCII cannot carry, instead of dropping letters #9

Closed

Description

@berb

slugify (cmd/exposer/index.go) normalises with NFKD and then keeps ASCII
only, mirroring Python's .encode("ascii", "ignore"). Characters that have no
ASCII decomposition are dropped rather than transliterated:

Name Slug today Slug wanted
Allgäu allgau allgaeu, or allgau kept for compatibility
Œuvre uvre oeuvre
東京 "" (build now fails, #7) tokyo
Москва "" (build now fails, #7) moskva

Two separate defects:

  1. A name in a non-Latin script has no slug at all. Since Refuse an album, tag or place that has no address of its own #7 that fails the
    build naming the album, tag or place, which is honest but leaves exposer
    unusable for a library whose albums are named in Japanese, Russian, Greek or
    Hebrew. The error message can only suggest renaming the album.
  2. A ligature loses a letter silently. Œuvre becomes uvre, which no one
    would choose as an address, and nothing reports it.

Options, roughly in order of cost:

  • Transliterate the Latin supplement by hand: ä → ae, ö → oe, ü →
    ue, ß → ss, œ → oe, æ → ae, ø → oe, å → aa. Small, no
    dependency, and the German case is the one this library actually meets.
  • A general transliteration table for other scripts. Much larger, and the
    romanisation of a CJK name is not something a table can settle correctly
    (東京 is tokyo in Hepburn, toukyou in Kunrei with long vowels marked).
  • Let the library decide: a slug: field in _data/albums/<slug>.yaml,
    _data/tags/ and _data/locations/, so the photographer picks the address
    and exposer never guesses. This also answers the CJK case without a table,
    and it is probably the right answer for an album, which already has a file.

Whichever is chosen, the URLs are a promise: changing how an existing name
slugs moves pages that are already published and already linked. So
transliterating the Latin supplement is a breaking change for any site with an
umlaut in an album name, and needs either a major version or a documented
compatibility switch. Adding an explicit slug: field is additive and breaks
nothing.

Spec: this needs a requirement before it has an implementation. R-3, R-19 and
R-10 all name a slug without saying what one is; the rule belongs in
docs/spec.md §11 beside Q7's photo id.

Related: #7, which made the empty slug a hard failure rather than a broken site.

Activity

  1. added a commit that references this issue on Oct 17, 2026
    a410158
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions