Yboichuk/sdk/language localization module

[black-ghost-off]

add support for multi language on keira os

` // Initialize the Localization object
lilka::Localization localization;

// Add some localized strings
localization.addString(lilka::Language_Code::EN, "greeting", "Hello");
localization.addString(lilka::Language_Code::UA, "greeting", "Привіт");

// Get the greeting message in English
String greetingEn = localization.getString(lilka::Language_Code::EN, "greeting");
Serial.begin(9600);
Serial.println(greetingEn);

// Get the greeting message in Ukrainian
String greetingUa = localization.getString(lilka::Language_Code::UA, "greeting");
Serial.println(greetingUa);
`

[and3rson]

Ідея хороша, але робити це в ран-таймі не дає ніяких переваг.
Краще виносити локалізації в окремі заголовні файли і зробити якийсь макрос, типу TR(), який буде брати відповідну стрінгу з пам'яті.

[and3rson]

Можна ще спробувати підключити якусь лібу для цього, яка б була сумісна з, скажімо, gettext

[and3rson]

Ось варіант, як можна мінімізувати час пошуку перекладу і переконатись, що ніхто не забуде перекласти якусь стрінгу:

// lilka/i18n.h
#include <stdio.h>

#define TR(KEY)  (lang == UA) ? HELLO_UA : HELLO_EN

typedef enum {
    UA,
    EN,
} lang_t;

lang_t lang = UA;

void setLang(lang_t newLang) {
    lang = newLang;
}

// myapp.h
#define HELLO_UA "Привіт!"
#define HELLO_EN "Hello!"

// myapp.cpp
void foo() {
    printf("%s\n", TR(HELLO));
    setLang(EN);
    printf("%s\n", TR(HELLO));
    return 0;
}

// otherapp.h
#define GOODBYE_UA "Бувай!"
#define GOODBYE_EN "Goodbye!"

// otherapp.cpp
void bar() {
    printf("%s\n", TR(GOODBYE));
    return 0;
}

В результаті, всі стрінги будуть визначені на етапі компіляції, а їх вибір буде здійснюватись тернарним оператором в ран-таймі (макро TR). При цьому збережеться статична типізація, оскільки цей механізм більш строгий. І найголовніше - це все буде в флеш-пам'яті, всі стрінги будуть const і не буде випадкових дублювань.

[black-ghost-off]

В моєму випадку можлива підтримка любої кількості мов і розробка додатків з підтримкою тих мов які ти знаєш з можливим доповненням в подальшому. В твоєму випадку ми прив'язані що обов'язково має бути переклад на дві мови.

Можна попередити що стягування "мовного пакету" варто(не обов'язково) робити тільки при ініціалізації апки, а не в циклі

[ReAlUA]

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

#define GOODBYE_UA "Бувай!"
#define GOODBYE_EN GOODBY_UA

і доперекласти пізніше.
Але якщо хтось додасть PL, і воно буде додане в TR(), то треба буде скрізь пододавати затички типу #define GOODBY_PL GOODBY_UA, інакше поламаються всі билди. Або робити макроси TR() для кожного застосунку окремо, що як на мене теж не дуже добре.
Щось на зразок згаданого gettext набагато краще. Основні розробники застосунку можуть просто додавати щось мовою (мовами) які знають, і не турбуватися навіть які мови взагалі в підтримуються у цьому застосунку на цей час.
Так, у новій версії іншою мовою просто виявиться частина не перекладеною. Так буде доки той, хто підтримує цю мову в усій системі, не перекладе ці нові рядки. Як я коли мав час, то підтримував на transifex українську локалізацію оболонки arduino, хоч сам нею не користувався і джаву не знаю :-).

p.s. Мабуть, малося на увазі

#define TR(KEY)  ((lang == UA) ? KEY ## _UA : KEY ## _EN) // Якщо хочемо за умовчанням EN