josh
/
Prusa-Firmware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

_i and _T differences and usage scenarios

This commit is contained in:
D.R.racer 2019-08-19 16:24:09 +02:00
parent 7ad62bb6df
commit 05fe5b408c
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
lang/translations.md
View File

@ -24,8 +24,9 @@ The reset of this explanation is devoted to `LANG_MODE==1`:
#define _T(s) lang_get_translation(s) #define _T(s) lang_get_translation(s)
``` ```
That explains the macros: 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. - `_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. - `_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). The two 0xff's are somehow magically replaced by real string ID's where the translations are available (still don't know where).
```C++ ```C++