[tractorjuice]

Addresses #766. Does not close it, see "What remains" below.

The bug

slugify is implemented four times: bash and Python, each in a root copy and a plugin copy. f8544b4a (#204, "preserve accented characters in slugify") landed in scripts/bash/common.sh only. The other three kept the original [^a-z0-9] class:

$ slugify "Café Modernisation"
scripts/bash/common.sh                        -> café-modernisation
plugins/arckit-claude/scripts/bash/common.sh  -> caf-modernisation
scripts/python/common.py                      -> caf-modernisation
plugins/arckit-claude/scripts/python/common.py-> caf-modernisation

The character is dropped mid-word. Marketplace users never touch scripts/bash/, so the single copy that carried the fix was the one they never ran, and #204 has been effectively unfixed for them since March.

Why the fix was not just "port #204"

[:alnum:] follows LC_CTYPE, so the root copy's output depended on the caller's environment:

LC_ALL=C.UTF-8   -> cafe-zurich-ecole   (accents kept)
LC_ALL=C         -> caf-z-rich-cole     (the fix silently reverts)

So "preserve accents" was not a stable behaviour to converge on.

The fix

All four copies transliterate to ASCII from a shared table (Latin-1 Supplement plus the Latin Extended-A characters used across European official languages). Characters outside the table are dropped, consistently in both languages.

"Café Zürich ÉCOLE"  ->  cafe-zurich-ecole
"Straße"             ->  strasse
"Łódź Rail"          ->  lodz-rail
"日本 Project"        ->  project

Transliteration over preservation because these names become filesystem paths, git entries and published URLs, and because macOS stores accents decomposed (NFD) where Linux composes them (NFC), so a literal accented directory name can mismatch across a clone.

Two portability details, both load-bearing:

• The bash implementation pins LC_ALL=C for the byte-oriented steps and spells out its character classes rather than using \+ or \|, which are GNU extensions and not portable to BSD sed. The previous implementation used both.
• Python lowercasing is restricted to A-Z. str.lower() maps the Turkish dotted capital İ to i plus a combining dot, which would have diverged from bash on that one input.

Tests

New tests/plugin/test_slugify.py, written before the fix (confirmed RED at 57 failed / 45 passed, the 45 being the plain-ASCII corpus that already worked; GREEN at 102 passed):

• each of the four copies against a shared corpus
• all four agree on every corpus entry, since the table is duplicated four ways and nothing else stops it drifting
• bash output identical under LC_ALL=C and LC_ALL=C.UTF-8
• no copy can emit non-ASCII

End to end, create-project.sh --name "Café Zürich Modernisation" now creates 001-cafe-zurich-modernisation.

Full suite 1399 passed / 225 skipped, 285 node tests, sync-shared-assets.py --check clean, markdownlint clean. Extensions regenerated.

What remains on #766

• No general parity guard for the two common.sh copies. This PR adds one for slugify specifically.
• The find_repo_root divergence (.arckit/ in the root copy, projects/ in the plugin copy) is deliberate, and stated in the Python docstrings, but still undocumented in the bash copies.
• get_templates_dir sits in a different position in each bash copy, which is cosmetic but will trip a naive diff-based guard.

Relationship to #764

Independent. Both touch common.sh but in different functions, and this branch is cut from main, so they merge in either order.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VKbHCujejpxkgvh47BndDE