@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!

AsciiDoctor, as a good software project don't have everything documented and sometimes you need to dig into their code hehe.

@pauamma I appreciate your concern on accessibility but please don't pollute all the discussions with accessibility. I have mentioned in the earlier Review that the table will be fixed with the info you have provided and with the alt text which will go into another review. This review is not about fixing the texts or the tables either.

That's awesome !

Hi Rodrigo,

Abandon as having a chat with a friend mentions Proximos is correct however I will create a new revision with the proper punctuation as ?? is wrong should be ¿? to be politically correct.

Ok

In D3363#109726, @chris_bsdjunk.com wrote:

In D3363#74436, @wblock wrote:

If this is done, it should be done in the external stylesheet, not hard-coded in the HTML. However, there is only a single paragraph in that text on the main page, so it does not seem necessary to help the user identify paragraph breaks.

Our other text uses increased line spacing between paragraphs. Indents might be better there, I have not considered it before.

So this isn't a werthy change?

Reply to comment

Jenkins link gives a 404 Error?

In D3363#74436, @wblock wrote:

If this is done, it should be done in the external stylesheet, not hard-coded in the HTML. However, there is only a single paragraph in that text on the main page, so it does not seem necessary to help the user identify paragraph breaks.

Our other text uses increased line spacing between paragraphs. Indents might be better there, I have not considered it before.