extract will affect for comment _(xxx)

[Hpbbs]

example follows: in file xx.h

//#define CODE_CHECK_BTN_CONFIRMTEXT ("#ffffff CHECKED#") //#define CODE_CHECK_BTN_CANCELTEXT ("#ffffff CANCEL#")

define PROTOCOLHEADER ("protocol_header")

define WEARABLEHEADER ("wearable_header")

<<<<< it will generate:

ffffff CHECKED

ffffff CANCEL

protocol_header wearable_header

but first and second was not expected

[puzrin]

https://github.com/lvgl/lv_i18n/blob/8bf1fd3ab37251667be11f27efcadb1ae8cd3e25/lib/parser.js#L11-L28

Extractor does not process C semantics. It uses simple regexps to search patterns. Even if we invent kludge for single line comments, multiline comment will fail.

No plans to fix, but if someone suggest PR it will be accepted.

[bubeck]

Extractor is fragile for many more problems, like multi line strings, String concat with constants like LV_SYMBOL_WARNING "This is a warning with an icon".

What do you think about changing the extraction process:

1. Ask user to use "-DLV_I18N_EXTRACT" to compile sources of to extract them.
2. Change _() and _p() in case of LV_I18N_EXTRACT to generate strings with markers,

     printf(_("hello world"));

will be changed to

printf( "LV_I18N-START" "hello world" "LV_I18N-END");

3. read throught binary and collect every string between "START" and "END".

What do you think?

[puzrin]

IMO that's very complicated => difficult to use.

I'd suggest to not invent anything new and borrow existing methods. For example, inspect how get_text()-based things work. Current regexp is quick and dirty, and probably can be improved. It was created becuse something good enough required very urgent.

[bubeck]

I looked at xgettext at https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/src/x-c.c;h=917bd7c88deb9cc2d19b975962dd3a1cd2014c4e;hb=HEAD

It is a very complicated c source containing a nearly full fledged (preprocessor) dealing specfically with all aspects of C. Additional parsers for other languages. For C only it is around 2400 LOC. I dont think, that we can transfer this to lv_i18n as it is way too complicated.

As lv_i18n deals with "mainly embedded" we can assume, that programmer take care of their notation to be lv_i18n compatible and keep the simple regex as a solution.

thanks for creating lvgl and lv_i18n!