Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve line-breaks in display of comments (string descriptions) #11131

Open
henry-torproject opened this issue Mar 4, 2024 · 3 comments
Open
Labels
enhancement Adding or requesting a new feature.

Comments

@henry-torproject
Copy link
Contributor

Describe the problem

Go to https://hosted.weblate.org/translate/tor/tor-browser/tb-tor-browser-ftl/ar/?checksum=34a0a0c74cb9093c and look at the "Source string description". It is currently shown as:

User provided bridge dialog. Error shown when the "bridge pass" server does not respond. Here "bridge pass" is a noun: a bridge pass gives users access to some tor bridges. So "pass" is referring to something that gives permission or access. Similar to "token", "permit" or "voucher", but for permanent use rather than one-time.

The original Fluent Group comment is "User provide bridge dialog." and the original Fluent Message comment purposefully includes line breaks after each sentence since they are separate comments. But all the line-breaks are collapsed into whitespace, making each point stand out less.

Note that in Fluent, Group and Resource comments are concatenated with the individual string comments. If the author of the original Fluent file did not include a full-stop at the end of their Group comment, it would blend in. E.g.

## Search Feature

# will be used when user has an account
search-with-account = some string

# will be used when the user does not have an account
search-no-account = other string

in Weblate the search-no-account would be shown with the comment:

Search Feature will be used when the user does not have an account

which has different meaning.

Describe the solution you would like

In your web-console change the CSS to include white-space: pre-line, and it will change to:

User provided bridge dialog.
Error shown when the "bridge pass" server does not respond.
Here "bridge pass" is a noun: a bridge pass gives users access to some tor bridges.
So "pass" is referring to something that gives permission or access. Similar to "token", "permit" or "voucher", but for permanent use rather than one-time.

And in my example, it would instead be shown as

Search Feature
will be used when the user does not have an account

I can understand that for some use-cases a single comment may be spread across multiple lines for other reasons, but in my own use case I would like each line to be more distinguished. So this could be an option set per component.

Describe alternatives you have considered

I have been making sure that all of my comment lines end in a full-stop, so there is at least some separation.

Screenshots

No response

Additional context

No response

@nijel
Copy link
Member

nijel commented Mar 5, 2024

I am not convinced that white-space: pre-line is the way to go as some discarding of newlines is desired as these are typically present just for line-wrapping purposes. As screen width varies, we would rather not preserve line breaks present in the code.

The root cause here is merging two scopes of comments. I don't recall such a concept being used in any other format. Maybe supporting some syntax in the field to allow structuring it?

@henry-torproject
Copy link
Contributor Author

Maybe supporting some syntax in the field to allow structuring it?

Could a double line break \n\n work?

The root cause here is merging two scopes of comments.

There are other cases. The convention in Fluent is put put variables on new lines: example.

But even pontoon doesn't seem to preserve them.

@nijel
Copy link
Member

nijel commented Mar 7, 2024

Yes, sometimes line breaks make sense to be preserved, sometimes not (example from the same project).

Current behavior seems to work well for most of the use-cases, so let's not change it for the most typical case (single \n). Treating \n\n as a line break (or rather a paragraph separator) might be a way to go.

@nijel nijel added the enhancement Adding or requesting a new feature. label Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding or requesting a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants