Exporting JSON file with Emojis transforms emojis.

[Tomato6966]

Hi there, I came accross few bugs, from the docker-image!

• JSON Export --> just shows the unicode emoji and not the real emoji
• Newlines aren't really visible

How it's in the exported json file:

How it should be:

Also another problem:

• When users are translating, they can't see if there is a \n aka new line, or not
• Either show it as a \n or as a dedicated new-line-break (i'd preferre the first one)

Also another slight problem: -> I have English (British) and English (United State) -> The config I set for my project is, that English (United State) is the default one, however it's always English (British) selected on default.

[JanCizmar]

That's actually for 2 separate issues. The first one is backend issue, the second one is more related to frontend.

1. It's definitely a bug, I'll look at it.
2. I think this is more complex and would require to actually add some way to define the context of translations. Since Tolgee primarily targets to Web Application development, we expect that the string will render inside DOM/HTML context, so the "\n" char will be ignored.

However, we know that this is not correct approach. So I guess we should enable user to define context of the translation/key. So user should be able to define whether the translations are HTML or plaintext. Or whether to use ICU message format or turn it off. This might be a part of Universal Format Support features, we have on roadmap, but IMO we should consider adding these features ASAP, since it's simple and might help a lot.

Thoughts? @stepan662 @cyyynthia

[stepan662]

I guess we could have some settings for the editor (ICU on/off). Not sure about the new lines, could also be a setting.

[JanCizmar]

It should be 3 state switch ICU/HTML/nothing, right?

• ICU has it's own way of interpreting tags, but doesn't support self enclosing tags like `
  
• HTML wouldn't warn on ICU message errors, but would report HTML errors, no plurals/dates/selects rendered
• Off no errors reported at all, no plurals/dates/selects rendered

[Tomato6966]

you could allow "markdown" as that's markdown :)

I thought like

settings.showNewLines = "show it" | "render it" -> show it will do: \n -> render it will actually do what the newline should do --> render it (however, there should be a small indicator like: ↲ so that you know it's a newline from the translation value, and not from the frontend cause the text is too long (which does a newline ones the text reaches the border automatically as it should)

so:

This is an Example.\nhere is the 2nd line

or

This is an Example.↲ here is the 2nd line

and for the emoji -> if you can render it in the dom then you can also export it via json -> the input json also has the EMOJIS within the values

Also I'd like to mention, that I had struggles setting the docker image up Cause it didn't recognise the config.yaml file path (Ubuntu 20.04) -> I set it up via .env -> Then I didn't understand how to do authentication.enabled --> with registrations-allowed cause it never shows sign up unless you send the users a link (that you should mention somewhere..)

[JanCizmar]

Hey! Thanks. That might make sense. We will talk about that on next meeting. To the docker issue and aut issues: Please open a discussion for that. It doesn't fit here. 🙏🏻

[stepan662]

By "show it", you mean show "\n" written (as a text)?

[cyyynthia]

• The emoji thing is perfectly valid and should not be a concern. It's just another way of representing a Unicode character which should be consumed the exact same way at the end of the day by a sane consumer (e.g.: sending emojis in this format to the Discord API does send the correct emoji in text chat). I don't think there is anything to do here.

• Newlines should indeed be reflected in the preview text. Even in Web context, there are plenty of cases where newlines do matter. I'm not a fan of showing the raw \n as this is a bit technical and translators may not understand what this means. Showing it with an explicit icon (or Unicode char) such as ↲ seems ideal. I don't think there need to be an exception for this, always displaying them doesn't bring any drawback I can think of right now.

you could allow "markdown" as that's markdown :)

Markdown support is tracked by #1298

[Tomato6966]

As cyynthia says, it's correct. However it would be nice, if the exported way could contain the "proper" showing of an emoji. as if i re-import the json file let's say after I added more features, it will be that way..

Then the translators will be even more confused as you say

[cyyynthia]

On import that should indeed be handled, you're right. I glossed over this possibility as you mentioned export and thought you meant it should be encoded the "correct" way in the JSON export specifically. I stand on my position that this is the job of a consumer to properly display this representation, and should be fixed in the webapp. ~~I guess the Tolgee UI is not a sane consumer then hehe~~

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.