lvgl / lv_i18n

Internationalization (i18n) for LVGL
MIT License
57 stars 17 forks source link

Newline support/Unwanted escaping of backslash character #30

Closed Crazor closed 2 years ago

Crazor commented 3 years ago

First of all, thank you for this library! This is just right for my needs (no dependencies, yet complete with tool support for string extraction). Worked on the first try, too...

I need to specify newlines in my translated strings. The obvious way to just include \n doesn't work, because the resulting C string has the backslash escaped with another backslash, i.e. 'Hello\nworld' becomes "Hello\\nworld".

Is this a bug or am I missing something?

Edit: I changed the quotes from double to single above, because that is what I actually did use in code before and what triggered the behaviour. See my next comment.

puzrin commented 3 years ago

I can not reproduce. Backslashes may be duplicaed in keys, but not duplicaed in value.

You can use any word for phrase key (instead of real phrase), and then assign real value in translation. Usually default translation has zero content, because default value = key value. But that's not mandatory.

Please, create a test repo with minimal sample. It's a bit difficult to understand problem from description.

Crazor commented 3 years ago

While preparing the test case, I noticed that the double backslash does only occur if I use single quotes in the .yml file. Using double quotes, everything works just fine. I suspect that this is Working As Intended and it is just me not understanding the finer semantics of .yml files. So feel free to close this issue, but maybe consider adding a note to the documentation. Otherwise, just let me know if you want me to push my example project.

puzrin commented 3 years ago

Double quoted strings supports escaping (\n) inside. Single quoted take string as is.

In short - don't use quoting, or use single quoting is something goes wrong. Or read yaml spec, if you have a lot of time and wish to break your brain :)

liangyongxiang commented 2 years ago

I have the same problem. Here is the example: https://github.com/liangyongxiang/lv_i18n_test

In the c code, I am using _("line1\nline2\nline3"), which is expected to be {"line1\nline2\nline3", "line 1\n line 2\n line 3\n"}. Actually it is: {"line1\\nline2\\nline3", "line 1\\\n line 2\\\n line 3\\\n"}, link: https://github.com/liangyongxiang/lv_i18n_test/blob/master/lv_i18n.c#L38=

kisvegabor commented 2 years ago

I had the same issue but putting the translation into " solved it for me. E.g. in the yml file:

de:
  a\nb\nc: "some\ntranslation\nhere"
kisvegabor commented 2 years ago

I was happy too early. My above comment solves the issue of \n in the translated text but biggest problem is that _("a\nb\nc") will be exported as:

  a\nb\nc: "some\ntranslation\nhere"

And then this will be generated:

   {"a\\nb\\nc",  "some\ntranslation\nhere"},

And as a\\nb\\nc != a\nb\nc lv_i18n won't find translation for a\nb\nc. The solution seems to be to replace \\ns with \n in the tags when generating lv_i18n.c. Other special characters might be affected too, but at least replacing this one would solve the most possible issue.

puzrin commented 2 years ago

Here is example of difference with quoting in yaml:

http://nodeca.github.io/js-yaml/#yaml=LSAiYVxuYlxuYyI6ICJzb21lXG50cmFuc2xhdGlvblxuaGVyZSIKLSBhXG5iXG5jOiAic29tZVxudHJhbnNsYXRpb25cbmhlcmUiCi0gJ2FcbmJcbmMnOiAic29tZVxudHJhbnNsYXRpb25cbmhlcmUi

So, with " we can be sure yaml data is correct (at least). Probably, bug in import/export between C and JS string formatting.

I'm a bit busy with other things now. Relocating & cutting urgent tails.

rlidwka commented 2 years ago

I have the same problem. Here is the example: https://github.com/liangyongxiang/lv_i18n_test

If you want to write newlines as \n, you need to use double quotes in your yaml.

If you don't use quotes, yaml parser treats it as literal backslash+"n". This is intended behavior as per yaml spec.

rlidwka commented 2 years ago

Fixed in https://github.com/lvgl/lv_i18n/commit/a5c19c3c20bc92b6dbef2506941421ed1509c49d, thanks for reporting.

liangyongxiang commented 2 years ago

Fixed in a5c19c3, thanks for reporting.

Yes, It worked