From 05fe5b408c49a826f10881635b5907e80384dce3 Mon Sep 17 00:00:00 2001 From: "D.R.racer" Date: Mon, 19 Aug 2019 16:24:09 +0200 Subject: [PATCH] _i and _T differences and usage scenarios --- lang/translations.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lang/translations.md b/lang/translations.md index 295bd8042..f0293f1ca 100644 --- a/lang/translations.md +++ b/lang/translations.md @@ -24,8 +24,9 @@ The reset of this explanation is devoted to `LANG_MODE==1`: #define _T(s) lang_get_translation(s) ``` That explains the macros: -- `_i` expands into `lang_get_translation((__extension__({static const char __c[] PROGMEM_I1 = "\xff\xff" s; &__c[0];})))` . Note the two 0xff's in the beginning of the string. -- `_T` expands into `lang_get_translation(s)` without the two 0xff's at the beginning. +- `_i` expands into `lang_get_translation((__extension__({static const char __c[] PROGMEM_I1 = "\xff\xff" s; &__c[0];})))` . Note the two 0xff's in the beginning of the string. `_i` allows for declaring a string directly inplace of C++ code, no string table is used. The downside of this approach is obvious - the compiler is not able/willing to merge duplicit strings into one. +- `_T` expands into `lang_get_translation(s)` without the two 0xff's at the beginning. Must be used in conjunction with MSG tables in `messages.h`. Allows to declare a string only once and use many times. +- `_N` means not-translated. These strings reside in a different segment of memory. The two 0xff's are somehow magically replaced by real string ID's where the translations are available (still don't know where). ```C++