tolgee
Enable string format specification on the key and project level
Currently our editor supports only ICU format and warns on when the translation syntax is not complaint to that. This is far from ideal, since users don't use only ICU messages, but they often use different format. Before we add support for HTML, I propose to add options to select format of the message on the key level and enable a project default.
-
Proposed formats
- [ ] ICU (FormatJS) (with ignore tag option checkbox?)
- [ ] None
-
Supported rendering checkboxes (so we will render this in the preview)
- [ ] HTML
- [ ] Markdown
This way we will can cover a lot of use cases before implementing actual All format support / visual editor.
@stepan662 @Martin005 @cyyynthia Please share your thoughts. Anyway, we should do something quickly. This is pretty common issue.
Unsure about rendering html, there is a non-negligible risk of opening up XSS vectors and there are too many cases to consider to do it properly imho.
Anyway, we should do something quickly. This is pretty common issue.
I think the only "urgent" thing is providing an escape hatch to disable syntax highlighting, so implementing the NONE translation format. Other things raised here already have tracking issues.
Hmm, also not sure if we can rendering html safe, but generally I agree. At least turning formatting off would be useful.
I would call the other format Other instead of None.
And what about rendering the ICU format (pretty-printing the plural/select/selectordinal cases)? This wouldn't be in the rendering checkboxes and would be instead turned on by default when selecting that the key is in the ICU format?
This issue is stale because it has been open for 30 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 30 days with no activity.
Don't worry, issues labeled tagged with enhancement or bug don't automatically go stale after 30 days.
Hey! Since All formats support is already released, I am closing this. Please reopen this if you still believe there is something missing for your use cases. Thanks!
Is support for HTML and Markdown already implemented in the Preview as well? that was the 2nd part of this issue.
We decided not to add WYSIWYG editor to Tolgee, since it would be confusing for the users. Rather we visualize HTML tags, as it is industry standard. Rendering HTML would generate more issues then it solves. The same pays for markdown. Although, we are not visualizing it. Markdown is basically visualizing itself, so IMHO it doesn't make much sense to add any markdown support.
@JanCizmar sure, you don't have to render it, but can you support it like tags or ICU format?
For example, we might have source English:
Hello, what is your **name**?
but then our French translators translate it like this, since you are supposed to add a space in between punctuation in formal French:
Comment vous ** appelez-vous ** ?
or maybe will omit or skip the * altogether because it doesn't make sense to them.
And this breaks the formatting and the text is no longer bold. Is there some cue in the UI that you as the translator broke the formatting? This can be achieved by supporting them as tags like you do with ICU, showing a rendered preview, or any number of other techniques.
Hmm, yeah. This might be a valid use case. We might add optional markdown wrapping checkbox, so it would visualize markdown too. The disadvantage here is that markdown is not that straightforward as HTML. It supports various options like tables, italic, lists etc, and we simply cannot support that all. It might be easier to simply explain this to the translators somehow, so they understand the markdown syntax and know how to use it. What do you think @stepan662