Коли говорять про локалізацію, найчастіше мають на увазі переклад інтерфейсу: назви кнопок, повідомлення, заголовки та підказки.
Але користувач читає не тільки текст. Він бачить дати, час, числа, грошові суми, назви місяців і часові пояси.
Тому ситуація, де українська й англійська версії мають правильні переклади, але одна показує 18:45, а інша 6:45 PM, теж є рішенням локалізації.
Локалізація - це не тільки словник перекладів
Для одного й того самого моменту часу різні інтерфейси можуть показати різні значення:
18:45;6:45 PM;27.10.2026, 18:45;Oct 27, 2026, 18:45.
Усі ці варіанти можуть описувати ту саму дату. Відмінність полягає у способі представлення даних користувачеві.
Типове налаштування мови не завжди дорівнює продуктовому правилу
Браузерні засоби форматування вміють самі вибирати звичний для мови формат.
Це зручно, але автоматичний вибір не завжди збігається з вимогами конкретного продукту.
Наприклад, в адміністративній панелі команда може свідомо використовувати 24-годинний формат і для uk, і для en, щоб час однаково читався в таблицях, журналах подій та фільтрах.
Intl.DateTimeFormat дозволяє явно зафіксувати 24-годинний формат
const formatTime = (value, locale) => { return new Intl.DateTimeFormat(locale, { hour: '2-digit', minute: '2-digit', hour12: false, }).format(new Date(value));};Тут locale усе ще впливає на інші мовні правила, але hour12: false явно задає формат часу.
Тобто мова залишається локалізованою, а формат годинника контролюється окремим продуктовим рішенням.
Те саме стосується повної дати й часу
const formatDateTime = (value, locale) => { return new Intl.DateTimeFormat(locale, { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', hour12: false, }).format(new Date(value));};У цьому варіанті мова може впливати на порядок і роздільники дати, але час усе одно залишається 24-годинним.
Саме так можна поєднати локальне представлення дати з єдиним форматом часу в адмінці.
Laravel краще передає момент часу, а форматування залишає шару представлення
Якщо API або Inertia-відповідь передає дату як ISO 8601, клієнтська частина має достатньо інформації, щоб показати її відповідно до мови та правил інтерфейсу.
Це гнучкіше, ніж заздалегідь перетворювати дату в готовий рядок на сервері, якщо той самий timestamp використовується в різних мовах або компонентах.
return [ 'createdAt' => $model->created_at?->toISOString(),];Формат часу і часовий пояс - різні речі
18:45 замість 6:45 PM змінює лише представлення години.
А зміна часового поясу може змінити саме значення години.
Тому під час виправлення формату важливо не змішати дві задачі: "як показати час" і "для якого часового поясу його показати".
Формат краще визначити в одному місці
Якщо кожна таблиця або компонент створює власний Intl.DateTimeFormat, інтерфейс легко стає непослідовним.
Один екран показує 18:45, інший 6:45 PM, а третій додає секунди.
Тому корисно винести форматування в спільний helper або composable і використовувати його в усій адмінці.
export const formatAdminTime = ( value, locale,) => new Intl.DateTimeFormat( locale, { hour: '2-digit', minute: '2-digit', hour12: false, },).format( new Date(value),);Що варто перевірити тестами
UA admin:18:45 EN admin:18:45 Do not expect:UA -> 18:45EN -> 6:45 PMУ тестах важливо перевіряти не тільки переклад підписів, а й кінцеве представлення значень.
Якщо продукт визначив, що адмінка використовує 24-годинний час для обох мов, це повинно бути зафіксовано так само явно, як будь-який інший UI-контракт.
Мова не повинна випадково визначати весь формат інтерфейсу
Автоматичні правила locale дуже корисні, але вони є лише початковим значенням, а не заміною продуктових вимог.
Якщо користувачам адмінки потрібен однаковий 24-годинний формат у різних мовах, його краще задати явно.
Локалізація - це не тільки питання "якою мовою написано", а й питання "у якому вигляді користувач читає дані".
Переклад може бути правильним, але інтерфейс усе одно буде локалізований неповністю, якщо формат даних суперечить правилам продукту.
