Skip to content

Semantic Comments Proposal: Title Line #138

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

Open
zbraniecki opened this issue Jun 1, 2018 · 1 comment
Open

Semantic Comments Proposal: Title Line #138

zbraniecki opened this issue Jun 1, 2018 · 1 comment
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 semantic comments

Comments

@zbraniecki
Copy link
Collaborator

zbraniecki commented Jun 1, 2018

This is part of the series of proposals spanning out of the meta #16.

Title Line

The title line of the comment is meant to provide two main features:

1) ability to use group comments as visual indicators in lists

The first goal is primarily driven by the Pontoon use case, where we display a list of strings in a resource on the left. With this feature on, we could additionally cluster the groups of messages with semantically valid title:

2) denote the first line of a group comment as a title for faster scannning

When scanning FTL resource files, group comments can be used to help identify the section of the file we want to work with.

Unfortunately, without the title line, the comment requires to be read to understand its role:

Details

My proposal is to identify the title line of any comment as fitting into one of two conditions:

  1. Being the only non-empty line of the comment
  2. Being the first non-empty line of the comment with a blank line right below it.

That means that the following two are titles lines:

## Privacy Section - Site Data
## Privacy Section - Site Data
##
## This sections will contain several messages
## that should be translated by a lawyer if possible.

but this is not:

## Privacy section describes the settings the user
## may want to customize in order to protect their privacy.
@flodolo
Copy link
Contributor

flodolo commented Jun 1, 2018

A couple of thoughts on point 1:

  • We don't know what Pontoon is going to look like with Translate.Next. But we know a lot of localizers coming from Pootle found that list not useful, and taking a lot of space, and I tend to agree.
  • That list is now what localizers look at most of the time. They look at "work to do", which means strings to translate or review, i.e. a much smaller subset of strings. In that context, having separators is not that useful.

On one side I think we should not just think of Pontoon, on the other I have a hard time thinking about localizers with Pontoon out of the picture :)

I'm not against the proposal, but I have a hard time finding how this could improve the experience for localizers.

@stasm stasm added the FUTURE Ideas and requests to consider after Fluent 1.0 label Jun 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 semantic comments
Projects
None yet
Development

No branches or pull requests

3 participants