git: 3853bc7660 - main - documentation: fix WARN after hugo setings change

The branch main has been updated by vladlen:

URL: https://cgit.FreeBSD.org/doc/commit/?id=3853bc7660d6f7feef77658c9b07f7d73e2327ce

commit 3853bc7660d6f7feef77658c9b07f7d73e2327ce
Author:     Vladlen Popolitov <[email protected]>
AuthorDate: 2026-07-02 12:38:09 +0000
Commit:     Vladlen Popolitov <[email protected]>
CommitDate: 2026-07-02 12:38:09 +0000

    documentation: fix WARN after hugo setings change
    
    Reviewed by: carlavilla, ziaee
    Approved by: carlavilla
    Differential Revision: https://reviews.freebsd.org/D57999
---
 .../books/developers-handbook/secure/_index.adoc   |   6 +-
 .../books/handbook/advanced-networking/_index.adoc |  26 +-
 .../content/en/books/dev-model/_index.adoc         |  56 ++--
 .../books/developers-handbook/secure/_index.adoc   |   4 +-
 .../books/handbook/advanced-networking/_index.adoc |  14 +-
 .../content/en/books/handbook/wayland/_index.adoc  |   4 +-
 .../books/porters-handbook/makefiles/_index.adoc   |  16 +-
 .../books/porters-handbook/pkg-files/_index.adoc   |   4 +-
 .../porters-handbook/quick-porting/_index.adoc     |   4 +-
 .../en/books/porters-handbook/testing/_index.adoc  |   4 +-
 .../books/handbook/advanced-networking/_index.adoc |   8 +-
 .../books/handbook/advanced-networking/_index.adoc |  22 +-
 .../content/ru/books/dev-model/_index.adoc         |  88 +++----
 .../books/developers-handbook/secure/_index.adoc   |  18 +-
 .../books/handbook/advanced-networking/_index.adoc |   8 +-
 .../content/ru/books/handbook/wayland/_index.adoc  |   4 +-
 .../content/ru/books/handbook/x11/_index.adoc      |  46 ++--
 .../books/porters-handbook/makefiles/_index.adoc   | 282 ++++++++++-----------
 .../books/porters-handbook/pkg-files/_index.adoc   |   4 +-
 .../porters-handbook/quick-porting/_index.adoc     |   4 +-
 .../ru/books/porters-handbook/testing/_index.adoc  |   4 +-
 .../books/developers-handbook/secure/_index.adoc   |   4 +-
 .../books/porters-handbook/makefiles/_index.adoc   |  24 +-
 .../books/porters-handbook/pkg-files/_index.adoc   |   4 +-
 .../porters-handbook/quick-porting/_index.adoc     |   6 +-
 25 files changed, 332 insertions(+), 332 deletions(-)

diff --git a/documentation/content/de/books/developers-handbook/secure/_index.adoc b/documentation/content/de/books/developers-handbook/secure/_index.adoc
index 6e71f358cd..ecf2f6e7ca 100644
--- a/documentation/content/de/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/de/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
 ---
 title: Kapitel 3. Sicheres Programmieren
-authors: 
+authors:
   - author: Murray Stokely
 prev: books/developers-handbook/tools
 next: books/developers-handbook/l10n
@@ -139,13 +139,13 @@ return 0;
 
 Betrachten wir nun, wie das Speicherabbild dieses Prozesses aussehen würde, wenn wir 160 Leerzeichen in unser kleines Programm eingeben, bevor wir Enter drücken.
 
-[XXX figure here!]
+[ XXX figure here! ]
 
 Offensichtlich kann man durch böswilligere Eingaben bereits kompilierten Programmtext ausführen (wie z.B. exec(/bin/sh)).
 
 === Puffer-Überläufe vermeiden
 
-Die direkteste Lösung, um Stack-Überläufe zu vermeiden, ist immer grössenbegrenzten Speicher und String-Copy-Funktionen zu verwenden. `strncpy` und `strncat` sind Teil der C-Standardbibliothek.  Diese Funktionen akzeptieren einen Längen-Parameter. Dieser Wert sollte nicht größer sein als die Länge des Zielpuffers. Die Funktionen kopieren dann bis zu `length` Bytes von der Quelle zum Ziel. Allerdings gibt es einige Probleme. Keine der Funktionen garantiert, dass die Zeichenkette NUL-terminiert ist, wenn die Größe  des Eingabepuffers so groß ist wie das Ziel. Außerdem wird der Parameter length zwischen strncpy und strncat inkonsistent definiert, weshalb Programmierer leicht bezüglich der korrekten Verwendung durcheinander kommen können. Weiterhin gibt es einen spürbaren Leist
 ungsverlust im Vergleich zu `strcpy`, wenn eine kurze Zeichenkette in einen großen Puffer kopiert wird. Denn `strncpy` fült den Puffer bis zur angegebenen Länge mit NUL auf. 
+Die direkteste Lösung, um Stack-Überläufe zu vermeiden, ist immer grössenbegrenzten Speicher und String-Copy-Funktionen zu verwenden. `strncpy` und `strncat` sind Teil der C-Standardbibliothek.  Diese Funktionen akzeptieren einen Längen-Parameter. Dieser Wert sollte nicht größer sein als die Länge des Zielpuffers. Die Funktionen kopieren dann bis zu `length` Bytes von der Quelle zum Ziel. Allerdings gibt es einige Probleme. Keine der Funktionen garantiert, dass die Zeichenkette NUL-terminiert ist, wenn die Größe  des Eingabepuffers so groß ist wie das Ziel. Außerdem wird der Parameter length zwischen strncpy und strncat inkonsistent definiert, weshalb Programmierer leicht bezüglich der korrekten Verwendung durcheinander kommen können. Weiterhin gibt es einen spürbaren Leist
 ungsverlust im Vergleich zu `strcpy`, wenn eine kurze Zeichenkette in einen großen Puffer kopiert wird. Denn `strncpy` fült den Puffer bis zur angegebenen Länge mit NUL auf.
 
 In OpenBSD wurde eine weitere Möglichkeit zum  kopieren von Speicherbereichen implementiert, die dieses Problem umgeht. Die Funktionen `strlcpy` und `strlcat` garantieren, dass das Ziel immer NUL-terminiert wird, wenn das Argument length ungleich null ist. Für weitere Informationen über diese Funktionen lesen Sie bitte crossref:bibliography[OpenBSD,6]. Die OpenBSD-Funktionen `strlcpy` und `strlcat` sind seit Version 3.3 auch in FreeBSD verfügbar.
 
diff --git a/documentation/content/de/books/handbook/advanced-networking/_index.adoc b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
index cca12a36b6..246c7942ad 100644
--- a/documentation/content/de/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
@@ -306,7 +306,7 @@ Häufig soll ein Computer an ein vorhandenes Drahtlosnetzwerk angeschlossen werd
 % ifconfig | grep -B3 -i wireless
 ....
 
-+ 
++
 In FreeBSD 11 und neueren Versionen verwenden Sie stattdessen diesen Befehl:
 +
 
@@ -315,9 +315,9 @@ In FreeBSD 11 und neueren Versionen verwenden Sie stattdessen diesen Befehl:
 % sysctl net.wlan.devices
 ....
 
-+ 
++
 Wenn der drahtlose Adapter nicht aufgeführt wird, könnte ein zusätzliches Kernelmodul erforderlich sein. Es besteht jedoch auch die Möglichkeit, dass der Adapter von FreeBSD nicht unterstützt wird.
-+ 
++
 Dieses Beispiel verwendet einen drahtlosen Atheros-Adapter `ath0`.
 . Fügen Sie in [.filename]#/etc/wpa_supplicant.conf# einen Eintrag für das Netzwerk hinzu. Wenn die Datei nicht existiert, müssen Sie diese erstellen. Ersetzen Sie _myssid_ und _psk_ durch die SSID und den PSK. Diese Informationen werden vom Netzwerkadministrator zur Verfügung gestellt.
 +
@@ -890,7 +890,7 @@ network={
 
 <.> Das Feld `ca_cert` gibt den Pfad zum CA-Zertifikat an. Diese Datei wird zur Verifizierung des Server-Zertifikats benötigt.
 
-<.> Dieses Feld enthält die Parameter für die erste Phase der Authentifizierung, den TLS-Tunnel. Je nachdem, welcher Authentifizierungsserver benutzt wird, kann 
+<.> Dieses Feld enthält die Parameter für die erste Phase der Authentifizierung, den TLS-Tunnel. Je nachdem, welcher Authentifizierungsserver benutzt wird, kann
 ein spezifisches Label für die Authentifizierung verwendet werden. Meistens lautet das Label "client EAP encryption", dass durch `peaplabel=0` gesetzt wird. Weitere Informationen finden Sie in man:wpa_supplicant.conf[5].
 
 <.> Das innerhalb des verschlüsselten TLS-Tunnels verwendete Authentifizierungsprotokoll. In unserem Beispiel handelt es sich dabei um `auth=MSCHAPV2`.
@@ -1256,7 +1256,7 @@ Dieser Abschnitt beschreibt eine Reihe von Maßnahmen zur Behebung von alltägli
 
 * Wird der Access Point bei der Suche nicht gefunden, überprüfen Sie, dass die Konfiguration des drahtlosen Geräts nicht die Anzahl der Kanäle beschränkt.
 * Wenn sich das Gerät nicht mit dem Access Point verbinden kann, überprüfen Sie, ob die Konfiguration der Station auch der des Access Points entspricht. Dazu gehören auch die Authentifzierungsmethode und die Sicherheitsprotokolle. Halten Sie die Konfiguration so einfach wie möglich. Wenn Sie ein Sicherheitsprotokoll wie WPA oder WEP verwenden, können Sie testweise den Access Point auf _offene Authentifizierung_ und _keine Sicherheit_ einstellen.
-+ 
++
 Für die Fehlersuche steht man:wpa_supplicant[8] zur Verfügung. Starten Sie das Programm manuell mit der Option `-dd` und durchsuchen Sie anschließend die Systemprotokolle nach eventuellen Fehlermeldungen.
 * Sobald sich das Gerät mit dem Access Point verbinden kann, prüfen Sie die Netzwerkkonfiguration mit einfachen Werkzeugen wie man:ping[8].
 * Zusätzlich gibt es auch zahlreiche Low-Level-Debugging-Werkzeuge. Die Ausgabe von Debugging-Informationen des 802.11 Protocol Support Layers lassen sich mit dem Programm man:wlandebug[8] aktivieren. Um beispielsweise während der Suche nach Access Points und des Aufbaus von 802.11-Verbindungen (Handshake) auftretende Systemmeldungen auf die Konsole auszugeben, verwenden Sie den folgenden Befehl:
@@ -1266,7 +1266,7 @@ Für die Fehlersuche steht man:wpa_supplicant[8] zur Verfügung. Starten Sie das
 # wlandebug -i wlan0 +scan+auth+debug+assoc
   net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
 ....
-+ 
++
 Der 802.11-Layer liefert umfangreiche Statistiken, die mit dem Werkzeug `wlanstats`, das sich in [.filename]#/usr/src/tools/tools/net80211# befindet, abgerufen werden können. Diese Statistiken sollten alle Fehler identifizieren, die im 802.11-Layer auftreten. Beachten Sie aber, dass einige Fehler bereits im darunterliegenden Gerätetreiber auftreten und daher in diesen Statistiken nicht enthalten sind. Wie Sie Probleme des Gerätetreibers identifizieren, entnehmen Sie bitte der Dokumentation des Gerätetreibers.
 
 Wenn die oben genannten Informationen nicht helfen das Problem zu klären, erstellen Sie einen Problembericht, der die Ausgabe der weiter oben genannten Werkzeuge beinhaltet.
@@ -2103,14 +2103,14 @@ Für Laptop-Benutzer ist es normalerweise wünschenswert, "wireless" als sekund
 Dies wird erreicht, indem die MAC-Adresse der Ethernet-Schnittstelle mit der MAC Adresse der drahtlosen Schnittstelle überschrieben wird.
 
 [NOTE]
-****
+====
 Theoretisch kann die Ethernet- oder die drahtlose MAC-Adresse so geändert werden, dass sie mit der jeweils anderen Adresse übereinstimmt. Bei einigen drahtlosen Schnittstellen fehlt jedoch die Unterstützung für das Überschreiben der MAC-Adresse. Daher wird empfohlen, die MAC-Adresse der Ethernet-Schnittstelle für diesen Zweck zu überschreiben.
-****
+====
 
 [NOTE]
-****
+====
 Wenn der Treiber für die drahtlose Schnittstelle nicht im `GENERIC`-Kernel oder in einem angepassten Kernel enthalten ist, kann unter FreeBSD {rel121-current} mit `_driver__load="YES"` die entsprechende [.filename]#.ko#-Datei in [.filename]#/boot/loader.conf# geladen werden. Dann muss das System neu gestartet werden. Ein anderer, besserer Weg ist es, den Treiber über [.filename]#/etc/rc.conf# zu laden, indem Sie ihn zu `kld_list` (siehe man:rc.conf[5]) hinzufügen und dann das System neu starten. Dies ist notwendig, da sonst der Treiber zum Zeitpunkt der Konfiguration der man:lagg[4]-Schnittstelle noch nicht geladen ist.
-****
+====
 
 In diesem Beispiel ist die Ethernet-Schnittstelle _re0_ der Master und die drahtlose Schnittstelle _wlan0_ der Failover. Die Schnittstelle _wlan0_ wurde aus der physischen Schnittstelle _ath0_ erstellt, und die Ethernet-Schnittstelle wird mit der MAC-Adresse der drahtlosen Schnittstelle konfiguriert. Im ersten Schritt wird die MAC-Adresse der drahtlosen Schnittstelle ermittelt:
 
@@ -2231,7 +2231,7 @@ Die in diesem Abschnitt dargestellten Schritte konfigurieren die in FreeBSD enth
 ....
 nfs_server_enable="YES"
 ....
-+ 
++
 Exportieren Sie das Root-Verzeichnis über NFS, indem Sie folgende Zeile in [.filename]#/etc/exports# hinzufügen:
 +
 [.programlisting]
@@ -2289,7 +2289,7 @@ Received 264951 bytes in 0.1 seconds
 # Device                                         Mountpoint    FSType   Options  Dump Pass$
 	    myhost.example.com:/b/tftpboot/FreeBSD/install       /         nfs      ro        0    0
 ....
-+ 
++
 Ersetzen Sie _myhost.example.com_ durch den Hostnamen oder die IP-Adresse des NFS-Servers. In diesem Beispiel wird das Root-Dateisystem schreibgeschützt eingehangen, um ein potenzielles Löschen des Inhalts durch die NFS-Clients zu verhindern.
 . Setzen Sie das root-Passwort in der PXE-Umgebung für Client-Maschinen, die über PXE starten:
 +
@@ -2384,7 +2384,7 @@ image::pxe-nfs.png[]
 tftp> get FreeBSD/install/boot/pxeboot
 Received 264951 bytes in 0.1 seconds
 ....
-+ 
++
 Weitere Informationen finden Sie in man:tftpd[8] und man:tftp[1]. Die `BUGS`-Sektionen dieser Seiten dokumentieren einige Einschränkungen von TFTP.
 . Achten Sie darauf, dass Sie das Root-Dateisystem über NFS einhängen können. Auch hier können Sie Ihre Einstellungen aus [.filename]#/usr/local/etc/dhcpd.conf# wie folgt testen:
 +
diff --git a/documentation/content/en/books/dev-model/_index.adoc b/documentation/content/en/books/dev-model/_index.adoc
index 1f56b814b0..04bbac61e1 100644
--- a/documentation/content/en/books/dev-model/_index.adoc
+++ b/documentation/content/en/books/dev-model/_index.adoc
@@ -79,7 +79,7 @@ Up until now, the FreeBSD project has released a number of described techniques
 However, a project model summarising how the project is structured is needed because of the increasing amount of project members.
 footnote:[This goes hand-in-hand with Brooks' law that adding another person to a late project will make it later since it will increase the communication needs . A project model is a tool to reduce the communication needs.]
 This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works.
-It is based on [crossref:dev-model[thesis, Saers,2003]].
+It is based on [ crossref:dev-model[thesis, Saers 2003] ].
 
 I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document.
 
@@ -102,23 +102,23 @@ I would like to thank the following people for taking the time to explain things
 [[overview]]
 == Overview
 A project model is a means to reduce the communications overhead in a project.
-As shown by [crossref:dev-model[brooks, Brooks, 1995]], increasing the number of project participants increases the communication in the project exponentially.
+As shown by [ crossref:dev-model[brooks, Brooks  1995] ], increasing the number of project participants increases the communication in the project exponentially.
 FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly.
 This project model will serve to reduce this overhead by providing an up-to-date description of the project.
 
 During the Core elections in 2002, Mark Murray stated "I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs."
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]].
+[ crossref:dev-model[bsd-election2002, FreeBSD 2002B] ].
 This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination.
 It is meant as a description of the project, with an overview of how the different processes are executed.
 It is an introduction to how the FreeBSD project works.
 
 The FreeBSD project model will be described as of July 1st, 2004.
-It is based on the Niels Jørgensen's paper [crossref:dev-model[jorgensen2001, Jørgensen, 2001]], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
+It is based on the Niels Jørgensen's paper [ crossref:dev-model[jorgensen2001, Jørgensen 2001] ], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
 
 After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes.
 Finally it will outline major sub-projects of the FreeBSD project.
 
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project.
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD  2002A] ] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project.
 The vision is "To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability."
 The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project
 
@@ -129,7 +129,7 @@ The architectural guidelines help determine whether a problem that someone wants
 === Activity
 
 An "activity" is an element of work performed during the course of a project
-[crossref:dev-model[ref-pmbok, PMI, 2000]].
+[ crossref:dev-model[ref-pmbok, PMI  2000] ].
 It has an output and leads towards an outcome.
 Such an output can either be an input to another activity or a part of the process' delivery.
 
@@ -155,7 +155,7 @@ An "outcome" is the final output of the process.
 This is synonymous with deliverable, that is defined as "any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project.
 Often used more narrowly in reference to an external deliverable, which is a
 deliverable that is subject to approval by the project sponsor or customer" by
-[crossref:dev-model[ref-pmbok, PMI, 2000]].
+[ crossref:dev-model[ref-pmbok, PMI 2000] ].
 Examples of outcomes are a piece of software, a decision made or a report written.
 
 [[ref-freebsd]]
@@ -308,7 +308,7 @@ Jørgenssen's model for change integration
 |===
 
 The "development release" is the FreeBSD-CURRENT ("-CURRENT") branch and the
-"production release" is the FreeBSD-STABLE branch ("-STABLE") [crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+"production release" is the FreeBSD-STABLE branch ("-STABLE") [ crossref:dev-model[jorgensen2001, Jørgensen  2001] ].
 
 This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems.
 After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community.
@@ -400,7 +400,7 @@ image::branches.png[Refer to table below for a screen-reader friendly version.]
 |===
 
 The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE.
-In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
+In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [ crossref:dev-model[freebsd-releng, FreeBSD 2002E] ]
 
 A "major release" is always made from the -CURRENT branch.
 However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising.
@@ -460,14 +460,14 @@ These hat descriptions are not such a formalisation, rather a summary of the rol
 
 A Contributor contributes to the FreeBSD project either as a developer, as an
 author, by sending problem reports, or in other ways contributing to the
-progress of the project. A contributor has no special privileges in the FreeBSD project. [crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
+progress of the project. A contributor has no special privileges in the FreeBSD project. [ crossref:dev-model[freebsd-contributors, FreeBSD 2002F] ]
 
 [[role-committer]]
 ==== Committer
 
 A person who has the required privileges to add their code or documentation to the repository.
 A committer has made a commit within the past 12 months.
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] An active committer is a committer who has made an average of one commit per month during that time.
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD 2000A] ] An active committer is a committer who has made an average of one commit per month during that time.
 
 It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify.
 However, when wanting to make modifications to parts a committer has not been involved in before, they should read the logs to see what has happened in this area before, and also read the MAINTAINERS file to see if the maintainer of this part has any special requests on how changes in the code should be made.
@@ -707,7 +707,7 @@ By tradition, this is by adding their name to the committers list.
 
 Recall that a committer is considered to be someone who has committed code during the past 12 months.
 However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked.
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD 2002H] ]
 There are, however, no automatic procedures for doing this.
 For reactions concerning commit privileges not triggered by time, see
 crossref:dev-model[process-reactions,section 1.5.8].
@@ -729,9 +729,9 @@ Roles in this process:
 . crossref:dev-model[role-maintainer, Maintainership]
 . crossref:dev-model[role-mentor, Mentor]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
-[crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD 2000A] ]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD 2002H] ]
+[ crossref:dev-model[freebsd-new-account, FreeBSD 2002I] ]
 
 [[committing]]
 === Committing code
@@ -782,8 +782,8 @@ Hats included in this process are:
 . crossref:dev-model[role-vendor, Vendor]
 . crossref:dev-model[role-reviewer, Reviewers]
 
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
+[ crossref:dev-model[freebsd-committer, FreeBSD 2001] ]
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ]
 
 [[process-core-election]]
 === Core election
@@ -824,16 +824,16 @@ Hats in core elections are:
 * crossref:dev-model[role-committer, Committer]
 * crossref:dev-model[role-election-manager, Election Manager]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
-[crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD 2000A] ]
+[ crossref:dev-model[bsd-election2002, FreeBSD 2002B] ]
+[ crossref:dev-model[freebsd-election, FreeBSD 2002G] ]
 
 [[new-features]]
 === Development of new features
 
 Within the project there are sub-projects that are working on new features.
 These projects are generally done by one person
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ].
 Every project is free to organise development as it sees fit.
 However, when the project is merged to the -CURRENT branch it must follow the project guidelines.
 When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch.
@@ -870,7 +870,7 @@ footnote:[sendmail and named are examples of code that has been merged from othe
 The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered.
 
 The main bulk of work that is put into the FreeBSD project is maintenance.
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]] has made a figure showing the life cycle of changes.
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ] has made a figure showing the life cycle of changes.
 
 Jørgenssen's model for change integration
 
@@ -952,13 +952,13 @@ The roles included in this process are:
 . crossref:dev-model[role-maintainer, Maintainership]
 . crossref:dev-model[role-bugbuster, Bugbuster]
 
-[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
-[crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
+[ crossref:dev-model[freebsd-handle-pr, FreeBSD  2002C] ].
+[ crossref:dev-model[freebsd-send-pr, FreeBSD  2002D] ].
 
 [[process-reactions]]
 === Reacting to misbehavior
 
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]] has a number of rules that committers should follow.
+[ crossref:dev-model[freebsd-committer, FreeBSD  2001] ] has a number of rules that committers should follow.
 However, it happens that these rules are broken.
 The following rules exist in order to be able to react to misbehavior.
 They specify what actions will result in how long a suspension of the committer's commit privileges.
@@ -968,7 +968,7 @@ They specify what actions will result in how long a suspension of the committer'
 * Commit wars - 5 days to all participating parties
 * Impolite or inappropriate behavior - 5 days
 
-[crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
+[ crossref:dev-model[ref-freebsd-trenches, Lehey  2002] ]
 
 For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the "core" mailing list.
 Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges.
@@ -1074,7 +1074,7 @@ The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limit
 It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community.
 General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public.
 The majority of all the communication in the project goes through these 85 lists
-[crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Appendix C].
+[ crossref:dev-model[ref-bsd-handbook, FreeBSD  2003A], Appendix C].
 
 [[tool-pgp]]
 === Pretty Good Privacy
@@ -1142,7 +1142,7 @@ Only documentation errors are corrected in the security branches.
 
 Like the ports sub-project, the Documentation project can appoint documentation
 committers without FreeBSD Core's approval.
-[crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
+[ crossref:dev-model[freebsd-doceng-charter, FreeBSD 2003B] ].
 
 The Documentation project has extref:{fdp-primer}[a primer].
 This is used both to introduce new project members to the standard tools and syntaxes and to act as a reference when working on the project.
diff --git a/documentation/content/en/books/developers-handbook/secure/_index.adoc b/documentation/content/en/books/developers-handbook/secure/_index.adoc
index fab08ad88b..bbcf991dec 100644
--- a/documentation/content/en/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
 ---
 title: Chapter 3. Secure Programming
-authors: 
+authors:
   - author: Murray Stokely
 prev: books/developers-handbook/tools
 next: books/developers-handbook/l10n
@@ -157,7 +157,7 @@ int main() {
 
 Let us examine what the memory image of this process would look like if we were to input 160 spaces into our little program before hitting return.
 
-[XXX figure here!]
+[ XXX figure here! ]
 
 Obviously more malicious input can be devised to execute actual compiled instructions (such as exec(/bin/sh)).
 
diff --git a/documentation/content/en/books/handbook/advanced-networking/_index.adoc b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
index 182c424c57..b2862f063d 100644
--- a/documentation/content/en/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
@@ -136,7 +136,7 @@ These hosts are identified using the Routing Information Protocol (RIP), which c
 
 subnet::
 FreeBSD will automatically add subnet routes for the local subnet.
-In this example, `10.20.30.255` is the broadcast address for the subnet `10.20.30` and `example.com` is the domain name associated with that subnet. 
+In this example, `10.20.30.255` is the broadcast address for the subnet `10.20.30` and `example.com` is the domain name associated with that subnet.
 The designation `link#1` refers to the first Ethernet card in the machine.
 +
 Local network hosts and local subnets have their routes automatically configured by a daemon called man:routed[8].
@@ -1109,7 +1109,7 @@ This node is normally connected to the downstream Bluetooth HCI node and upstrea
 The default name for the L2CAP node is "devicel2cap".
 For more details refer to man:ng_l2cap[4].
 
-A useful command is man:l2ping[8], which can be used to ping other devices. 
+A useful command is man:l2ping[8], which can be used to ping other devices.
 Some Bluetooth implementations might not return all of the data sent to them, so `0 bytes` in the following example is normal.
 
 [source,shell]
@@ -1164,7 +1164,7 @@ For the purposes of RFCOMM, a complete communication path involves two applicati
 RFCOMM is intended to cover applications that make use of the serial ports of the devices in which they reside.
 The communication segment is a direct connect Bluetooth link from one device to another.
 
-RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case. 
+RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case.
 RFCOMM can support other configurations, such as modules that communicate via Bluetooth wireless technology on one side and provide a wired interface on the other side.
 
 In FreeBSD, RFCOMM is implemented at the Bluetooth sockets layer.
@@ -1857,18 +1857,18 @@ With man:lagg[4], it is possible to configure a failover which prefers the Ether
 This is achieved by overriding the Ethernet interface's MAC address with that of the wireless interface.
 
 [NOTE]
-****
+====
 In theory, either the Ethernet or wireless MAC address can be changed to match the other.
 However, some popular wireless interfaces lack support for overriding the MAC address.
 We therefore recommend overriding the Ethernet MAC address for this purpose.
-****
+====
 
 [NOTE]
-****
+====
 If the driver for the wireless interface is not loaded in the `GENERIC` or custom kernel, and the computer is running FreeBSD {rel121-current}, load the corresponding [.filename]#.ko# in [.filename]#/boot/loader.conf# by adding `*driver_load="YES"*` to that file and rebooting.
 Another, better way is to load the driver in [.filename]#/etc/rc.conf# by adding it to `kld_list` (see man:rc.conf[5] for details) in that file and rebooting.
 This is needed because otherwise the driver is not loaded yet at the time the man:lagg[4] interface is set up.
-****
+====
 
 In this example, the Ethernet interface, _re0_, is the master and the wireless interface, _wlan0_, is the failover.
 The _wlan0_ interface was created from the _ath0_ physical wireless interface, and the Ethernet interface will be configured with the MAC address of the wireless interface.
diff --git a/documentation/content/en/books/handbook/wayland/_index.adoc b/documentation/content/en/books/handbook/wayland/_index.adoc
index e05df2004d..d9e78df6b1 100644
--- a/documentation/content/en/books/handbook/wayland/_index.adoc
+++ b/documentation/content/en/books/handbook/wayland/_index.adoc
@@ -641,7 +641,7 @@ To install `ly`, issue the following command:
 
 There will be some configuration hints presented, the import steps are to add the following lines to [.filename]#/etc/gettytab#:
 
-[programlisting]
+[.programlisting]
 ....
 Ly:\
   :lo=/usr/local/bin/ly:\
@@ -650,7 +650,7 @@ Ly:\
 
 And then modify the ttyv1 line in [.filename]#/etc/ttys# to match the following line:
 
-[programlisting]
+[.programlisting]
 ....
 ttyv1 "/usr/libexec/getty Ly" xterm onifexists secure
 ....
diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
index 8415ede9a4..a9ffe801b9 100644
--- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
@@ -134,10 +134,10 @@ See below on how to use  man:pkg-version[8] to compare versions.
 <.> `1.2` is before `1.2p1` as `2p1`, think "2, patch level 1" which is a version after any `2.X` but before `3`.
 
 [NOTE]
-****
+=====
 In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level",
 but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately.
-****
+=====
 
 ====
 
@@ -1546,9 +1546,9 @@ GH_TAGNAME=	2678d2b6a8ca3cf80cb4dbc8da557a2998e1b5c0
 It will automatically have `MASTER_SITES` set to `GH` and `WRKSRC` to `${WRKDIR}/pkg-6dbb17b`.
 
 [TIP]
-****
+====
 `20260626` is the date of the commit referenced in `GH_TAGNAME`, not the date the [.filename]#Makefile# is edited, or the date the commit is made.
-****
+====
 
 ====
 
@@ -1645,7 +1645,7 @@ See crossref:makefiles[makefile-versions-ex-pkg-version, this section for how to
 ....
 
 [NOTE]
-****
+=====
 If the requested commit is the same as a tag, a shorter description is shown by default.
 The longer version is equivalent:
 
@@ -1658,7 +1658,7 @@ v0.7.3
 v0.7.3-0-gc66c71d
 ....
 
-****
+=====
 
 ====
 
@@ -1851,11 +1851,11 @@ It can also be found on GitHub.
 Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`.
 
 [NOTE]
-****
+=====
 While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information.
 For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`.
 Both can be used interchangeably, but when a tag is available, use it.
-****
+=====
 
 Now that all the required information has been gathered, the [.filename]#Makefile# can be written (only GitHub-related lines are shown):
 
diff --git a/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc b/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
index d4530108c9..ae5432e2ac 100644
--- a/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
@@ -218,10 +218,10 @@ When a port is upgraded, the message displayed can be even more tailored to the
 ....
 
 [IMPORTANT]
-****
+=====
 When displaying a message on upgrade, it is important to limit when it is being shown to the user.
 Most of the time it is by using `maximum_version` to limit its usage to upgrades from before a certain version when something specific needs to be done.
-****
+=====
 
 ====
 
diff --git a/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc b/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
index 9c25913c38..a3d7547179 100644
--- a/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
@@ -284,9 +284,9 @@ Patch generated with `git format-patch` will include author identity and email a
 easier for developers to apply (with `git am`) and give proper credit.
 
 [IMPORTANT]
-****
+====
 To make it easier for committers to apply the patch on their working copy of the ports tree, please generate the [.filename]#.diff# from the base of your ports tree.
-****
+====
 
 ====
 
diff --git a/documentation/content/en/books/porters-handbook/testing/_index.adoc b/documentation/content/en/books/porters-handbook/testing/_index.adoc
index c854994f6f..9cf5786d20 100644
--- a/documentation/content/en/books/porters-handbook/testing/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/testing/_index.adoc
@@ -603,9 +603,9 @@ To build a set with a non default Perl version, for example, `5.20`, using a set
 DEFAULT_VERSIONS+= perl=5.20
 ....
 [NOTE]
-****
+=====
 Note the use of `+=` so that if the variable is already set in the default [.filename]#make.conf# its content will not be overwritten.
-****
+=====
 
 ====
 
diff --git a/documentation/content/es/books/handbook/advanced-networking/_index.adoc b/documentation/content/es/books/handbook/advanced-networking/_index.adoc
index 31a0325853..cc9fbc7116 100644
--- a/documentation/content/es/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/es/books/handbook/advanced-networking/_index.adoc
@@ -1575,14 +1575,14 @@ Para los usuarios de portátiles, normalmente es deseable configurar el disposit
 Esto se consigue sobrescribiendo la dirección MAC del interfaz Ethernet con el de la interfaz inalámbrica.
 
 [NOTE]
-****
+====
 En teoría, cualquiera de las dos direcciones MAC (Ethernet o inalámbrica) se puede cambiar para igualarse a la otra. Sin embargo, algunas interfaces inalámbricas populares carecen del soporte para sobrescribir la dirección MAX. Por lo tanto para este propósito recomendamos sobrescribir la dirección MAC Ethernet.
-****
+====
 
 [NOTE]
-****
+====
 Si el controlador para el interfaz inalámbrico no está cargado en el kernel `GENERIC` o en el personalizado, y el ordenador está ejecutando FreeBSD{rel121-current}, carga el [.filename]#.ko# correspondiente en [.filename]#/boot/loader.conf# añadiendo `*driver_load="YES"*` a ese fichero y después reiniciando. Otra forma mejor es cargar el driver en [.filename]#/etc/rc.conf# añadiéndolo a `kld_list` (consulta man:rc.conf[5] para los detalles) en ese fichero y reiniciando. Esto es necesario porque de otra forma el controlador no está todavía cargado en el momento en el que se configura el interfaz man:lagg[4].
-****
+====
 
 En este ejemplo, el interfaz Ethernet, _re0_, es el maestro y el interfaz inalámbrico, _wlan0_, es el recambio. El interfaz _wlan0_ ha sido creado a partir del interfaz inalámbrico físico _ath0_, y el interfaz Ethernet se configurará con la dirección MAC del interfaz inalámbrico. Primero, levanta el interfaz inalámbrico (reemplaza _FR_ con tu código de país de dos letras), pero no establezcas una dirección IP. Reemplaza _wlan0_ con el nombre del interfaz inalámbrico del sistema:
 
diff --git a/documentation/content/pl/books/handbook/advanced-networking/_index.adoc b/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
index dc8b9310d8..b8c0f6d09c 100644
--- a/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
@@ -304,16 +304,16 @@ Connecting a computer to an existing wireless network is a very common situation
 ....
 % ifconfig | grep -B3 -i wireless
 ....
-+ 
++
 On FreeBSD 11 or higher, use this command instead:
 +
 [source,shell]
 ....
 % sysctl net.wlan.devices
 ....
-+ 
++
 If a wireless adapter is not listed, an additional kernel module might be required, or it might be a model not supported by FreeBSD.
-+ 
++
 This example shows the Atheros `ath0` wireless adapter.
 . Add an entry for this network to [.filename]#/etc/wpa_supplicant.conf#. If the file does not exist, create it. Replace _myssid_ and _mypsk_ with the SSID and PSK provided by the network administrator.
 +
@@ -1226,7 +1226,7 @@ This section describes a number of steps to help troubleshoot common wireless ne
 
 * If the access point is not listed when scanning, check that the configuration has not limited the wireless device to a limited set of channels.
 * If the device cannot associate with an access point, verify that the configuration matches the settings on the access point. This includes the authentication scheme and any security protocols. Simplify the configuration as much as possible. If using a security protocol such as WPA or WEP, configure the access point for open authentication and no security to see if traffic will pass.
-+ 
++
 Debugging support is provided by man:wpa_supplicant[8]. Try running this utility manually with `-dd` and look at the system logs.
 * Once the system can associate with the access point, diagnose the network configuration using tools like man:ping[8].
 * There are many lower-level debugging tools. Debugging messages can be enabled in the 802.11 protocol support layer using man:wlandebug[8]. For example, to enable console messages related to scanning for access points and the 802.11 protocol handshakes required to arrange communication:
@@ -1236,7 +1236,7 @@ Debugging support is provided by man:wpa_supplicant[8]. Try running this utility
 # wlandebug -i wlan0 +scan+auth+debug+assoc
   net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
 ....
-+ 
++
 Many useful statistics are maintained by the 802.11 layer and `wlanstats`, found in [.filename]#/usr/src/tools/tools/net80211#, will dump this information. These statistics should display all errors identified by the 802.11 layer. However, some errors are identified in the device drivers that lie below the 802.11 layer so they may not show up. To diagnose device-specific problems, refer to the drivers' documentation.
 
 If the above information does not help to clarify the problem, submit a problem report and include output from the above tools.
@@ -2075,14 +2075,14 @@ For laptop users, it is usually desirable to configure the wireless device as a
 This is achieved by overriding the Ethernet interface's MAC address with that of the wireless interface.
 
 [NOTE]
-****
+====
 In theory, either the Ethernet or wireless MAC address can be changed to match the other. However, some popular wireless interfaces lack support for overriding the MAC address. We therefore recommend overriding the Ethernet MAC address for this purpose.
-****
+====
 
 [NOTE]
-****
+====
 If the driver for the wireless interface is not loaded in the `GENERIC` or custom kernel, and the computer is running FreeBSD {rel121-current}, load the corresponding [.filename]#.ko# in [.filename]#/boot/loader.conf# by adding `*driver_load="YES"*` to that file and rebooting. Another, better way is to load the driver in [.filename]#/etc/rc.conf# by adding it to `kld_list` (see man:rc.conf[5] for details) in that file and rebooting. This is needed because otherwise the driver is not loaded yet at the time the man:lagg[4] interface is set up.
-****
+====
 
 In this example, the Ethernet interface, _re0_, is the master and the wireless interface, _wlan0_, is the failover. The _wlan0_ interface was created from the _ath0_ physical wireless interface, and the Ethernet interface will be configured with the MAC address of the wireless interface. First, determine the MAC address of the wireless interface:
 
@@ -2261,7 +2261,7 @@ Received 264951 bytes in 0.1 seconds
 # Device                                         Mountpoint    FSType   Options  Dump Pass
 myhost.example.com:/b/tftpboot/FreeBSD/install       /         nfs      ro        0    0
 ....
-+ 
++
 Replace _myhost.example.com_ with the hostname or IP address of the NFS server. In this example, the root file system is mounted read-only in order to prevent NFS clients from potentially deleting the contents of the root file system.
 . Set the root password in the PXE environment for client machines which are PXE booting :
 +
@@ -2368,7 +2368,7 @@ image::pxe-nfs.png[]
 tftp> get FreeBSD/install/boot/pxeboot
 Received 264951 bytes in 0.1 seconds
 ....
-+ 
++
 The `BUGS` sections in man:tftpd[8] and man:tftp[1] document some limitations with TFTP.
 . Make sure that the root file system can be mounted via NFS. To test this example configuration:
 +
diff --git a/documentation/content/ru/books/dev-model/_index.adoc b/documentation/content/ru/books/dev-model/_index.adoc
index 280822e773..15c8f1669d 100644
--- a/documentation/content/ru/books/dev-model/_index.adoc
+++ b/documentation/content/ru/books/dev-model/_index.adoc
@@ -1,6 +1,6 @@
 ---
 authors:
-  - 
+  -
     author: 'Niklas Saers'
 bookOrder: 45
 copyright: '2002-2005 Niklas Saers'
@@ -76,7 +76,7 @@ toc::[]
 [.abstract-title]
 Предисловие
 
-До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент 
 для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётÑ
Ñ в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [crossref:dev-model[thesis, Saers,2003]].
+До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент 
 для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётÑ
Ñ в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [ crossref:dev-model[thesis, Saers,2003]].
 
 Я хотел бы поблагодарить следующих людей за то, что они нашли время объяснить мне непонятные моменты и проверить документ.
 
@@ -98,15 +98,15 @@ toc::[]
 
 [[overview]]
 == Обзор
-Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [crossref:dev-model[brooks, Brooks, 1995]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за 
 счёт предоставления актуального описания проекта.
+Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [ crossref:dev-model[brooks, Brooks, 1995]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за
  счёт предоставления актуального описания проекта.
 
-Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор тÐ
 ¾Ð³Ð¾, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
+Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [ crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор т
 ого, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
 
-Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
+Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
 
 После определения используемых терминов в этом документе будет описана организационная структура (включая описания ролей и линии коммуникации), рассмотрена модель методологии, а после представления инструментов, используемых для контроля процессов, будут описаны определённые процессы. В заключение будут представлены основные подпроекты проекта FreeBSD.
 
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в раÐ
 ¼ÐºÐ°Ñ… проекта
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в ра
 мках проекта
 
 [[definitions]]
 == Определения
@@ -114,7 +114,7 @@ toc::[]
 [[ref-activity]]
 === Активность
 
-"Активность" — это элемент работы, выполняемый в ходе проекта [crossref:dev-model[ref-pmbok, PMI, 2000]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
+"Активность" — это элемент работы, выполняемый в ходе проекта [ crossref:dev-model[ref-pmbok, PMI, 2000]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
 
 [[def-process]]
 === Процесс
@@ -129,7 +129,7 @@ toc::[]
 [[ref-outcome]]
 === Результат
 
-«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [crossref:dev-model[ref-pmbok
 , PMI, 2000]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
+«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [ crossref:dev-model[ref-pmbo
 k, PMI, 2000]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
 
 [[ref-freebsd]]
 === FreeBSD
@@ -179,27 +179,27 @@ toc::[]
 | Количество людей
 
 |Основные участники
-| 
+|
 |9
 
 |Коммиттеры
 |Базовый
 |164
 
-| 
+|
 |Docs
 |45
 
-| 
+|
 |Порты
 |166
 
-| 
+|
 |Total
 |374
 
 |Участники
-| 
+|
 |~3000
 |===
 
@@ -234,7 +234,7 @@ toc::[]
 
 |программирование
 |рецензирование
-| 
+|
 
 |рецензирование
 |предварительная проверка перед коммитом
@@ -253,11 +253,11 @@ toc::[]
 |программирование
 
 |релиз для производства
-| 
+|
 |программирование
 |===
 
-"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
 
 Это модель для одного изменения, которая показывает, что после написания кода разработчики ищут рецензирование сообщества и пытаются интегрировать это изменение в свои собственные системы. После интеграции изменения в версию разработки, называемую FreeBSD-CURRENT, оно тестируется многими пользователями и разработчиками сообщества FreeBSD. После достаточного тестирования оно объединяется с производственной версией, называемой FreeBSD-STABLE. ЕÑ
 Ð»Ð¸ каждая стадия не завершена успешно, разработчику необходимо вернуться, внести изменения в код и пер
езапустить процесс. Интеграция изменения в -CURRENT или -STABLE называется выполнением коммита.
 
@@ -295,11 +295,11 @@ image::branches.png["Обратитесь к таблице ниже для уд
 | Следующие минорные выпуски
 
 |...
-| 
-| 
+|
+|
 
 |3.0 Current (ветка разработки)
-| 
+|
 |Ветки Releng 3: выпуски с 3.0 Release по 3.5 Release, ведущие к выпуску 3.5.1 Release и последующей ветке 3 Stable
 
 |4.0 Current (ветка разработки)
@@ -312,15 +312,15 @@ image::branches.png["Обратитесь к таблице ниже для уд
 
 |6.0 Current (ветка разработки)
 |Релиз 5.3
-| 
+|
 
 |...
-| 
-| 
+|
+|
 
 |===
 
-Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
+Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [ crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
 
 «Основной выпуск» всегда создаётся из ветки -CURRENT. Однако ветка -CURRENT не обязательно должна разветвляться в этот момент, а может сосредоточиться на стабилизации. Примером этого является то, что после 3.0-RELEASE, 3.1-RELEASE также был продолжением ветки -CURRENT, и -CURRENT не стал настоящей веткой разработки до тех пор, пока не был выпущен этот релиз и не была создана ветка 3-STABLE. Когда -CURRENT снова становится веткой разработки, за ним может следовать тольÐ
 ºÐ¾ основной выпуск. Ожидается, что ветка 5-STABLE будет отделена от 5.0-CURRENT примерно на момент выпуска 5.3-RELEASE.
 Только после отделения 5-STABLE ветка разработки получит название 6.0-CURRENT.
 
@@ -357,12 +357,12 @@ image::freebsd-code-model.png["Обратитесь к параграфам ни
 [[role-contributor]]
 ==== Участник (контрибьютор)
 
-Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
+Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [ crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
 
 [[role-committer]]
 ==== Коммиттер
 
-Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
+Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
 
 Стоит отметить, что нет технических препятствий, которые могли бы помешать кому-либо, получившему права на коммиты в основном или подпроекте, делать коммиты в частях исходного кода проекта, для которых у коммиттера нет явного разрешения на изменение. Однако, при желании внести изменения в части, с которыми коммиттер ранее не работал, следует изучить логи, чтобы понять, что происходило в этой области ранее, а также прочитать файл MAINTAINE
 RS, чтобы узнать, есть ли у сопровождающего этой части какие-либо особые требования к внесению изменений
 в код.
 
@@ -553,7 +553,7 @@ image::proc-add-committer.png["Обратитесь к абзацу ниже д
 Когда участник отправляет фрагмент кода, принимающий коммиттер может предложить предоставить этому участнику права на коммит. Если он рекомендует это основной команде (Core Team), команда проводит голосование по этой рекомендации. Если голосование завершается в пользу предложения, новому коммиттеру назначается наставник, и новый коммиттер должен отправить свои данные администраторам для создания учётной записи. После этого новый ко
 ммиттер готов сделать свой первый коммит. По традиции, это делается путём добавления своего имени в спи
сок коммиттеров.
 
 Напомним, что коммиттером считается тот, кто за последние 12 месяцев внёс изменения в код. Однако право на коммиты может быть отозвано только после 18 месяцев неактивности.
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
 Однако не существует автоматических процедур для этого. Для действий, связанных с привилегиями коммитов, не вызванных временем, см. crossref:dev-model[process-reactions,раздел 1.5.8].
 
 .Процесс: удаление коммиттера
@@ -571,9 +571,9 @@ image::proc-rm-committer.png["Обратитесь к абзацу ниже дл
 . crossref:dev-model[role-maintainer, Сопровождение]
 . crossref:dev-model[role-mentor, Наставник (Mentor)]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
-[crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
 
 [[committing]]
 === Коммит кода
@@ -605,8 +605,8 @@ image::proc-contrib.png["Обратитесь к абзацам выше и ни
 . crossref:dev-model[role-vendor, Поставщик]
 . crossref:dev-model[role-reviewer, Рецензенты]
 
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
+[ crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
+[ crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
 
 [[process-core-election]]
 === Выборы основной команды (Core Team)
@@ -638,14 +638,14 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 * crossref:dev-model[role-committer, Коммиттер]
 * crossref:dev-model[role-election-manager, Менеджер выборов]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
-[crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[ crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
+[ crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
 
 [[new-features]]
 === Разработка новых функций
 
-В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [crossref:dev-model[jorgensen2001, Йоргенсен, 2001]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяе
 тся с ветвью -STABLE.
+В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [ crossref:dev-model[jorgensen2001, Йоргенсен, 2001]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяÐ
 µÑ‚ся с ветвью -STABLE.
 
 Требования проекта определяются пожеланиями разработчиков, запросами сообщества в виде прямых обращений по почте, отчётов о проблемах (Problem Reports), коммерческим финансированием разработки функциональности или вкладами научного сообщества. Пожелания, которые входят в зону ответственности разработчика, передаются этому разработчику, который расставляет приоритеты между запросом и своими собственными пожеланиями. Распространенны
 й способ организации этого процесса — ведение списка задач (TODO-list), поддерживаемого проектом. Задачи, нÐ
µ входящие в чью-либо зону ответственности, собираются в списках TODO, пока кто-нибудь не возьмет на себя ответственность за их выполнение. Все запросы, их распределение и отслеживание обрабатываются с помощью инструмента crossref:dev-model[tool-bugzilla, Bugzilla].
 
@@ -660,7 +660,7 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 
 Для проекта полезно, чтобы за каждую область исходного кода отвечал хотя бы один человек, который хорошо её знает. Некоторые части кода имеют назначенных сопровождающих. Другие имеют фактических сопровождающих, а некоторые части системы не имеют сопровождающих. Сопровождающий обычно является участником подпроекта, который написал и интегрировал код, или тем, кто портировал его с платформы, для которой он был написан. footnote:[sendmail и nam
 ed — примеры кода, который был объединён с других платформ.] Задача сопровождающего — убедиться, что код
 синхронизирован с проектом, из которого он получен, если это сторонний код, а также применять патчи, предоставленные сообществом, или исправлять обнаруженные проблемы.
 
-Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [crossref:dev-model[jorgensen2001, Jørgensen, 2001]] предоставляет схему, показывающую жизненный цикл изменений.
+Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]] предоставляет схему, показывающую жизненный цикл изменений.
 
 Модель Йоргенссена для интеграции изменений
 
@@ -673,7 +673,7 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 
 |программирование
 |рецензирование
-| 
+|
 
 |рецензирование
 |предварительная проверка перед коммитом
@@ -692,7 +692,7 @@ image::proc-elections.png["Обратитесь к абзацу ниже для
 |программирование
 
 |релиз для производства
-| 
+|
 |программирование
 |===
 
@@ -720,20 +720,20 @@ image::proc-pr.png["Обратитесь к абзацу ниже для вер
 . crossref:dev-model[role-maintainer, Сопровождение]
 . crossref:dev-model[role-bugbuster, Исправитель ошибок (Bugbuster)]
 
-[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
-[crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
+[ crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
+[ crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
 
 [[process-reactions]]
 === Реагирование на неправильное поведение
 
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
+[ crossref:dev-model[freebsd-committer, FreeBSD, 2001]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
 
 * Совершение коммитов во время заморозки кода без одобрения команды Release Engineering — 2 дня
 * Коммит изменений в ветку безопасности без одобрения - 2 дня
 * Войны коммитов — 5 дней для всех участвующих сторон
 * Невежливое или неподобающее поведение — 5 дней
 
-[crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
+[ crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
 
 Для эффективности приостановок любой член основной команды (Core Team) может применить приостановку до обсуждения на почтовой рассылке "core". Повторные нарушители могут, при 2/3 голосов от основной команды, получить более строгие наказания, включая постоянное лишение прав на коммиты. (Однако последнее всегда рассматривается как крайняя мера из-за присущей ему склонности вызывать споры.) Все приостановки публикуются в почтовой рассылке "de
 velopers", доступной только коммиттерам.
 
@@ -799,7 +799,7 @@ Bugzilla — это база данных для сопровождения, с
 [[model-mailman]]
 === Mailman
 
-Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены
  для разработки определённых областей интересов, а закрытые рассылки используются для внутренней комм
уникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Приложение C].
+Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены
  для разработки определённых областей интересов, а закрытые рассылки используются для внутренней комм
уникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [ crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Приложение C].
 
 [[tool-pgp]]
 === Pretty Good Privacy
@@ -847,7 +847,7 @@ crossref:dev-model[fig-ports,image::portsstatus.svg] показывает кол
 
 Как и проект FreeBSD, документация разделена на те же ветви. Это сделано для того, чтобы для каждой версии всегда была обновлённая документация. В ветвях безопасности исправляются только ошибки в документации.
 
-Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
+Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [ crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
 
 Проект документации включает в себя extref:{fdp-primer}[вводное руководство]. Оно используется как для ознакомления новых участников проекта со стандартными инструментами и синтаксисом, так и в качестве справочника при работе над проектом.
 
diff --git a/documentation/content/ru/books/developers-handbook/secure/_index.adoc b/documentation/content/ru/books/developers-handbook/secure/_index.adoc
index db6613bffa..2ad0f536ae 100644
--- a/documentation/content/ru/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/ru/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
 ---
 authors:
-  - 
+  -
     author: 'Murray Stokely'
 description: 'Безопасное программирование в FreeBSD'
 next: books/developers-handbook/l10n
@@ -78,37 +78,37 @@ endif::[]
 |===
 
 |`strcpy`(char *dest, const char *src)
-| 
+|
 
 Может переполнить буфер назначения
 
*** 1231 LINES SKIPPED ***