Adding a New Language

Adding a New Language

This page describes everything that has to happen for a new language to work end-to-end - based on what was actually needed when Spanish (es) was added. Use it as a checklist for any future language.

1. UI strings - resources/lang/{code}/all.php

Copy an existing file (resources/lang/en/all.php or resources/lang/hu/all.php) into a new folder, e.g. resources/lang/es/all.php, and translate every value - keep every key exactly the same, only the strings change.

No separate registration step is needed. UsersController builds the language-switcher list dynamically:

$languages = array_diff(scandir(resource_path('lang')), ['..', '.']);

As soon as the folder exists with a properly filled all.php, the new language automatically appears in My Settings.

2. Seed data - database/seeders/lang/{code}.php

This is a separate file from step 1, and easy to forget. DatabaseSeeder picks which one to run based on the APP_LANGUAGE env value:

database_path("seeders/lang/{$mainLanguage}.php")

This file must exist with the same top-level array keys as en.php/hu.php: intervention_templates, console_scripts, ws_filters, notifications, global_settings, downloads, documents, service_updates.

Important: the documents array should list all language variants of the installation/user guides, not just the new one - this is what makes a fresh install always seed every language's documentation regardless of which APP_LOCALE was chosen during setup. Keep this array identical across en.php, hu.php, and the new language's file.

3. Two places that used to be hardcoded to hu/en (already fixed, but worth knowing about)

These were real bugs found when Spanish was added as the third language - both are now fixed to be language-agnostic, so a fourth language shouldn't need any code changes here. Still worth checking if either regresses:

• RegisterController::store() - originally never set a new user's language field at all (always null, silently falling back to APP_FALLBACK_LOCALE). Fixed to $user->language = config('app.locale');
• UsersController::switchLanguage() - originally a hardcoded switch that only accepted "hu"/"en", silently nulling out anything else. Fixed to check against the same scandir(resource_path('lang')) list used by the settings page, so it now accepts whatever languages actually exist.

4. install-biglan.sh - locale prompt

The installer's language prompt has its own small, hardcoded allow-list that needs updating for each new language:

LOCALE_CHOICE=$(ask "Default language (hu/en/es)" "en")
case "${LOCALE_CHOICE}" in
    hu|es) ;;
    *) LOCALE_CHOICE="en" ;;
esac

Add the new code to both the prompt text and the case pattern (e.g. hu|es|de) ;;), otherwise the script will silently fall back to en for the new language.

5. Documentation (PDFs)

Three documents need a full translation, matching the structure/formatting of the existing