Multilingual slug strategy: Polylang free constraints, Pro purchase decision

[JohnRDOrazio]

Context

The CDCF website runs WordPress + Polylang (free) in directory mode (/it/..., /es/..., etc.), with WPGraphQL feeding a Next.js front-end. We have multilingual page translations for IT, ES, FR, PT, DE in addition to the EN canonical.

Polylang free relies on WordPress's built-in wp_unique_post_slug() for slug uniqueness — and that function enforces uniqueness globally, not per-language. So if the EN page governance is created first and an IT translation also wants to be called governance, WordPress silently appends a numeric suffix → governance-2. Same thing happens to ES/FR/PT/DE if they want the same string.

This is a known limitation of Polylang free. The paid version (Polylang Pro) ships a "Share slugs" feature that hooks into wp_unique_post_slug and skips the uniqueness check when the colliding post is in a different language. The setting is visible but disabled in our admin (screenshot below) with the message "To enable this feature, you need Polylang Pro."

Scope: how widespread is the problem in our content?

I scanned all 24 EN pages and their translations. Every "section root" page has the issue, plus numerous other top-level pages:

EN slug	IT	ES	FR	PT	DE
governance	governance-2	gobernanza ✅	gouvernance ✅	governanca ✅	governance-3
manifesto	(translated)	(translated)	(translated)	manifesto-4	(translated)
contact	contact-2	contact-3	contact-4	contact-5	contact-6
blog	blog-2	blog-3	blog-4	blog-5	blog-6
community	community-2	community-3	community-4	community-5	community-6
projects	projects-2	projects-3	projects-4	projects-5	projects-6
about	about-2	about-3	about-4	about-5	about-6

That's 27 pages with numeric collision suffixes in their URLs across the site.

For pages where the natural translation produces a different word (gobernanza, gouvernance, governanca for "governance"), Polylang free works fine. For pages where the same word would be the natural choice in two or more languages (like manifesto, blog, about, contact, community, projects — many of which are actually loanwords or shared roots in romance languages), every language after the first to claim the slug gets a numeric suffix.

These ugly numeric suffixes appear in user-visible URLs (https://catholicdigitalcommons.org/it/projects-2/...) and weaken multilingual SEO, since the URL no longer carries semantic content for that locale.

There's also a separate but related editorial problem: 5 leaf pages have slugs >50 characters in every non-EN locale (e.g. criteri-di-valutazione-dei-progetti-cdcf-quadro-generale, 56 chars). That's not caused by the slug-collision issue and would need a content-team pass regardless of which option below we choose.

The three options

Option A — translate around the collisions (no spend, more editorial work)

For every collision, pick a target-language word that's distinct from the EN slug:

• Governance: IT governanza, DE verwaltung (or German team's preference). The other three are already fine.
• Contact: IT contatti, ES contacto, FR contact-nous or nous-contacter, PT contato, DE kontakt. All natural in their language.
• Blog: IT blog is normal — but it collides. Could use articoli, but loses the "blog" framing. Same for ES/FR/PT/DE.
• Community: IT comunita, ES comunidad, FR communaute, PT comunidade, DE gemeinschaft.
• Projects: IT progetti, ES proyectos, FR projets, PT projetos, DE projekte.
• About: IT chi-siamo, ES quienes-somos, FR a-propos, PT sobre, DE uber-uns.
• Manifesto: PT alternatives? manifesto is the natural word. Forced into something less natural like nosso-manifesto.

Pros: zero ongoing cost; URLs read fully in their target language; no plugin dependency; aligned with Polylang's free model.

Cons: editorial work for ~27 pages now; some slugs feel forced (e.g. having to invent articoli for what is universally called a "blog" in Italian, or PT manifesto losing its natural slug); every future page needs the same vigilance; the "Project Governance" sub-tree already has translated slugs that may want loanword reconsideration regardless (governance-del-progetto reads more idiomatically in Italian tech contexts than governanza-del-progetto).

Effort estimate: ~1 day editorial pass for current pages + small recurring cost per new page.

Option B — implement a custom wp_unique_post_slug filter (no spend, more code/risk)

Add a hook in our custom theme (wordpress/themes/cdcf-headless/functions.php) that intercepts wp_unique_post_slug() and returns the original (non-suffixed) slug when the colliding post is in a different Polylang language. ~20 lines of PHP. This is essentially a free re-implementation of what Polylang Pro's "Share slugs" feature does internally.

Pros: zero recurring cost; one-time code change; URLs become identical to Option C result.

Cons:

• Couples our theme to Polylang's internal data model. Polylang updates could silently break it.
• Polylang's permalink resolution and admin UI weren't designed to expect cross-language slug collisions, so there are edge cases (e.g. preview URLs, REST API uniqueness on creation, admin slug-editor warnings) we'd have to discover and patch as they arise.
• Effectively re-implementing a paid feature. WordPress/Polylang's licenses are GPL so this is legally fine, but it's worth knowing it's a deliberate paid-tier feature we'd be circumventing.
• Maintenance burden falls on our team forever.

Effort estimate: ~2-4 hours initial implementation, plus unknown ongoing debugging if edge cases surface.

Option C — purchase Polylang Pro (recurring spend, no editorial constraint)

The "Share slugs" toggle becomes available. We can decide per-page whether two languages share a slug, or whether they translate. URL collision suffixes go away.

Approximate pricing (verify with vendor before purchase): around €99/year for 1 site, €199/year for 3 sites, with discounts for renewals after the first year. (Numbers from Polylang Pro pricing page as of last public reference; exact figures should be re-checked at purchase time.) Polylang Pro also bundles other features we may not currently use (translated URL slugs for taxonomies, language switcher widget improvements, REST API support refinements, custom post type translation management). So part of the value is unlocked features beyond just "Share slugs".

Pros: solves the problem cleanly; supports the plugin's authors; unlocks other useful features (some of which we'd benefit from as the site grows — for instance, translated CPT slugs would matter when we expose more public CPT archives); editorial team can focus on content quality not URL gymnastics; small dollar amount for a foundation of our type.

Cons: recurring cost forever; one more vendor dependency; if we ever drop Polylang the migration is bigger; we may not use enough of the Pro features to justify the price relative to Option A's editorial effort.

Effort estimate: ~30 min purchase + install + flip toggle + manually rename ~27 slugs (or write a one-shot migration script using our existing cdcf_api.py).

Recommendation framework for the finance committee

The decision is fundamentally about trade-off between recurring cost and recurring editorial constraint:

• If the website's translated content is expected to grow significantly (new sections, custom post types with public archives, more leaf pages), Pro pays for itself in saved editorial-pass time and avoided URL ugliness.
• If the site's structure is largely stable now and content additions are slow, Option A (one pass + occasional vigilance) is cheaper over a 3-5 year horizon.
• Option B is only attractive if budget is genuinely unavailable — the maintenance risk makes it the worst long-run choice for an organization that takes its tech stack seriously.

Key data points for the committee

• Current scope: 27 pages with collision-suffixed slugs in user-visible URLs.
• Each translated page is a Polylang-managed translation of an EN canonical, so slug renames are non-destructive (don't affect the source post).
• WordPress redirects do not auto-update on slug rename, so any rename requires either keeping the old -N slug as a redirect alias OR ensuring no external bookmarks/inbound links exist (none of these pages are old enough to have meaningful inbound links yet, so this is a one-time low-cost fix if done now).
• Polylang Pro is purchased once per site and includes 1 year of updates + support; renewal is discounted but optional (the plugin keeps working without renewing — you just stop getting updates).

Open questions to resolve before the committee meeting

• Confirm current Polylang Pro pricing (and whether non-profit / educational discounts apply — Catholic non-profit may qualify).
• German team: confirm that verwaltung (or alternative) is acceptable for the IT root vs governance loanword.
• If Option A is chosen, agree on the IT translation philosophy: keep governance as the loanword for technical sub-pages (recommended), or use governanza consistently (more bureaucratic register).
• Editorial: settle on the 5 bloated leaf slugs separately — this needs to happen no matter which option wins.

Related issues

• fix(i18n): double locale prefix in Governance TOC links #53 — fix(i18n): double locale prefix in Governance TOC links
• fix(seo): sitemap-[lang].xml emits doubled locale prefix and broken hreflang #54 — fix(seo): sitemap-[lang].xml emits doubled locale prefix and broken hreflang
• feat(i18n): consume Polylang translated slugs in nav and routing #55 — feat(i18n): consume Polylang translated slugs in nav and routing

The slug strategy decided in this discussion will inform how #55 is implemented (specifically: which paths get baked into the pathnames map at build time).