Thanks! That seems much more reasonable than what I was thinking.

I'd drop all the changes before 12.x. The CS driver was around for a long time. I forget which release we dropped it in, but changing things older than 12 is likely not a good idea.

Missed a spot, sorry.

Thank you!

I'm sorry, I won't do it again. I thought it would be a hilarious way to ping.

Please don't accept your own revisions. That's implied ;-)

@bcr Do you have any objections on behalf of core@? As I am removing some stale members I was also looking forward for core's approval.

Sorry for the wrong revision.

Committed at https://cgit.freebsd.org/ports/commit/?id=5125ee97dbeac1c76e145c38cdde9ea47eec47ed with wrong Revision. :'(

LGTM.

Sort dependencies

Go ahead, but in the future, with the new design, I’ll translate the website :)

If at some point we deem it necessary, we can translate the website.

I had the notion that @fernape was from Italy. I hope that you will work on it and fix those. But it's too much work to maintain a translation of the website specially keeping it upto date. I believe you will maybe do it one time to sync it with the latest en but will you be able to maintain it regularly? In FreeBSD world there is always something happening. :)

I would like to start with this at some point, but I didn't have time yet.
I'm considering this a small nudge so I can start the task, but I will not oppose if you think we should delete it for now.

In D41646#949742, @bofh wrote:

@fernape As @carlavilla has solved the issue do you have any objection removing the hu translations for the website?

@fernape As @carlavilla has solved the issue do you have any objection removing the hu translations for the website?

Remove this file too please https://cgit.freebsd.org/doc/tree/website/config/_default/languages.hu.toml

When running the building, why is HU also reported?

Committed.

Thanks for taking care of this :)

@salvadore Somewhere mentioned about some exceptions with Inc. and e.g. which will contain . but not apparently at the end of line. This patch handles this exception.

Thanks, I have not yet tested diff 120428.

I have checked out the repository to a version before the commit and tested. I confirm that it now works as expected, showing lines 89, 90, 91 and 110 all at once, thanks @bofh.

In D39560#901295, @salvadore wrote:

Since I remember I had spotted those multisentences list items through vale, I have tested it again. I confirm what @grahamperrin reports: even with level: warning it only reports line 110. I add that the same happens with level: suggestion.

However, if line 110 is fixed, then vale reports line 89. When line 89 is fixed, it reports line 91 and so on. So, for some reason, vale applies the rule only once.

Handle semantic line breaking in lists.

There is another scope called list which might be helpful for bullet points.

Modify warning level to suggestion

Toying with scopes:

In D39560#901295, @salvadore wrote:

… if line 110 is fixed, then vale reports line 89. When line 89 is fixed, it reports line 91 and so on. So, for some reason, vale applies the rule only once.

Since I remember I had spotted those multisentences list items through vale, I have tested it again. I confirm what @grahamperrin reports: even with level: warning it only reports line 110. I add that the same happens with level: suggestion.

In D39560#901277, @salvadore wrote:

Have you tried switching from level: error to level: warning as suggested in the above comments?

In D39560#901276, @grahamperrin wrote:

In D39560#901262, @salvadore wrote:

… fixing in https://reviews.freebsd.org/D39567#change-bq5lJMuUrbA0.

Thanks. Running vale here (with diff 120268), I see that it catches line 100, but not the list items.

In D39560#901262, @salvadore wrote:

… fixing in https://reviews.freebsd.org/D39567#change-bq5lJMuUrbA0.

In D39560#901131, @grahamperrin wrote:

In D39560#900625, @salvadore wrote:

I have tested it successfully on this quarter status reports. …

Can you recall, were there any multi-sentence list items (bullet points)?

Thinking back a few months … my perceptions of ambiguity might have differed from other people's perceptions.

In D39560#900625, @salvadore wrote:

I have tested it successfully on this quarter status reports. …

In D39560#900668, @salvadore wrote:

In D39560#900629, @salvadore wrote:

Maybe also remove max: 1.

No, sorry: this must stay. I thought it refered to how many times the rule was allowed to fail before stopping checking the file, but I realized that it counts the number of sentences instead.

In D39560#900625, @salvadore wrote:

I have tested it successfully on this quarter status reports.

Two suggestions for improvements:

• I had two false positives due to abbreviations (Inc. and e.g.);

Ah yes this is fixable. I will need to add another rule.

In D39560#900629, @salvadore wrote:

Maybe also remove max: 1.

Maybe also remove max: 1.

I have tested it successfully on this quarter status reports.

In D36982#859054, @zlei wrote:

One more advantage to use (dynamically create) svg is it will be easy to support 'dark mode'.

@bofh Are you still working on it ?

One more advantage to use (dynamically create) svg is it will be easy to support 'dark mode'.

About the use of "you".

Updates according to feedback from @ceri

In D37381#849798, @ceri wrote:

Reword. This would have benefitted from much wider review, from inception to commit. Please allow more time for these wide-ranging changes, and perhaps invite feedback on the doc@ mailing list.

Reword. This would have benefitted from much wider review, from inception to commit. Please allow more time for these wide-ranging changes, and perhaps invite feedback on the doc@ mailing list.

Oops. Looks like my commit missed the review.

Looks good!

Looks good, ready to commit!