Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

24.03.2023

Коли закладати локалізацію додатка?

Обговорення вчорашньої статті на DOU порушило цікаве питання. А саме, чи має локалізація додатка бути закладена на початку розробки? Я маю на увазі — чи треба від початку роботи складати рядки у словник та використати в коді ключі перекладу замість рядків без перекладу?

На моєму досвіді, щоб це мало сенс, треба дві умови. Перше — щоб інтерфейс додатка був чітко заданий заздалегідь. Якщо розробка має, так би мовити, характер Agile, та екрани змінюються з новими вимогами та випробуваннями, то ви змарнуєте купу часу на підтримку словника для фраз, які не попадуть до остаточної версії.

Друге — що багатомовність має бути обґрунтована потребами бізнесу. Та головне, що на перекладі додатка інтернаціоналізація тільки починається. Треба ще продавати його на різних ринках, робити розкрутку, рекламу, підтримку користувачів. Перекладати інформаційні матеріали, нарешті. Якщо бізнес не планує це робити, то можливість зміни мови в додатку має суто символічний характер.

Я вважаю, що такий збіг обставин трапляється рідко. Так, якщо робити сервіс мікрокредитів для європейського банку, то в них і дизайн готовий є, і перелік країн, де він буде представлений. В інших випадках раннє впровадження локалізації тільки вадить розробці. Як я показав, додати i18n пізніше — цілком реально, а якщо це так, то не бачу сенсу думати про інтернаціоналізацію раніше, ніж це буде потрібно.

Навіть при розробці нового функціоналу в додатку, що вже має i18n, я схиляюсь до того, щоб нові рядки локалізувати вже наприкінці іншої розробки. До того ж як я писав в статті, в деяких місцях i18n здатний суттєво ускладнити архітектуру. Доведеться думати не тільки про розвʼязання базових задач бізнесу, а ще й про те, як розвʼязок локалізувати. Як на мене, то простіше ці дві справи робити окремо.