Locale & Translations
The starter kit uses Laravel's lang/ structure for translations and exposes those strings to Vue through laravel-vue-i18n. This gives both backend and frontend a shared translation source.
Core Flow
- translation files live under
lang/ - the backend uses them through
__() - Vue reads them through
$t()and related helpers - the selected interface locale is stored in a long-lived cookie (survives logout; the legacy session key is read only as a fallback)
- the allowed locale list comes from the settings layer
Vue and PHP Usage
Inside Vue:
<template>
<h1>{{ $t('sk-user.title') }}</h1>
</template>
Inside PHP:
__('sk-user.title');
Switching Locale
The interface language switch runs through a lightweight public helper route:
| Method | Path | Route name | Purpose |
|---|---|---|---|
POST |
/locale |
locale.update |
Updates the active interface locale (long-lived cookie) |
The controller only accepts a locale value if it exists in the active language list, then persists it in a forever cookie (so it survives logout — the session is flushed on sign-out) and redirects back. SetLocale reads this cookie on every request, falling back to the legacy session key for older installs.
Where Active Languages Come From
The active locale list is driven by application settings. The settings layer and service providers decide which languages are available in the UI, so the locale switch only accepts locales that are currently enabled.
Build Behavior
Translation files are compiled into a client-consumable format during the build. On the frontend, only the active locale is lazy-loaded, which helps avoid shipping unnecessary translation payloads.
Relation to Multi-Locale Fields
Some admin forms may render locale-specific inputs. For example, role display names can be shown as one input per active locale. Because of that, locale configuration matters not only for language switching but also for multi-language admin screens.