One Localization System for Ukrainian and English ICanUp
Update

One Localization System for Ukrainian and English ICanUp

ICanUp moved to one localization infrastructure: Ukrainian remained the default locale without a prefix, English uses /en, and all public routes gained one shared locale-aware routing contract.

Multilingual support existed in ICanUp from the beginning, but as the site grew, it became important not to leave localization as a collection of separate conditions spread across the application.

In August 2026, public localization moved to one infrastructure based on AVN Laravel Localization.

The goal was simple: one set of rules for route registration, locale resolution, language switching, canonical URLs, and public links across the project.

The URL structure became predictable

Ukrainian Without Prefix

The default locale uses clean public URLs without /uk, keeping the primary version short and canonical.

English Through /en

The English version uses a stable /en prefix while sharing the same public routes and route names.

Locale from URL

The current language is resolved from the explicit URL, while a preferred locale cannot unexpectedly override it.

Canonical Redirects

Non-canonical default-locale URLs such as /uk redirect to the correct unprefixed version.

Shared slugs became part of the multilingual model

Another important decision was moving Posts and Categories to one product-owned slug shared across locales.

Ukrainian and English URLs now differ by the locale prefix rather than by two independent slugs.

The same entity therefore keeps a stable URL identity:

  • /posts/example-slug
  • /en/posts/example-slug

This simplified language switching, sitemap generation, RSS, hreflang, and internal link generation.

Language switching stopped being a collection of exceptions

Route Parameters

Route parameters are preserved during a language switch, keeping the visitor on the same entity.

Query Parameters

Filters, search parameters, and other query strings remain intact when switching locale.

Strict Locale Handling

Malformed, unknown, or disabled explicit locales return 404 instead of silently falling back.

Stable Route Names

Existing logical route names stayed stable even after replacing the underlying localization infrastructure.

Localization became infrastructure, not a page-level feature

After the integration, the homepage, posts, categories, pages, and other public routes began using one locale-resolution mechanism.

At the same time, Admin, API, authentication, webhooks, and service routes remained outside the public localization layer and did not gain unnecessary dependencies.

It was also important that localized routes continued to work correctly with Laravel route cache and application optimization.

This decision became an important foundation for the next stages of ICanUp.

New Pages, Series, Forms, News, and other public modules could now connect to an existing locale-aware routing contract instead of implementing their own localization rules.

From this point on, the Ukrainian and English versions of ICanUp became two representations of one system rather than two parallel sets of routes.