Improve English grammar in user-interface text. - #2075

Thank you for the suggestions. I welcome the comments and appreciate the discovery of errors.

I have attempted to apply as many of the comments as possible at the present time.

For purposes of housekeeping, I have marked all conversations as resolved. Please be free to comment further if you find unfixed problems.

Currently, three questions remain, which I feel are structural rather than grammatical, but may be dependencies for this request.

The structural questions are as follows:

1. Following the earlier discussion, the user might be confused about why language detection is unavailable, if use of the spell checker is required and if no explanation is given for this requirement. Also, if support is only available for Mac users, then I wonder whether the application should simply hide (rather than disable) the option, depending on an OS check.

2. My best understanding of the handling of trailing line breaks is that the configurability reduces to two separate binary options, which have orthogonal effects, and also apply to mutually exclusive conditions. The two possible values for each of two options is of course four total options, as in the drop-down menu.

   The two options are the following, as I understand:

   1. If the file ends in no line breaks, then do nothing, or append one line break.
   2. If the file ends in multiple line breaks, then do nothing, or truncate all line breaks in excess of one.

   Because the questions are separate, phrasing the answers to both in a single sentence is difficult. I feel inclined to suggest that the design be changed to incorporate two separate checkboxes, one for each question.

3. The text relating to emphasis needs to be consistent in two respects. First, the same language must be used in both the pop-up tool tips and the menu. Second, the language must commit either to the semantic feature of emphasis or to the physical feature of letter style.

   Currently, neither constraint is followed. However, as three out of four instances of this text is the semantic case, I chose to adopt that convention for the revisions.

   I identify the following three options:

   1. Italic and bold: Simple and familiar, but not strictly correct, as many Markdown enthusiasts will notice. (In some cases users may even alter editing display with custom styles, once the feature becomes supported.)
   2. Emphasis and strong emphasis: Cumbersome, but accurate. Used in some applications, but fewer than above. Alongside icons that show the letters I and B in corresponding letter style, unlikely to cause misunderstanding.
   3. Emphasized and strong: As above, but slightly more compact.

Following the earlier discussion, the user might be confused about why language detection is unavailable, if use of the spell checker is required and if no explanation is given for this requirement. Also, if support is only available for Mac users, then I wonder whether the application should simply hide (rather than disable) the option, depending on an OS check.

The option will be only shown when macOS spell checker is used (#2138). In addition we need to notify the user about the compatible issue with underlined words like "This feature is only enabled if spelling mistakes are underlined." because there are no backend checks. The spell check is most likely disabled but I cannot test this because I don't own macOS.

My best understanding of the handling of trailing line breaks is that the configurability reduces to two separate binary options, which have orthogonal effects, and also apply to mutually exclusive conditions. The two possible values for each of two options is of course four total options, as in the drop-down menu.

That's wrong because all cases are valid options depending on the users preferences. The options are:

1. Trim trailing newlines: Remove all ending newlines before saving.
2. Insert final newline: Remove all ending newline and ensure a single one before saving.
3. Analyse each file and apply either 1, 2 or 4.
4. Allow unlimited newlines and don't change anything before saving.

The text relating to emphasis needs to be consistent in two respects. First, the same language must be used in both the pop-up tool tips and the menu. Second, the language must commit either to the semantic feature of emphasis or to the physical feature of letter style.

I still prefer bold and italic because it's most commonly used. Further opinions @Jocs @Rexogamer ?

My best understanding of the handling of trailing line breaks is that the configurability reduces to two separate binary options, which have orthogonal effects, and also apply to mutually exclusive conditions. The two possible values for each of two options is of course four total options, as in the drop-down menu.

That's wrong because all cases are valid options depending on the users preferences. The options are:

1. Trim trailing newlines: Remove all ending newlines before saving.
2. Insert final newline: Remove all ending newline and ensure a single one before saving.
3. Analyse each file and apply either 1, 2 or 4.
4. Allow unlimited newlines and don't change anything before saving.

I’m presuming this means that 3 is used alongside one of the other options (eg 3 and 1)?

The text relating to emphasis needs to be consistent in two respects. First, the same language must be used in both the pop-up tool tips and the menu. Second, the language must commit either to the semantic feature of emphasis or to the physical feature of letter style.

I still prefer bold and italic because it's most commonly used. Further opinions @Jocs @Rexogamer ?

I agree, bold/italic would be better as it just seems more commonly understood to me.

I identify the following three options:
Italic and bold: Simple and familiar, but not strictly correct, as many Markdown enthusiasts will notice. (In some cases users may even alter editing display with custom styles, once the feature becomes supported.)
Emphasis and strong emphasis: Cumbersome, but accurate. Used in some applications, but fewer than above. Alongside icons that show the letters I and B in corresponding letter style, unlikely to cause misunderstanding.
Emphasized and strong: As above, but slightly more compact.

I also prefer Italic and bold, Because it corresponds to the shortcut key. Cmd + B and Cmd + I

@brainchild0 @Rexogamer Thank you, great work!

My understanding is still lacking for handing of trailing newline characters, but I believe it is at least improving.

Every file at any time falls into one of three categories: a) It has no trailing newline characters, b) it has exactly one, or c) it has more than one.

I believe we all agree so far.

Now I am understanding that option (1) causes the resulting file to have no trailing newline characters, regardless of how many it had before. Option (2) causes it to have one newline character, regardless of how many it had before. Option (4) has no effect.

But you are describing option (3) as "analyzing" the file. Can we please be explicit? If the three possibilities are that the initial number of newline characters is a) 0, b) 1, or c) N > 1, then what is the result for option (3) in each case?

But you are describing option (3) as "analyzing" the file. Can we please be explicit?

The third option checks the end of the document while loading the file and set it to a (1), b (2) or c (4). After the document is edited by the user, the text is formatted by a, b or c. That means the third option is never used by the editor to format the document but is used by the document decoding process while loading a file to detect and apply one of the other options. If you set 1, 2 or 4 in settings we don't care about the existing format of the file and just overwrite the ending.

So if the file has three trailing line breaks when it is opened, under option (3), and the editing buffer has no trailing line breaks when the file is saved, then the application appends the three lines breaks to the saved file? And if the buffer has ten trailing line breaks when the file is saved, then the application truncates seven line breaks?

I still lack a clear understanding of the behavior and meaning, but we can use whatever text you want.

I accepted the comments and revisions. These changes appear in commits up to and including 9f44ea3.

I also made a few more find adjustments in b39b662.

I am mostly comfortable with everything except the language about the trailing new lines.

Two further possible revisions moving forward include using ellipsis (...) consistently following items that invoke a dialog box, and deciding whether to keep colon characters in the text for the GitHub fields.

See revised, previous comment. I will wait for feedback, and am currently planning nothing further until I receive it.

@fxha: I now understand. Thank you.

The rules are too complex to explain completely in summary, but to me, compared to the current language, a clearer form for option (3) is one similar to "Preserve style of original document."

(Also, for option (2) I prefer "Ensure exactly one trailing.")

(3) "Preserve style of original document."
Also, for option (2) I prefer "Ensure exactly one trailing."

@brainchild0 That's sounds great. Would you mind updating the string, so I can merge the PR.

@brainchild0 That's sounds great. Would you mind updating the string, so I can merge the PR.

@fxha Done!