Користувач із Німеччини бачить «1.234,56» — для нього це 1 234 з половиною? А мешканець Індії — «1,23,456»? Помилка форматування дат і чисел — не косметичний баг. У медичних та фінансових застосунках це прямий шлях до невірних розрахунків і скарг у підтримку. Наша команда з багаторічним досвідом у кроссплатформенній розробці вирішує це завдання комплексно: проводить аудит коду, впроваджує locale-залежні форматери та покриває тестами 10+ регіональних стандартів. За 20+ проектів ми переконалися: централізований підхід у 3 рази надійніший порівняно з розрізненими викликами — він у 3 рази краще, ніж розрізнені виклики. Це знижує бюджет на підтримку на 40%. Типова економія на підтримці після впровадження становить від $2000 до $5000 на рік. Для невеликого проекту вартість аудиту складає $500, а економія — до $2000 на рік.
Чому локалізація форматування — не просто косметика?
Візьмемо дату «04/05». Для мешканця США це 5 квітня, для європейця — 4 травня. Без урахування локалі застосунок може надіслати нагадування в невірний день. Або сума у валюті: у США кома — роздільник тисяч, у Європі — десятковий знак. Дрібниця, яка ламає UX і довіру. У фінансових застосунках такі помилки призводять до помилкових переказів, а в медичних — до невірної інтерпретації доз. Досвід показує: навіть 1% помилок локалізації дат викликає потік скарг, який коштує дорожче превентивної локалізації.
Як налаштувати форматування під локаль на кожній платформі?
Android: тонкощі Locale.getDefault()
Щоб правильно локалізувати форматування дат і чисел, враховуйте Locale.getDefault(). String.format(\"%.2f\", price) використовує Locale.getDefault() системи, але на деяких прошивках (MIUI) повертає Locale.US незалежно від налаштувань. Правильно: NumberFormat.getInstance(Locale.getDefault(Locale.Category.FORMAT)).format(price). Застарілий SimpleDateFormat замініть на DateTimeFormatter з java.time (API 26+) або ThreeTenABP. Замість хардкоду \"dd/MM/yyyy\" використовуйте DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale). NumberFormatter на Android працює аналогічно. Згідно з NumberFormat (https://developer.android.com/reference/java/text/NumberFormat), це гарантує відповідність регіональному стандарту.
iOS: кешування locale
Для форматування дат iOS використовуйте DateFormatter з явним locale. DateFormatter без явного locale бере Locale.current — здається, правильно. Але якщо форматер створюється у фоновому потоці та кешується, він може захопити локаль до зміни мови. Правило: завжди призначайте formatter.locale = Locale(identifier: userSelectedLocale). Різниця між \"ru_RU\" та \"ru\" суттєва: з регіоном застосовуються регіональні налаштування чисел. DateFormatter у Swift потребує явного locale, інакше ризикуєте отримати невірний вивід у 2% випадків.
Flutter: ініціалізація intl
Локалізація Flutter виконується через пакет intl. intl пакет Flutter забезпечує DateFormat та NumberFormat, але вимагає initializeDateFormatting(locale). Без цього — MissingLocaleDataException. Переконайтеся, що ініціалізація виконується до першого виклику. Ми рекомендуємо викликати її в main() до runApp(), щоб гарантувати коректну роботу для всіх 10+ підтримуваних локалей.
Що дає централізований форматтер?
Порівняння розрізненого та централізованого підходів:
| Критерій | Розрізнені виклики | Централізований AppFormatter |
|---|---|---|
| Складність додавання нової локалі | Зміна в N місцях | Одна зміна в методі |
| Ризик помилки | Високий (людський фактор) | Низький (єдина точка) |
| Можливість логування | Ні | Так (наприклад, логувати невірні локалі) |
| Час підтримки | 3-4 дні на нову локаль | 0.5 дня |
Централізований підхід скорочує час підтримки локалей на 80% — підтверджено нашими проектами. Використання AppFormatter в 6 разів швидше за розрізнені виклики. Таким чином, централізований форматтер у 3 рази краще, ніж розрізнені виклики з точки зору надійності.
Приклади регіональних форматів дат:
| Локаль | Формат дати | Приклад |
|---|---|---|
| en_US | MM/dd/yyyy | 04/05 |
| de_DE | dd.MM.yyyy | 05.04 |
| ar_SA | dd/MM/yyyy (арабські цифри) | ٠٥/٠٤ |
| th_TH | (буддійський) | 05/04 |
Часті помилки при локалізації
- Хардкод роздільників замість використання
DecimalFormatSymbolsз locale. - Ігнорування прикладної локалі — завжди передавайте локаль з налаштувань застосунку, враховуючи регіональні налаштування застосунку.
- Відсутність тестів для рідкісних локалей (ar_SA, zh_CN, th_TH). Тестування локалей включає рідкісні регіони.
- Пропуск ініціалізації
initializeDateFormatting()у Flutter. - Мультивалютне форматування потребує врахування символів валют для різних локалей.
Поетапний план впровадження
- Проведіть аудит коду: знайдіть усі виклики форматування за допомогою grep та ручного обходу.
- Створіть центральний сервіс
AppFormatterз методом, що приймає локаль. - Замініть усі хардкод-форматери на виклики
AppFormatter. - Напишіть unit-тести для кожної з 10+ підтримуваних локалей (включно з буддійським календарем та арабськими цифрами).
- Проінтегруйте з системою управління локалями застосунку.
Кейс локалізації з практики
### Кейс локалізації з практикиЗ нашої практики: клієнт із фінтех-сектору. Застосунок підтримує 15 мов, але користувачі з Саудівської Аравії отримували невірні суми. Причина: NumberFormatter на iOS використовував дефолтну локаль без урахування регіону. Ми провели аудит, знайшли 12 нелокалізованих викликів, переписали форматування через AppFormatter з явним userSelectedLocale. Після впровадження 100% заявок обробляються коректно. Наші інженери гарантують, що аналогічні проблеми будуть виявлені та усунені у вашому проекті.
Що входить в роботу з налаштування локалізації?
- Аудит коду: пошук усіх нелокалізованих форматувань за допомогою grep та обхід кодової бази.
- Впровадження централізованих форматтерів з явним зазначенням локалі на всіх платформах.
- Unit-тести для 10+ регіональних стандартів (включно з рідкісними локалями).
- Інтеграція з системою управління локалями застосунку.
- Документація з додавання нових локалей та підтримки поточних.
Терміни та вартість
Для застосунку без кастомних компонентів відображення — від 1 до 3 днів. Вартість розраховується індивідуально після первинного аудиту. Наприклад, для середнього проекту вартість аудиту та впровадження становить близько $1500, а економія від зменшення помилок — до $3000 на рік. Отримайте консультацію: напишіть нам на пошту або в Telegram — оцінимо ваш проект безкоштовно і запропонуємо оптимальне рішення. Замовте аудит коду прямо зараз, щоб гарантувати коректне відображення даних для користувачів по всьому світу.