From b40c64f1075774f7232608df6636586009ab8ab3 Mon Sep 17 00:00:00 2001
From: Alban Auzeill <alban.auzeill@sonarsource.com>
Date: Tue, 30 May 2023 16:04:14 +0200
Subject: [PATCH] SONARJAVA-4499 Update rules metadata (#4392)

* SONARJAVA-4499 Update rules metadata, rename sections

* SONARJAVA-4499 Update rules metadata, deprecated rules

* SONARJAVA-4499 Update rules metadata, "See Also" sections

* SONARJAVA-4499 S2384 description updated to match the implementation

* SONARJAVA-4499 Fix S2755 rule description invalid section

* SONARJAVA-4499 Migrate S3981 rule description to the educational format
---
 .../org/sonar/l10n/java/rules/java/S100.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S101.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S103.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S104.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S105.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S106.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1065.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1066.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1067.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1068.html | 18 ++++++++-------
 .../org/sonar/l10n/java/rules/java/S107.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1075.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S108.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S109.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S110.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S1104.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1105.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1106.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1107.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1108.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1109.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1110.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1111.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1113.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1114.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1116.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1117.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1118.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1119.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S112.html  |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1120.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1121.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1123.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1124.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1125.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1126.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1128.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S113.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S1130.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1132.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1133.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1134.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1135.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S114.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1141.html |  1 +
 .../org/sonar/l10n/java/rules/java/S1142.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1143.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1144.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1147.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1149.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S115.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1150.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1151.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1153.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1155.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1157.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1158.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S116.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1160.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1161.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1162.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1163.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1165.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1166.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1168.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S117.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1170.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1171.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1172.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1174.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1175.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1176.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S118.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1181.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1182.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1185.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1186.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1188.html |  1 +
 .../org/sonar/l10n/java/rules/java/S119.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1190.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1191.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1192.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1193.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1194.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1195.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1197.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1199.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S120.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1200.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1201.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1206.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S121.html  |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1210.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1213.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1214.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1215.html |  1 +
 .../org/sonar/l10n/java/rules/java/S1217.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1219.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S122.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1220.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1221.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1223.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1226.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1228.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S124.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S1244.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S125.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S1258.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S126.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1264.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S127.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S128.html  |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1301.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1309.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S131.html  |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1310.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1312.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1314.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1315.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1317.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1319.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S134.html  |  3 ++-
 .../org/sonar/l10n/java/rules/java/S135.html  |  3 ++-
 .../org/sonar/l10n/java/rules/java/S138.html  |  1 +
 .../org/sonar/l10n/java/rules/java/S139.html  |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1444.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1448.html |  1 +
 .../org/sonar/l10n/java/rules/java/S1449.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1450.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1451.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1452.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1479.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1481.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1488.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1541.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1596.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1598.html |  1 +
 .../org/sonar/l10n/java/rules/java/S1602.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1604.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1607.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1610.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1611.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1612.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1640.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1641.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1643.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1656.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1659.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1694.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1695.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1696.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1698.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1699.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1700.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1710.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1711.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1751.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1764.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1774.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1820.html |  1 +
 .../org/sonar/l10n/java/rules/java/S1821.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1844.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1845.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1849.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1854.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1858.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1860.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1862.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1871.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1872.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1874.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1905.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1939.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1940.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1941.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1942.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1943.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S1948.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S1989.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S1994.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S1996.html |  1 +
 .../org/sonar/l10n/java/rules/java/S2039.html | 10 ++++-----
 .../org/sonar/l10n/java/rules/java/S2047.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2053.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2055.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2057.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S2059.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2060.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2061.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2062.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2063.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2065.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2066.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2093.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2094.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2095.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S2096.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2097.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2109.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2110.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2111.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2112.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2114.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2115.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2116.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2118.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2119.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S2121.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2122.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2123.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2127.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2129.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2130.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2131.html |  8 +++----
 .../org/sonar/l10n/java/rules/java/S2133.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2134.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2139.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2140.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2141.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2142.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2143.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2147.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2148.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2151.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2153.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2154.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2156.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2157.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2159.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2160.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2162.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2164.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S2165.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2166.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2167.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2168.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2175.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2176.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2177.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2178.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2183.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2184.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2185.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2186.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2187.html |  1 +
 .../org/sonar/l10n/java/rules/java/S2188.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2189.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2196.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2197.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2200.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2201.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S2203.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2204.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2208.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2209.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2211.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2221.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2222.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2225.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2226.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2229.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2230.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2232.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2234.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2235.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2236.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2250.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2251.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2252.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2253.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2254.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2259.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2260.html |  1 +
 .../org/sonar/l10n/java/rules/java/S2272.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2273.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2274.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2275.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2276.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2293.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2301.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2308.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2309.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2325.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2326.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2333.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2384.html | 13 ++++++-----
 .../org/sonar/l10n/java/rules/java/S2384.json |  2 +-
 .../org/sonar/l10n/java/rules/java/S2386.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2387.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2388.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2390.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2437.html |  1 +
 .../org/sonar/l10n/java/rules/java/S2438.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2440.html |  8 ++++---
 .../org/sonar/l10n/java/rules/java/S2441.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2442.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2444.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2445.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2446.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2447.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2479.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2583.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2589.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2629.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2637.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2638.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2639.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2647.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2658.html |  8 +++----
 .../org/sonar/l10n/java/rules/java/S2674.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2675.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2676.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2677.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2681.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2689.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2692.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2693.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2694.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2695.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2696.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S2698.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2699.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2701.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2718.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2737.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2755.html |  8 ++++---
 .../org/sonar/l10n/java/rules/java/S2757.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2761.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2786.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2789.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2864.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2885.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2886.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2924.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2925.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2959.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2970.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S2972.html |  1 +
 .../org/sonar/l10n/java/rules/java/S2973.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2974.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S2975.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S3008.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3010.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3011.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3012.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3014.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3020.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3030.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3032.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3034.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3038.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3039.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3042.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3046.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3047.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3052.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3064.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S3065.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3066.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3067.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3077.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3078.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3242.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3252.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3254.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3305.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3306.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3329.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3346.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3358.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3366.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3398.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3400.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3414.html |  1 +
 .../org/sonar/l10n/java/rules/java/S3415.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3416.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3436.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3437.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3457.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3516.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3518.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3546.html |  4 +++-
 .../org/sonar/l10n/java/rules/java/S3551.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3553.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3577.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3578.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3599.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3626.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3631.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3655.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3658.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3688.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3725.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3740.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3749.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3750.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3751.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3753.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3776.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3824.html | 10 +++++----
 .../org/sonar/l10n/java/rules/java/S3864.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3878.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3923.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3937.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3958.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S3959.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3972.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3973.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3981.html | 22 +++++++------------
 .../org/sonar/l10n/java/rules/java/S3984.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S3985.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S3986.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4011.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S4032.html |  1 +
 .../org/sonar/l10n/java/rules/java/S4034.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4042.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4065.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4087.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4143.html |  3 ++-
 .../org/sonar/l10n/java/rules/java/S4144.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4165.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4174.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4201.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4248.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4266.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4274.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4275.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4276.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4288.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4347.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4348.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4349.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4351.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4423.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4425.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4426.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4433.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4449.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4454.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4488.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4517.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4524.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4551.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4601.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4602.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4604.html |  8 +++----
 .../org/sonar/l10n/java/rules/java/S4605.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4635.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4682.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4684.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S4719.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4738.html |  1 +
 .../org/sonar/l10n/java/rules/java/S4830.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4838.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4925.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4926.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4929.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4968.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4970.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S4973.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S4977.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5128.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5164.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S5194.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5261.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5301.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5329.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5344.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5361.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5411.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5413.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5445.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5527.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5542.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5547.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5612.html |  1 +
 .../org/sonar/l10n/java/rules/java/S5659.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5663.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5664.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5665.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5669.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5679.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5738.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5776.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5777.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5778.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5779.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5783.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5785.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5786.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S5790.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5793.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5803.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5808.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S5810.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5826.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5831.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5833.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5838.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5841.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5842.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5843.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5845.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5846.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5850.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5853.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5854.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5855.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5856.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5857.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5860.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5863.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5866.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5867.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5868.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5869.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5876.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5917.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5958.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5960.html |  1 +
 .../org/sonar/l10n/java/rules/java/S5961.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5967.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5969.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5970.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5973.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5976.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5977.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5979.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S5993.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5994.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5996.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S5998.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6001.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6002.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6019.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6035.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6068.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6070.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6073.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6103.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6104.html |  8 ++++---
 .../org/sonar/l10n/java/rules/java/S6126.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6201.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6202.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6203.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6204.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6205.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6206.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6207.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6208.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6209.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6211.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S6212.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6213.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6216.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6217.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6218.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6219.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6241.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6242.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6243.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6244.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6246.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6262.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6288.html |  2 +-
 .../org/sonar/l10n/java/rules/java/S6293.html |  2 +-
 .../org/sonar/l10n/java/rules/java/S6301.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6326.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6331.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6353.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6355.html | 10 +++++----
 .../org/sonar/l10n/java/rules/java/S6373.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S6374.html |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S6376.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6377.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6395.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6396.html |  5 +++--
 .../org/sonar/l10n/java/rules/java/S6397.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6411.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6432.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S6437.html |  7 +++---
 .../org/sonar/l10n/java/rules/java/S818.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S864.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S881.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S888.html  |  9 ++++----
 .../org/sonar/l10n/java/rules/java/S899.html  |  7 +++---
 .../org/sonar/l10n/java/rules/java/S923.html  |  5 +++--
 sonarpedia.json                               |  2 +-
 588 files changed, 1944 insertions(+), 1364 deletions(-)

diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
index 89a2d0ebccc..1232317c668 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate efficiently. This rule checks that all method names match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With default provided regular expression <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 public int DoSomething(){...}
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int doSomething(){...}
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Overriding methods are excluded.</p>
 <pre>
 @Override
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
index 00ca7705061..f772827d774 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions allow teams to collaborate effectively. This rule allows to check that all class names match a provided regular
 expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With default provided regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 class my_class {...}
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {...}
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
index b50789b4526..10a9058c202 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
@@ -1,2 +1,3 @@
+<h2>Why is this an issue?</h2>
 <p>Having to scroll horizontally makes it harder to get a quick overview and understanding of any piece of code.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
index c94c1ce85d2..f6c0dbaa448 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A source file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to
 maintain. Above a specific threshold, it is strongly advised to refactor it into smaller pieces of code which focus on well defined tasks. Those
 smaller files will not only be easier to understand but also probably easier to test.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
index 116918878d6..2aab84fc839 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Developers should not need to configure the tab width of their text editors in order to be able to read source code.</p>
 <p>So the use of the tabulation character must be banned.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S106.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S106.html
index 946c75758b0..25adb814140 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S106.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S106.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When logging a message there are several important requirements which must be fulfilled:</p>
 <ul>
   <li> The user must be able to easily retrieve the logs </li>
@@ -7,15 +8,15 @@
 </ul>
 <p>If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That’s why defining and using a
 dedicated logger is highly recommended.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 System.out.println("My Message");  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 logger.log("My Message");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/">OWASP Top 10 2021 Category A9</a> - Security Logging and
   Monitoring Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1065.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1065.html
index d68eac34f79..3d75bdc73cb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1065.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1065.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>If a label is declared but not used in the program, it can be considered as dead code and should therefore be removed.</p>
 <p>This will improve maintainability as developers will not wonder what this label is used for.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void foo() {
   outer: //label is not used.
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void foo() {
   for(int i = 0; i&lt;10; i++) {
@@ -17,7 +18,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1066.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1066.html
index 9fb8b4e6d4e..66cbe52247b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1066.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1066.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Merging collapsible <code>if</code> statements increases the code’s readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (file != null) {
   if (file.isFile() || file.isDirectory()) {
@@ -7,7 +8,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (file != null &amp;&amp; isFileOrDirectory(file)) {
   /* ... */
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1067.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1067.html
index 75687afeff3..bd63fba067b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1067.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1067.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>The complexity of an expression is defined by the number of <code>&amp;&amp;</code>, <code>||</code> and <code>condition ? ifTrue : ifFalse</code>
 operators it contains.</p>
 <p>A single expression’s complexity should not become too high to keep the code readable.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold value of 3:</p>
 <pre>
 if (((condition1 &amp;&amp; condition2) || (condition3 &amp;&amp; condition4)) &amp;&amp; condition5) { ... }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if ( (myFirstCondition() || mySecondCondition()) &amp;&amp; myLastCondition()) { ... }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue is reported inside <code>equals</code> methods, because it is common to compare all the fields of a class for equality inside this kind of
 method.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1068.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1068.html
index 6c2c9cec897..6ddbb798cf2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1068.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1068.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>If a <code>private</code> field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will
 improve maintainability because developers will not wonder what the variable is used for.</p>
 <p>Note that this rule does not take reflection into account, which means that issues will be raised on <code>private</code> fields that are only
 accessed using the reflection API.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   private int foo = 42;
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   public int compute(int a) {
@@ -21,14 +22,11 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The rule admits 3 exceptions:</p>
 <ul>
   <li> Serialization id fields </li>
-  <li> Annotated fields </li>
-  <li> Fields from classes with native methods </li>
 </ul>
-<h3>Serialization id fields</h3>
 <p>The Java serialization runtime associates with each serializable class a version number, called <code>serialVersionUID</code>, which is used during
 deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to
 serialization.</p>
@@ -39,7 +37,9 @@ <h3>Serialization id fields</h3>
   private static final long serialVersionUID = 42L;
 }
 </pre>
-<h3>Annotated fields</h3>
+<ul>
+  <li> Annotated fields </li>
+</ul>
 <p>The unused field in this class will not be reported by the rule as it is annotated.</p>
 <pre>
 public class MyClass {
@@ -47,7 +47,9 @@ <h3>Annotated fields</h3>
   private int unused;
 }
 </pre>
-<h3>Fields from classes with native methods</h3>
+<ul>
+  <li> Fields from classes with native methods </li>
+</ul>
 <p>The unused field in this class will not be reported by the rule as it might be used by native code.</p>
 <pre>
 public class MyClass {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S107.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S107.html
index 43ca4638a38..13455d96dad 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S107.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S107.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>A long parameter list can indicate that a new structure should be created to wrap the numerous parameters or that the function is doing too many
 things.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a maximum number of 4 parameters:</p>
 <pre>
 public void doSomething(int param1, int param2, int param3, String param4, long param5) {
 ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(int param1, int param2, int param3, String param4) {
 ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Methods annotated with :</p>
 <ul>
   <li> Spring’s <code>@RequestMapping</code> (and related shortcut annotations, like <code>@GetRequest</code>) </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1075.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1075.html
index 91c58f63eed..1f07840f0fe 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1075.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1075.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Hard coding a URI makes it difficult to test a program: path literals are not always portable across operating systems, a given absolute path may
 not exist on a specific test environment, a specified Internet URL may not be available when executing the tests, production environment filesystems
 usually differ from the development environment, …​etc. For all those reasons, a URI should never be hard coded. Instead, it should be replaced by
 customizable parameter.</p>
 <p>Further even if the elements of a URI are obtained dynamically, portability can still be limited if the path-delimiters are hard-coded.</p>
 <p>This rule raises an issue when URI’s or path delimiters are hard coded.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
   public Collection&lt;User&gt; listUsers() {
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo {
   // Configuration is a class that returns customizable properties: it can be mocked to be injected during tests.
@@ -32,7 +33,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
index f4d1be00b83..9aa75a10fc0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Most of the time a block of code is empty when a piece of code is really missing. So such empty block must be either filled or removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 0; i &lt; 42; i++){}  // Empty on purpose or missing piece of code ?
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When a block contains a comment, this block is not considered to be empty unless it is a <code>synchronized</code> block. <code>synchronized</code>
 blocks are still considered empty even with comments because they can still affect program flow.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S109.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S109.html
index c6cc3ef402d..244e36a0103 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S109.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S109.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>A magic number is a number that comes out of nowhere, and is directly used in a statement. Magic numbers are often used, for instance to limit the
 number of iterations of a loop, to test the value of a property, etc.</p>
 <p>Using magic numbers may seem obvious and straightforward when you’re writing a piece of code, but they are much less obvious and straightforward at
 debugging time.</p>
 <p>That is why magic numbers must be demystified by first being assigned to clearly named variables before being used.</p>
 <p>-1, 0 and 1 are not considered magic numbers.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static void doSomething() {
 	for(int i = 0; i &lt; 4; i++){                 // Noncompliant, 4 is a magic number
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 	}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static final int NUMBER_OF_CYCLES = 4;
 public static void doSomething() {
@@ -21,6 +22,6 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule ignores <code>hashCode</code> methods.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
index 31849e855df..63beb6ffe8c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Inheritance is certainly one of the most valuable concepts in object-oriented programming. It’s a way to compartmentalize and reuse code by
 creating collections of attributes and behaviors called classes which can be based on previously created classes. But abusing this concept by creating
 a deep inheritance tree can lead to very complex and unmaintainable source code. Most of the time too deep of an inheritance tree is due to bad object
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1104.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1104.html
index dd6f529eff3..f38727d5ba5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1104.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1104.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Public class variable fields do not respect the encapsulation principle and has three main disadvantages:</p>
 <ul>
   <li> Additional behavior such as validation cannot be added. </li>
@@ -5,7 +6,7 @@
   <li> Member values are subject to change from anywhere in the code and may not meet the programmer’s assumptions. </li>
 </ul>
 <p>By using private attributes and accessor methods (set and get), unauthorized modifications are prevented.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
 
@@ -33,10 +34,10 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Because they are not modifiable, this rule ignores <code>public final</code> fields. Also, annotated fields, whatever the annotation(s) will be
 ignored, as annotations are often used by injection frameworks, which in exchange require having public fields.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/493">MITRE, CWE-493</a> - Critical Public Variable Without Final Modifier </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1105.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1105.html
index 4076cfc2fd1..a5963b0d705 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1105.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1105.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when an open curly brace is not placed at the end of a
 line of code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if(condition)
 {
   doSomething();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if(condition) {
   doSomething();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When blocks are inlined (left and right curly braces on the same line), no issue is triggered.</p>
 <pre>
 if(condition) {doSomething();}
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1106.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1106.html
index bfee821fb9c..311db9aed49 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1106.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1106.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions make it possible to collaborate efficiently. This rule makes it mandatory to place the open curly brace at the beginning
 of a line.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void myMethod {  // Noncompliant
   if(something) {  // Noncompliant
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void myMethod
 {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1107.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1107.html
index a714c8c3453..376ae51b4b7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1107.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1107.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions make it possible for a team to collaborate efficiently.</p>
 <p>This rule makes it mandatory to place closing curly braces on the same line as the next <code>else</code>, <code>catch</code> or
 <code>finally</code> keywords.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void myMethod() {
   if(something) {
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void myMethod() {
   if(something) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1108.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1108.html
index 5d0a8278ed0..c2c8b6e0528 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1108.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1108.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions make it possible for a team to collaborate efficiently.</p>
 <p>This rule makes it mandatory to place a closing curly brace and the next <code>else</code>, <code>catch</code> or <code>finally</code> keyword on
 two different lines.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void myMethod() {
   if(something) {
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void myMethod() {
   if(something) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1109.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1109.html
index 95698c23d44..17acbac7e51 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1109.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1109.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions make it possible for a team to efficiently collaborate. This rule makes it mandatory to place a close curly brace at the
 beginning of a line.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if(condition) {
   doSomething();}
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if(condition) {
   doSomething();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When blocks are inlined (open and close curly braces on the same line), no issue is triggered.</p>
 <pre>
 if(condition) {doSomething();}
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1110.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1110.html
index de6db5b911c..de7eeaf8a62 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1110.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1110.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The use of parentheses, even those not required to enforce a desired order of operations, can clarify the intent behind a piece of code. But
 redundant pairs of parentheses could be misleading, and should be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int x = (y / 2 + 1);   //Compliant even if the parenthesis are ignored by the compiler
 
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
 
 return ((x + 1));  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int x = (y / 2 + 1);
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
index f1dd64245f3..69833610279 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>According to the official javadoc documentation, this Object.finalize() is called by the garbage collector on an object when garbage collection
 determines that there are no more references to the object. Calling this method explicitly breaks this contract and so is misleading.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void dispose() throws Throwable {
   this.finalize();                       // Noncompliant
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/586">MITRE, CWE-586</a> - Explicit Call to Finalize() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
index 8e46370091b..81f76dbe18f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>Object.finalize()</code> method is called on an object by the garbage collector when it determines that there are no more references to
 the object. But there is absolutely no warranty that this method will be called AS SOON AS the last references to the object are removed. It can be
 few microseconds to few minutes later. So when system resources need to be disposed by an object, it’s better to not rely on this asynchronous
 mechanism to dispose them.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   ...
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
index 5e55c269554..fb6513fbe7d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Overriding the <code>Object.finalize()</code> method must be done with caution to dispose some system resources.</p>
 <p>Calling the <code>super.finalize()</code> at the end of this method implementation is highly recommended in case parent implementations must also
 dispose some system resources.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 protected void finalize() {   // Noncompliant; no call to super.finalize();
   releaseSomeResources();
@@ -12,14 +13,14 @@ <h2>Noncompliant Code Example</h2>
   releaseSomeResources();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 protected void finalize() {
   releaseSomeResources();
   super.finalize();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/568">MITRE, CWE-568</a> - finalize() Method Without super.finalize() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1116.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1116.html
index 99bc62983bf..f98f80a5496 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1116.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1116.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Empty statements, i.e. <code>;</code>, are usually introduced by mistake, for example because:</p>
 <ul>
   <li> It was meant to be replaced by an actual statement, but this was forgotten. </li>
   <li> There was a typo which lead the semicolon to be doubled, i.e. <code>;;</code>. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void doSomething() {
   ;                                                       // Noncompliant - was used as a kind of TODO marker
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void doSomething() {}
 
@@ -25,7 +26,7 @@ <h2>Compliant Solution</h2>
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
index d4305415135..fe4b6a30992 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of
 code. Further, it could lead maintainers to introduce bugs because they think they’re using one variable but are really using another.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Foo {
   public int myField;
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/c/DCL01-C.+Do+not+reuse+variable+names+in+subscopes">CERT, DCL01-C.</a> - Do not reuse
   variable names in subscopes </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
index d0aa242532c..36ded924a7b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Utility classes, which are collections of <code>static</code> members, are not meant to be instantiated. Even abstract utility classes, which can
 be extended, should not have public constructors.</p>
 <p>Java adds an implicit public constructor to every class which does not define at least one explicitly. Hence, at least one non-public constructor
 should be defined.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class StringUtils { // Noncompliant
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class StringUtils { // Compliant
 
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When class contains <code>public static void main(String[] args)</code> method it is not considered as utility class and will be ignored by this
 rule.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1119.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1119.html
index 2401a5dd267..babb44ac3e1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1119.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1119.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Labels are not commonly used in Java, and many developers do not understand how they work. Moreover, their usage makes the control flow harder to
 follow, which reduces the code’s readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int matrix[][] = {
   {1, 2, 3},
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (int row = 1; row &lt; matrix.length; row++) {          // Compliant
   for (int col = 0; col &lt; row; col++) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S112.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S112.html
index d37fb9f7ad9..91d808c869f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S112.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S112.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>Using such generic exceptions as <code>Error</code>, <code>RuntimeException</code>, <code>Throwable</code>, and <code>Exception</code> prevents
 calling methods from handling true, system-generated exceptions differently than application-generated errors.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void foo(String bar) throws Throwable {  // Noncompliant
   throw new RuntimeException("My Message");     // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void foo(String bar) {
   throw new MyOwnRuntimeException("My Message");
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Generic exceptions in the signatures of overriding methods are ignored, because overriding method has to follow signature of the throw declaration
 in the superclass. The issue will be raised on superclass declaration of the method (or won’t be raised at all if superclass is not part of the
 analysis).</p>
@@ -26,7 +27,7 @@ <h2>Exceptions</h2>
   doTheThing();  // this method throws Exception
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/397">MITRE, CWE-397</a> - Declaration of Throws for Generic Exception </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/_DdGBQ">CERT, ERR07-J.</a> - Do not throw RuntimeException, Exception, or Throwable </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html
index a8cd7b142fc..93300538981 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Proper indentation is a simple and effective way to improve the code’s readability. Consistent indentation among the developers within a team also
 reduces the differences that are committed to source control systems, making code reviews easier.</p>
 <p>This rule raises an issue when indentation does not match the configured value. Only the first line of a badly indented section is reported.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With an indent size of 2:</p>
 <pre>
 class Foo {
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Foo {
   public int a;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1121.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1121.html
index c71a4e0a106..62fc817b7d1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1121.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1121.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Assignments within sub-expressions are hard to spot and therefore make the code less readable. Ideally, sub-expressions should not have
 side-effects.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if ((str = cont.substring(pos1, pos2)).isEmpty()) {  // Noncompliant
   //...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 str = cont.substring(pos1, pos2);
 if (str.isEmpty()) {
   //...
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Assignments in <code>while</code> statement conditions, and assignments enclosed in relational expressions are ignored.</p>
 <pre>
 BufferedReader br = new BufferedReader(/* ... */);
@@ -25,7 +26,7 @@ <h2>Exceptions</h2>
 int k = (j += 1);
 result = (bresult = new byte[len]);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/481">MITRE, CWE-481</a> - Assigning instead of Comparing </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ZNYxBQ">CERT, EXP45-C.</a> - Do not perform assignments in selection statements </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1123.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1123.html
index 663162d539c..557a21a61f9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1123.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1123.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Deprecation should be marked with both the <code>@Deprecated</code> annotation and @deprecated Javadoc tag. The annotation enables tools such as
 IDEs to warn about referencing deprecated elements, and the tag can be used to explain when it was deprecated, why, and how references should be
 refactored.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass {
 
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
 
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The members and methods of a deprecated class or interface are ignored by this rule. The classes and interfaces themselves are still subject to
 it.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1124.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1124.html
index f0760bab026..31e70421aeb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1124.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1124.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The Java Language Specification recommends listing modifiers in the following order:</p>
 <ol>
   <li> Annotations </li>
@@ -16,12 +17,12 @@
 </ol>
 <p>Not following this convention has no technical impact, but will reduce the code’s readability because most developers are used to the standard
 order.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 static public void main(String[] args) {   // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static void main(String[] args) {   // Compliant
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1125.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1125.html
index c2bba7f3413..e530943ad97 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1125.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1125.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Redundant Boolean literals should be removed from expressions to improve readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (booleanMethod() == true) { /* ... */ }
 if (booleanMethod() == false) { /* ... */ }
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 booleanVariable = booleanMethod() ? exp : true;
 booleanVariable = booleanMethod() ? exp : false;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (booleanMethod()) { /* ... */ }
 if (!booleanMethod()) { /* ... */ }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1126.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1126.html
index 7c7cb799b38..c160b634ff9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1126.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1126.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Return of boolean literal statements wrapped into <code>if-then-else</code> ones should be simplified.</p>
 <p>Similarly, method invocations wrapped into <code>if-then-else</code> differing only from boolean literals should be simplified into a single
 invocation.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 boolean foo(Object param) {
   if (expression) { // Noncompliant
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 boolean foo(Object param) {
   bar(param, expression, "qix");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1128.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1128.html
index 5b91ace0be9..2f68de3c69e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1128.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1128.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The imports part of a file should be handled by the Integrated Development Environment (IDE), not manually by the developer.</p>
 <p>Unused and useless imports should not occur if that is the case.</p>
 <p>Leaving them in reduces the code’s readability, since their presence can be confusing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 package my.company;
 
@@ -19,6 +20,6 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Imports for types mentioned in Javadocs are ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S113.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S113.html
index 5c9fcea9481..33ec564a16a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S113.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S113.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Some tools work better when files end with an empty line.</p>
 <p>This rule simply generates an issue if it is missing.</p>
 <p>For example, a Git diff looks like this if the empty line is missing at the end of the file:</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
index 27935df9b1e..fbb92b15ee6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
@@ -1,20 +1,21 @@
+<h2>Why is this an issue?</h2>
 <p>An exception in a <code>throws</code> declaration in Java is superfluous if it is:</p>
 <ul>
   <li> listed multiple times </li>
   <li> a subclass of another listed exception </li>
   <li> completely unnecessary because the declared exception type cannot actually be thrown </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void foo() throws MyException, MyException {}  // Noncompliant; should be listed once
 void bar() throws Throwable, Exception {}  // Noncompliant; Exception is a subclass of Throwable
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void foo() throws MyException {}
 void bar() throws Throwable {}
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The rule will not raise any issue for exceptions that cannot be thrown from the method body:</p>
 <ul>
   <li> in overriding and implementation methods </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1132.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1132.html
index 00e08a1163d..927ed8708dc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1132.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1132.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>It is preferable to place string literals on the left-hand side of an <code>equals()</code> or <code>equalsIgnoreCase()</code> method call.</p>
 <p>This prevents null pointer exceptions from being raised, as a string literal can never be null by definition.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String myString = null;
 
 System.out.println("Equal? " + myString.equals("foo"));                        // Noncompliant; will raise a NPE
 System.out.println("Equal? " + (myString != null &amp;&amp; myString.equals("foo")));  // Noncompliant; null check could be removed
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 System.out.println("Equal?" + "foo".equals(myString));                         // properly deals with the null case
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1133.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1133.html
index ea251e892de..3c016e770f6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1133.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1133.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule is meant to be used as a way to track code which is marked as being deprecated. Deprecated code should eventually be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Foo {
   /**
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
index 931d4d1a139..42d9a98a2a7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p><code>FIXME</code> tags are commonly used to mark places where a bug is suspected, but which the developer wants to deal with later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int divide(int numerator, int denominator) {
   return numerator / denominator;              // FIXME denominator value might be  0
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1135.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1135.html
index 1387f1c4d16..ed19bae4f88 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1135.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1135.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p><code>TODO</code> tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void doSomething() {
   // TODO
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S114.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S114.html
index ed5b5c83cbd..6072a33602e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S114.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S114.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that all
 interface names match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 public interface myInterface {...} // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface MyInterface {...}
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1141.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1141.html
index 6feef6d433c..676aadd3e20 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1141.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1141.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Nesting <code>try</code>/<code>catch</code> blocks severely impacts the readability of source code because it makes it too difficult to understand
 which block will catch which exception.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1142.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1142.html
index 3158f971efb..e7b2bc30c82 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1142.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1142.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Having too many return statements in a method increases the method’s essential complexity because the flow of execution is broken each time a
 return statement is encountered. This makes it harder to read and understand the logic of the method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold of 3:</p>
 <pre>
 public boolean myMethod() { // Noncompliant; there are 4 return statements
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1143.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1143.html
index 699a95a5042..2064f67ef40 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1143.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1143.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>return</code>, <code>break</code>, <code>throw</code>, and so on from a <code>finally</code> block suppresses the propagation of any
 unhandled <code>Throwable</code> which was thrown in the <code>try</code> or <code>catch</code> block.</p>
 <p>This rule raises an issue when a jump statement (<code>break</code>, <code>continue</code>, <code>return</code>, <code>throw</code>, and
 <code>goto</code>) would force control flow to leave a <code>finally</code> block.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static void main(String[] args) {
   try {
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static void main(String[] args) {
   try {
@@ -55,7 +56,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/584">MITRE, CWE-584</a> - Return Inside Finally Block </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/BTdGBQ">CERT, ERR04-J.</a> - Do not complete abruptly from a finally block </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1144.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1144.html
index 695380375d5..678681fdd3a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1144.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1144.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p><code>private</code> methods that are never executed are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code
 decreases the size of the maintained codebase, making it easier to understand the program and preventing bugs from being introduced.</p>
 <p>Note that this rule does not take reflection into account, which means that issues will be raised on <code>private</code> methods that are only
 accessed using the reflection API.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo implements Serializable
 {
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   private void readObject(ObjectInputStream in){...}  //Compliant, relates to the java serialization mechanism
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo implements Serializable
 {
@@ -31,7 +32,7 @@ <h2>Compliant Solution</h2>
   private void readObject(ObjectInputStream in){...}  //Compliant, relates to the java serialization mechanism
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise issues for:</p>
 <ul>
   <li> annotated methods </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1147.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1147.html
index e78d0da9de1..16881c03cfb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1147.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1147.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Calling <code>System.exit(int status)</code> or <code>Rutime.getRuntime().exit(int status)</code> calls the shutdown hooks and shuts downs the
 entire Java virtual machine. Calling <code>Runtime.getRuntime().halt(int)</code> does an immediate shutdown, without calling the shutdown hooks, and
 skipping finalization.</p>
 <p>Each of these methods should be used with extreme care, and only when the intent is to stop the whole Java process. For instance, none of them
 should be called from applications running in a J2EE container.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 System.exit(0);
 Runtime.getRuntime().exit(0);
 Runtime.getRuntime().halt(0);
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>These methods are ignored inside <code>main</code>.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/382">MITRE, CWE-382</a> - Use of System.exit() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/7zZGBQ">CERT, ERR09-J.</a> - Do not allow untrusted code to terminate the JVM </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
index 3aa09759e54..ec4c6b1eb66 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Early classes of the Java API, such as <code>Vector</code>, <code>Hashtable</code> and <code>StringBuffer</code>, were synchronized to make them
 thread-safe. Unfortunately, synchronization has a big negative impact on performance, even when using these collections from a single thread.</p>
 <p>It is better to use their new unsynchronized replacements:</p>
@@ -9,15 +10,15 @@
 </ul>
 <p>Even when used in synchronized context, you should think twice before using it, since it’s usage can be tricky. If you are confident the usage is
 legitimate, you can safely ignore this warning.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Vector cats = new Vector();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ArrayList cats = new ArrayList();
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Use of those synchronized classes is ignored in the signatures of overriding methods.</p>
 <pre>
 @Override
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S115.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S115.html
index 60e0ab03c1e..e38d55a6892 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S115.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S115.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions allow teams to collaborate efficiently. This rule checks that all constant names match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$</code>:</p>
 <pre>
 public class MyClass {
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   first;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   public static final int FIRST = 1;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
index edf02d2b331..9c8e5fbaa86 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>From the official Oracle Javadoc:</p>
 <blockquote>
   <p>NOTE: The functionality of this Enumeration interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove
   operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration.</p>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass implements Enumeration {  // Non-Compliant
   /* ... */
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass implements Iterator {     // Compliant
   /* ... */
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1151.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1151.html
index 657dc48be88..ba0eb4b1c05 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1151.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1151.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>switch</code> statement should be used only to clearly define some new branches in the control flow. As soon as a <code>case</code>
 clause contains too many statements this highly decreases the readability of the overall control flow statement. In such case, the content of the
 <code>case</code> clause should be extracted into a dedicated method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold of 5:</p>
 <pre>
 switch (myVariable) {
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch (myVariable) {
   case 0:
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
index 538b451892f..be20bc7daff 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>Appending <code>String.valueOf()</code> to a <code>String</code> decreases the code readability.</p>
 <p>The argument passed to <code>String.valueOf()</code> should be directly appended instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void display(int i){
   System.out.println("Output is " + String.valueOf(i));    // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void display(int i){
   System.out.println("Output is " + i);                    // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1155.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1155.html
index 29181003d1a..f43a958cd18 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1155.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1155.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>Collection.size()</code> to test for emptiness works, but using <code>Collection.isEmpty()</code> makes the code more readable and can
 be more performant. The time complexity of any <code>isEmpty()</code> method implementation should be <code>O(1)</code> whereas some implementations
 of <code>size()</code> can be <code>O(n)</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (myCollection.size() == 0) {  // Noncompliant
   /* ... */
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (myCollection.isEmpty()) {
   /* ... */
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
index efcb3eecade..6f556039cae 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>toLowerCase()</code> or <code>toUpperCase()</code> to make case insensitive comparisons is inefficient because it requires the creation
 of temporary, intermediate <code>String</code> objects.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 boolean result1 = foo.toUpperCase().equals(bar);             // Noncompliant
 boolean result2 = foo.equals(bar.toUpperCase());             // Noncompliant
 boolean result3 = foo.toLowerCase().equals(bar.LowerCase()); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 boolean result = foo.equalsIgnoreCase(bar);                  // Compliant
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue will be raised when a locale is specified because the result could be different from "equalsIgnoreCase". (e.g.: using the Turkish
 locale)</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
index c5d7341c890..e71183a256f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>Creating temporary primitive wrapper objects only for <code>String</code> conversion or the use of the <code>compareTo</code> method is
 inefficient.</p>
 <p>Instead, the static <code>toString</code> or <code>compare</code> method of the primitive wrapper class should be used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 new Integer(myInteger).toString();   // Noncompliant
 Integer.valueOf(myInt).compareTo(0); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Integer.toString(myInteger);        // Compliant
 Integer.compare(myInteger, 0);      // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S116.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S116.html
index af42b7f3a76..d6a8bacc935 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S116.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S116.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that field
 names match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 class MyClass {
    private int my_field;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
    private int myField;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1160.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1160.html
index a80b1614931..b5df1038170 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1160.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1160.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>Using checked exceptions forces method callers to deal with errors, either by propagating them or by handling them. Throwing exceptions makes them
 fully part of the API of the method.</p>
 <p>But to keep the complexity for callers reasonable, methods should not throw more than one kind of checked exception.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void delete() throws IOException, SQLException {      // Noncompliant
   /* ... */
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void delete() throws SomeApplicationLevelException {
   /* ... */
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Overriding methods are not checked by this rule and are allowed to throw several checked exceptions.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
index eb769b3a9d8..d9823986bfe 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Using the <code>@Override</code> annotation is useful for two reasons :</p>
 <ul>
   <li> It elicits a warning from the compiler if the annotated method doesn’t actually override anything, as in the case of a misspelling. </li>
   <li> It improves the readability of the source code by making it obvious that methods are overridden. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class ParentClass {
   public boolean doSomething(){...}
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   public boolean doSomething(){...}  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class ParentClass {
   public boolean doSomething(){...}
@@ -22,6 +23,6 @@ <h2>Compliant Solution</h2>
   public boolean doSomething(){...}  // Compliant
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule is relaxed when overriding a method from the <code>Object</code> class like <code>toString()</code>, <code>hashCode()</code>, …​</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1162.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1162.html
index e6865dd9512..4ec1bff1a7d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1162.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1162.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The purpose of checked exceptions is to ensure that errors will be dealt with, either by propagating them or by handling them, but some believe
 that checked exceptions negatively impact the readability of source code, by spreading this error handling/propagation logic everywhere.</p>
 <p>This rule verifies that no method throws a new checked exception.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void myMethod1() throws CheckedException {
   ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
index 9e07cd7f42d..86f7cd1589b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Throwing an exception from within a finally block will mask any exception which was previously thrown in the <code>try</code> or <code>catch</code>
 block, and the masked’s exception message and stack trace will be lost.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try {
   /* some work which end up throwing an exception */
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   throw new RuntimeException();       // Noncompliant; masks the IllegalArgumentException
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try {
   /* some work which end up throwing an exception */
@@ -19,7 +20,7 @@ <h2>Compliant Solution</h2>
   /* clean up */
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/FTZGBQ">CERT, ERR05-J.</a> - Do not let checked exceptions escape from a finally block </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
index d07d6192d68..c750d2bd554 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Exceptions are meant to represent the application’s state at the point at which an error occurred.</p>
 <p>Making all fields in an <code>Exception</code> class <code>final</code> ensures that this state:</p>
 <ul>
@@ -5,7 +6,7 @@
   <li> Won’t be updated or corrupted by a questionable error handler. </li>
 </ul>
 <p>This will enable developers to quickly understand what went wrong.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyException extends Exception {
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyException extends Exception {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1166.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1166.html
index 42d38904c28..1b9c97dce40 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1166.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1166.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>When handling a caught exception, the original exception’s message and stack trace should be logged or passed forward.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try {
   /* ... */
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   throw new RuntimeException("context");
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try {
   /* ... */
@@ -42,7 +43,7 @@ <h2>Compliant Solution</h2>
   throw new RuntimeException(e);  // Conversion into unchecked exception is also allowed
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>InterruptedException</code>, <code>NumberFormatException</code>, <code>DateTimeParseException</code>, <code>ParseException</code> and
 <code>MalformedURLException</code> exceptions are arguably used to indicate nonexceptional outcomes. Similarly, handling
 <code>NoSuchMethodException</code> is often required when dealing with the Java reflection API.</p>
@@ -67,7 +68,7 @@ <h2>Exceptions</h2>
   LOGGER.warn(message); // Compliant - exception message logged with some contextual information
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/">OWASP Top 10 2021 Category A9</a> - Security Logging and
   Monitoring Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1168.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1168.html
index 1de97a62856..b94513b6b5a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1168.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1168.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Returning <code>null</code> instead of an actual array, collection or map forces callers of the method to explicitly test for nullity, making them
 more complex and less readable.</p>
 <p>Moreover, in many cases, <code>null</code> is used as a synonym for empty.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static List&lt;Result&gt; getAllResults() {
   return null;                             // Noncompliant
@@ -36,7 +37,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static List&lt;Result&gt; getAllResults() {
   return Collections.emptyList();          // Compliant
@@ -62,7 +63,7 @@ <h2>Compliant Solution</h2>
   getValues().forEach((k, v) -&gt; doSomething(k, v));
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/aNYxBQ">CERT, MSC19-C.</a> - For functions that return an array, prefer returning an empty array
   over a null value </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S117.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S117.html
index c43c925224e..b67712986e4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S117.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S117.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when a local variable or function parameter name does
 not match the provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 public void doSomething(int my_param) {
@@ -8,14 +9,14 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(int myParam) {
   int local;
   ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Loop counters are ignored by this rule.</p>
 <pre>
 for (int i_1 = 0; i_1 &lt; limit; i_1++) {  // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1170.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1170.html
index b334aa91dd1..99ce3c8bfae 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1170.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1170.html
@@ -1,21 +1,22 @@
+<h2>Why is this an issue?</h2>
 <p>Making a <code>public</code> constant just <code>final</code> as opposed to <code>static final</code> leads to duplicating its value for every
 instance of the class, uselessly increasing the amount of memory required to execute the application.</p>
 <p>Further, when a non-<code>public</code>, <code>final</code> field isn’t also <code>static</code>, it implies that different instances can have
 different values. However, initializing a non-<code>static final</code> field in its declaration forces every instance to have the same value. So such
 fields should either be made <code>static</code> or initialized in the constructor.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Myclass {
   public final int THRESHOLD = 3;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Myclass {
   public static final int THRESHOLD = 3;    // Compliant
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issues are reported on final fields of inner classes whose type is not a primitive or a String. Indeed according to the Java specification:</p>
 <blockquote>
   <p>An inner class is a nested class that is not explicitly or implicitly declared static. Inner classes may not declare static initializers (§8.7)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
index df501761f9a..92f440359f0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Non-static initializers are rarely used, and can be confusing for most developers because they only run when new class instances are created. When
 possible, non-static initializers should be refactored into standard constructors or field initializers.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass {
   private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;String, String&gt;() {
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   };
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
   private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;String, String&gt;();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1172.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1172.html
index 3bdcefa4774..03f75548d7e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1172.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1172.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Unused parameters are misleading. Whatever the values passed to such parameters, the behavior will be the same.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void doSomething(int a, int b) {     // "b" is unused
   compute(a);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void doSomething(int a) {
   compute(a);
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The rule will not raise issues for unused parameters:</p>
 <ul>
   <li> that are annotated with <code>@javax.enterprise.event.Observes</code> </li>
@@ -48,7 +49,7 @@ <h2>Exceptions</h2>
   compute(a);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1174.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1174.html
index 2b90584b429..1c83cda9a42 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1174.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1174.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The contract of the <code>Object.finalize()</code> method is clear: only the Garbage Collector is supposed to call this method.</p>
 <p>Making this method public is misleading, because it implies that any caller can use it.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/583">MITRE, CWE-583</a> - finalize() Method Declared Public </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1175.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1175.html
index 4442ed48c43..a5806ae469f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1175.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1175.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>Object.finalize()</code> is called by the Garbage Collector at some point after the object becomes unreferenced.</p>
 <p>In general, overloading <code>Object.finalize()</code> is a bad idea because:</p>
 <ul>
@@ -5,13 +6,13 @@
   <li> Users are not expected to call <code>Object.finalize()</code> and will get confused. </li>
 </ul>
 <p>But beyond that it’s a terrible idea to name a method "finalize" if it doesn’t actually override <code>Object.finalize()</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int finalize(int someParameter) {        // Noncompliant
   /* ... */
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int someBetterName(int someParameter) {  // Compliant
   /* ... */
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1176.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1176.html
index 4bb11828691..4760081b610 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1176.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1176.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Try to imagine using the standard Java API (Collections, JDBC, IO, …​) without Javadoc. It would be a nightmare, because Javadoc is the only way to
 understand of the contract of the API. Documenting an API with Javadoc increases the productivity of the developers consuming it.</p>
 <p>On top of a main description for each member of a public API, the following Javadoc elements are required to be described:</p>
@@ -34,7 +35,7 @@
   <li> <code>java.internal.*</code> will match any member of <code>java.internal</code> package. </li>
   <li> <code>java.internal.**</code> same as above, but including sub-packages. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 /**
   * This is a Javadoc comment
@@ -69,7 +70,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 /**
   * This is a Javadoc comment
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S118.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S118.html
index 856ae258549..81538678fba 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S118.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S118.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that all
 <code>abstract</code> class names match a provided regular expression. If a non-abstract class match the regular expression, an issue is raised to
 suggest to either make it abstract or to rename it.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression: <code>^Abstract[A-Z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 abstract class MyClass { // Noncompliant
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
 class AbstractLikeClass { // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 abstract class AbstractClass {
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1181.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1181.html
index b0bf820e980..e2b7096c25a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1181.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1181.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p><code>Throwable</code> is the superclass of all errors and exceptions in Java. <code>Error</code> is the superclass of all errors, which are not
 meant to be caught by applications.</p>
 <p>Catching either <code>Throwable</code> or <code>Error</code> will also catch <code>OutOfMemoryError</code> and <code>InternalError</code>, from
 which an application should not attempt to recover.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try { /* ... */ } catch (Throwable t) { /* ... */ }
 try { /* ... */ } catch (Error e) { /* ... */ }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try { /* ... */ } catch (RuntimeException e) { /* ... */ }
 try { /* ... */ } catch (MyException e) { /* ... */ }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/396">MITRE, CWE-396</a> - Declaration of Catch for Generic Exception </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors">CERT,
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
index df594e5a585..a04f9593827 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>Cloneable</code> is the marker <code>Interface</code> that indicates that <code>clone()</code> may be called on an object. Overriding
 <code>clone()</code> without implementing <code>Cloneable</code> can be useful if you want to control how subclasses clone themselves, but otherwise,
 it’s probably a mistake.</p>
@@ -13,7 +14,7 @@
   <li> <code>super.clone()</code> returns an object of the same type as the one <code>clone()</code> was called on </li>
   <li> <code>Object.clone()</code> performs a shallow copy of the object’s state </li>
 </ol>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class BaseClass {  // Noncompliant; should implement Cloneable
   @Override
@@ -37,7 +38,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class BaseClass implements Cloneable {
   @Override
@@ -61,7 +62,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/580">MITRE, CWE-580</a> - clone() Method Without super.clone() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/FjZGBQ">CERT, MET53-J.</a> - Ensure that the clone() method calls super.clone() </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1185.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1185.html
index 257f3956a4d..c05355a9441 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1185.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1185.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Overriding a method just to call the same method from the super class without performing any other actions is useless and misleading. The only time
 this is justified is in <code>final</code> overriding methods, where the effect is to lock in the parent class behavior. This rule ignores such
 overrides of <code>equals</code>, <code>hashCode</code> and <code>toString</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething() {
   super.doSomething();
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   return super.isLegal(action);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Override
 public boolean isLegal(Action action) {         // Compliant - not simply forwarding the call
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1186.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1186.html
index ace7ee7f0dd..c0000397ee1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1186.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1186.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>There are several reasons for a method not to have a method body:</p>
 <ul>
   <li> It is an unintentional omission, and should be fixed to prevent an unexpected behavior in production. </li>
   <li> It is not yet, or never will be, supported. In this case an <code>UnsupportedOperationException</code> should be thrown. </li>
   <li> The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething() {
 }
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 public void doSomethingElse() {
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Override
 public void doSomething() {
@@ -24,7 +25,7 @@ <h2>Compliant Solution</h2>
   throw new UnsupportedOperationException();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This does not raise an issue in the following cases:</p>
 <ul>
   <li> Non-public default (no-argument) constructors </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1188.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1188.html
index 58e2702b827..0da4ecfb19b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1188.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1188.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Anonymous classes are a very convenient and compact way to inject a behavior without having to create a dedicated class. But those anonymous inner
 classes should be used only if the behavior to be injected can be defined in a few lines of code, otherwise the source code can quickly become
 unreadable.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S119.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S119.html
index ab1953a8054..c61530938f1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S119.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S119.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions make it possible for a team to collaborate efficiently. Following the established convention of single-letter type
 parameter names helps users and maintainers of your code quickly see the difference between a type parameter and a poorly named class.</p>
 <p>This rule check that all type parameter names match a provided regular expression. The following code snippets use the default regular
 expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass&lt;TYPE&gt; { // Noncompliant
   &lt;TYPE&gt; void method(TYPE t) { // Noncompliant
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass&lt;T&gt; {
   &lt;T&gt; void method(T t) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
index e5b9db56053..1c910712436 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Through Java’s evolution keywords have been added. While code that uses those words as identifiers may be compilable under older versions of Java,
 it will not be under modern versions.</p>
 <p>Following keywords are marked as invalid identifiers</p>
@@ -25,14 +26,14 @@
 </table>
 <p><code>assert</code> and <code>strictfp</code> are another example of valid identifiers which became keywords in later versions, but are not
 supported by this rule.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething() {
   int enum = 42;            // Noncompliant
   String _ = "";   // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething() {
   int magic = 42;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
index 4bd4ae4923b..713e3f967db 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Classes in the <code>sun.*</code> packages are considered implementation details, and are not part of the Java API.</p>
 <p>They can cause problems when moving to new versions of Java because there is no backwards compatibility guarantee. Similarly, they can cause
 problems when moving to a different Java vendor, such as OpenJDK.</p>
 <p>Such classes are almost always wrapped by Java API classes that should be used instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import sun.misc.BASE64Encoder; // Noncompliant
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html
index 654d1f21cc8..0f9ebaa1197 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences.</p>
 <p>On the other hand, constants can be referenced from many places, but only need to be updated in a single place.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold of 3:</p>
 <pre>
 public void run() {
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   return "";                                       // Compliant - literal "" has less than 5 characters and is excluded
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private static final String ACTION_1 = "action1";  // Compliant
 
@@ -29,6 +30,6 @@ <h2>Compliant Solution</h2>
   release(ACTION_1);
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>To prevent generating some false-positives, literals having less than 5 characters are excluded.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
index fc7a0625d23..295e09a4183 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Multiple catch blocks of the appropriate type should be used instead of catching a general exception, and then testing on the type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try {
   /* ... */
@@ -8,14 +9,14 @@ <h2>Noncompliant Code Example</h2>
   if(e instanceof NullPointerException{ /* ... */ }  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try {
   /* ... */
 } catch (IOException e) { /* ... */ }                // Compliant
 } catch (NullPointerException e) { /* ... */ }       // Compliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/ERR51-J.+Prefer+user-defined+exceptions+over+more+general+exception+types">CERT,
   ERR51-J.</a> - Prefer user-defined exceptions over more general exception types </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1194.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1194.html
index d2cf21d9d2e..4ce221353e4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1194.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1194.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p><code>java.lang.Error</code> and its subclasses represent abnormal conditions, such as <code>OutOfMemoryError</code>, which should only be
 encountered by the Java Virtual Machine.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyException extends Error { /* ... */ }       // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyException extends Exception { /* ... */ }   // Compliant
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
index 332c1746891..9b7ba0e90da 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java Language Specification:</p>
 <blockquote>
   <p>For compatibility with older versions of the Java SE platform,</p>
@@ -5,13 +6,13 @@
   array type after the formal parameter list.</p>
   <p>This obsolescent syntax should not be used in new code.</p>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int getVector()[] { /* ... */ }    // Noncompliant
 
 public int[] getMatrix()[] { /* ... */ }  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int[] getVector() { /* ... */ }
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1197.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1197.html
index e633488ac16..1c33a34581b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1197.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1197.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Array designators should always be located on the type for better code readability. Otherwise, developers must look both at the type and the
 variable name to know whether or not a variable is an array.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int matrix[][];   // Noncompliant
 int[] matrix[];   // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int[][] matrix;   // Compliant
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1199.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1199.html
index c310d4802fd..011fb9de096 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1199.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1199.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Nested code blocks can be used to create a new scope and restrict the visibility of the variables defined inside it. Using this feature in a method
 typically indicates that the method has too many responsibilities, and should be refactored into smaller methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void evaluate(int operator) {
   // Do some computation...
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void evaluate(int operator) {
   // Do some computation...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S120.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S120.html
index b3eeac71e9c..c5aeef2108d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S120.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S120.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions allow teams to collaborate efficiently. This rule checks that all package names match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[a-z_]+(\.[a-z_][a-z0-9_]*)*$</code>:</p>
 <pre>
 package org.exAmple; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package org.example;
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1200.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1200.html
index 791552a63ff..007ccd11420 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1200.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1200.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Single Responsibility Principle, introduced by Robert C. Martin in his book "Principles of Object Oriented Design", a class should
 have only one responsibility:</p>
 <blockquote>
@@ -7,7 +8,7 @@
 </blockquote>
 <p>Classes which rely on many other classes tend to aggregate too many responsibilities and should be split into several smaller ones.</p>
 <p>Nested classes dependencies are not counted as dependencies of the outer class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a threshold of 5:</p>
 <pre>
 class Foo {                        // Noncompliant - Foo depends on too many classes: T1, T2, T3, T4, T5, T6 and T7
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
index 28236305efc..da0e38cebbe 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>"equals" as a method name should be used exclusively to override <code>Object.equals(Object)</code> to prevent any confusion.</p>
 <p>It is tempting to overload the method to take a specific class instead of <code>Object</code> as parameter, to save the class comparison check.
 However, this will not work as expected when that is the only override.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass {
   private int foo = 1;
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
   private int foo = 1;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1206.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1206.html
index 47611ddba52..19d0772d884 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1206.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1206.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java Language Specification, there is a contract between <code>equals(Object)</code> and <code>hashCode()</code>:</p>
 <blockquote>
   <p>If two objects are equal according to the <code>equals(Object)</code> method, then calling the <code>hashCode</code> method on each of the two
@@ -8,7 +9,7 @@
   hashtables.</p>
 </blockquote>
 <p>In order to comply with this contract, those methods should be either both inherited, or both overridden.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass {    // Noncompliant - should also override "hashCode()"
 
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {    // Compliant
 
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/581">MITRE, CWE-581</a> - Object Model Violation: Just One of Equals and Hashcode Defined </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/7DVGBQ">CERT, MET09-J.</a> - Classes that define an equals() method must also define a
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
index 48c10de6f9e..4b0f6a52775 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>While not technically incorrect, the omission of curly braces can be misleading, and may lead to the introduction of errors during maintenance.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (condition)  // Noncompliant
   executeSomething();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (condition) {
   executeSomething();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When the body of an <code>if</code> statement is a single <code>return</code>, <code>break</code> or <code>continue</code> and is on the same
 line.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/g9YxBQ">CERT, EXP19-C.</a> - Use braces for the body of an if, for, or while statement </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/MzZGBQ">CERT, EXP52-J.</a> - Use braces for the body of an if, for, or while statement </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1210.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1210.html
index 9480e691611..e9a710a4609 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1210.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1210.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java <code>Comparable.compareTo(T o)</code> documentation:</p>
 <blockquote>
   <p>It is strongly recommended, but not strictly required that <code>(x.compareTo(y)==0) == (x.equals(y))</code>.</p>
@@ -7,14 +8,14 @@
 <p>If this rule is violated, weird and unpredictable failures can occur.</p>
 <p>For example, in Java 5 the <code>PriorityQueue.remove()</code> method relied on <code>compareTo()</code>, but since Java 6 it has relied on
 <code>equals()</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo implements Comparable&lt;Foo&gt; {
   @Override
   public int compareTo(Foo foo) { /* ... */ }      // Noncompliant as the equals(Object obj) method is not overridden
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo implements Comparable&lt;Foo&gt; {
   @Override
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1213.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1213.html
index 3e1d2bcfda5..4d31bf8fe12 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1213.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1213.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java Code Conventions as defined by Oracle, the members of a class or interface declaration should appear in the following order
 in the source files:</p>
 <ul>
@@ -6,7 +7,7 @@
   <li> Constructors </li>
   <li> Methods </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo{
    private int field = 0;
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
    public static final int OPEN = 4;  //Noncompliant, variable defined after constructors and methods
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo{
    public static final int OPEN = 4;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
index cb1e545eaae..74afe87e6ee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to Joshua Bloch, author of "Effective Java":</p>
 <blockquote>
   <p>The constant interface pattern is a poor use of interfaces.</p>
@@ -9,14 +10,14 @@
   <p>all of its subclasses will have their namespaces polluted by the constants in the interface.</p>
 </blockquote>
 <p>This rule raises an issue when an interface consists solely of fields, without any other members.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 interface Status {                      // Noncompliant
    int OPEN = 1;
    int CLOSED = 2;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public enum Status {                    // Compliant
   OPEN,
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1215.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1215.html
index 4f021732cfb..681e8e1a72f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1215.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1215.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Calling <code>System.gc()</code> or <code>Runtime.getRuntime().gc()</code> is a bad idea for a simple reason: there is no way to know exactly what
 will be done under the hood by the JVM because the behavior will depend on its vendor, version and options:</p>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
index e979dc17238..e26c0abe878 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>The purpose of the <code>Thread.run()</code> method is to execute code in a separate, dedicated thread. Calling this method directly doesn’t make
 sense because it causes its code to be executed in the current thread.</p>
 <p>To get the expected behavior, call the <code>Thread.start()</code> method instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Thread myThread = new Thread(runnable);
 myThread.run(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Thread myThread = new Thread(runnable);
 myThread.start(); // Compliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/572">MITRE, CWE-572</a> - Call to Thread run() instead of start() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6DdGBQ">CERT THI00-J.</a> - Do not invoke Thread.run() </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1219.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1219.html
index 64c572ce6aa..fb1c240697f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1219.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1219.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Even if it is legal, mixing case and non-case labels in the body of a switch statement is very confusing and can even be the result of a typing
 error.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (day) {
   case MONDAY:
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
     /* ... */
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch (day) {
   case MONDAY:
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
index 713383e5044..58809c7594b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>For better readability, do not put more than one statement on a single line.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if(someCondition) doSomething();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if(someCondition) {
   doSomething();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
index c32d65029fa..b718b8eb09a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java Language Specification:</p>
 <blockquote>
   <p>Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just
   beginning development.</p>
 </blockquote>
 <p>To enforce this best practice, classes located in default package can no longer be accessed from named ones since Java 1.4.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass { /* ... */ }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package org.example;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
index cdbef354e06..542aea48df3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Naming a method <code>tostring</code>, <code>hashcode</code> or <code>equal</code> is either:</p>
 <ul>
   <li> A bug in the form of a typo. Overriding <code>toString</code>, <code>Object.hashCode()</code> (note the camelCasing) or
@@ -6,7 +7,7 @@
   </li>
 </ul>
 <p>In both cases, the method should be renamed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int hashcode() { /* ... */ }  // Noncompliant
 
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
 
 public boolean equal(Object obj) { /* ... */ }  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Override
 public int hashCode() { /* ... */ }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1223.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1223.html
index 96d677d2d79..0ec0e5b54c2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1223.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1223.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Having a class and some of its methods sharing the same name is misleading, and leaves others to wonder whether it was done that way on purpose, or
 was the methods supposed to be a constructor.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
    public Foo() {...}
    public void Foo(String label) {...}  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo {
    public Foo() {...}
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1226.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1226.html
index cb00435c34c..b6b6d7560ee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1226.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1226.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>While it is technically correct to assign to parameters from within method bodies, doing so before the parameter value is read is likely a bug.
 Instead, initial values of parameters, caught exceptions, and foreach parameters should be, if not treated as <code>final</code>, then at least read
 before reassignment.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doTheThing(String str, int i, List&lt;String&gt; strings) {
   str = Integer.toString(i); // Noncompliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1228.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1228.html
index 8df04c23f7d..78167f2e5e2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1228.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1228.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Each package in a Java project should include a <code>package-info.java</code> file. The purpose of this file is to document the Java package using
 javadoc and declare package annotations.</p>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 /**
 * This package has non null parameters and is documented.
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S124.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S124.html
index dcfbfc671e8..0a9462b4b89 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S124.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S124.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>This rule template can be used to create rules which will be triggered when the full content of a comment matches a given regular expression. Note
 that the regular expression should be expressed using the dotall format (where the <code>.</code> character matches any character).</p>
 <p>For example, one can create a rule with the regular expression <code>.*REVIEW.*</code> to match all comment containing "REVIEW".</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1244.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1244.html
index 3f2afcc94f4..6aba2d8a9e0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1244.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1244.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Floating point math is imprecise because of the challenges of storing such values in a binary representation. Even worse, floating point math is
 not associative; push a <code>float</code> or a <code>double</code> through a series of simple mathematical operations and the answer will be
 different based on the order of those operation because of the rounding that takes place at each step.</p>
@@ -14,7 +15,7 @@
 value and the expected value against a margin of acceptable error. Note that this does not cover all cases (<code>NaN</code> and <code>Infinity</code>
 for instance).</p>
 <p>This rule checks for the use of direct and indirect equality/inequailty tests on floats and doubles.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 float myNumber = 3.146;
 if ( myNumber == 3.146f ) { //Noncompliant. Because of floating point imprecision, this will be false
@@ -32,7 +33,7 @@ <h2>Noncompliant Code Example</h2>
 if (zeroFloat == 0) {  // Noncompliant. Computations may end up with a value close but not equal to zero.
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Since <code>NaN</code> is not equal to itself, the specific case of testing a floating point value against itself is a valid test for
 <code>NaN</code> and is therefore ignored. Though using <code>Double.isNaN</code> method should be preferred instead, as intent is more explicit.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S125.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S125.html
index 20f15bf4409..86475f084cb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S125.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S125.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Programmers should not comment out code as it bloats programs and reduces readability.</p>
 <p>Unused code should be deleted and can be retrieved from source control history if required.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1258.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1258.html
index 9f7a447ed83..6e0fb61bf11 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1258.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1258.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>Non-abstract classes and enums with non-<code>static</code>, <code>private</code> members should explicitly initialize those members, either in a
 constructor or with a default value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class A { // Noncompliant
   private int field;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class A {
   private int field;
@@ -16,7 +17,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <ul>
   <li> Class implementing a Builder Pattern (name ending with "Builder"). </li>
   <li> <a href="https://docs.oracle.com/javaee/7/tutorial/index.html">Java EE</a> class annotated with:
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S126.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S126.html
index 88f3076973c..dd23c0da1e9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S126.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S126.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>This rule applies whenever an <code>if</code> statement is followed by one or more <code>else if</code> statements; the final <code>else if</code>
 should be followed by an <code>else</code> statement.</p>
 <p>The requirement for a final <code>else</code> statement is defensive programming.</p>
 <p>The <code>else</code> statement should either take appropriate action or contain a suitable comment as to why no action is taken. This is
 consistent with the requirement to have a final <code>default</code> clause in a <code>switch</code> statement.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (x == 0) {
   doSomething();
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   doSomethingElse();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (x == 0) {
   doSomething();
@@ -21,7 +22,7 @@ <h2>Compliant Solution</h2>
   throw new IllegalStateException();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/RtYxBQ">CERT, MSC01-C.</a> - Strive for logical completeness </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/jzZGBQ">CERT, MSC57-J.</a> - Strive for logical completeness </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1264.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1264.html
index 9c6c096d3dd..aff8b404bda 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1264.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1264.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>When only the condition expression is defined in a <code>for</code> loop, and the initialization and increment expressions are missing, a
 <code>while</code> loop should be used instead to increase readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (;condition;) { /*...*/ }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 while (condition) { /*...*/ }
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S127.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S127.html
index 42889a942a2..74a7337071b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S127.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S127.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>for</code> loop stop condition should test the loop counter against an invariant value (i.e. one that is true at both the beginning and
 ending of every loop iteration). Ideally, this means that the stop condition is set to a local variable just before the loop begins.</p>
 <p>Stop conditions that are not invariant are slightly less efficient, as well as being difficult to understand and maintain, and likely lead to the
@@ -8,7 +9,7 @@
   <li> When the stop condition depend upon a method call </li>
   <li> When the stop condition depends on an object property, since such properties could change during the execution of the loop. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 0; i &lt; 10; i++) {
   ...
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (int i = 0; i &lt; 10; i++) {...}
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S128.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S128.html
index 116a09839cc..1717011e6ef 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S128.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S128.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When the execution is not explicitly terminated at the end of a switch case, it continues to execute the statements of the following case. While
 this is sometimes intentional, it often is a mistake which leads to unexpected behavior.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (myVariable) {
   case 1:
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
     break;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch (myVariable) {
   case 1:
@@ -27,7 +28,7 @@ <h2>Compliant Solution</h2>
     break;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule is relaxed in the following cases:</p>
 <pre>
 switch (myVariable) {
@@ -47,7 +48,7 @@ <h2>Exceptions</h2>
     doSomethingElse();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/484">MITRE, CWE-484</a> - Omitted Break Statement in Switch </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ldYxBQ">CERT, MSC17-C.</a> - Finish every set of statements associated with a case label with a
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1301.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1301.html
index 64a6dc2ae25..ba926e6e058 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1301.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1301.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p><code>switch</code> statements are useful when there are many different cases depending on the value of the same expression.</p>
 <p>For just one or two cases however, the code will be more readable with <code>if</code> statements.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (variable) {
   case 0:
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
     break;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (variable == 0) {
   doSomething();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1309.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1309.html
index 6eb52266077..9d1b576c647 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1309.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1309.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows you to track the usage of the <code>@SuppressWarnings</code> mechanism.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a parameter value of "unused" :</p>
 <pre>
 @SuppressWarnings("unused")
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S131.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S131.html
index 64ed316d6cd..4ed0b588fa6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S131.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S131.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The requirement for a final <code>default</code> clause is defensive programming. The clause should either take appropriate action, or contain a
 suitable comment as to why no action is taken.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (param) {  //missing default clause
   case 0:
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
     break;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch (param) {
   case 0:
@@ -37,7 +38,7 @@ <h2>Compliant Solution</h2>
     break;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>If the <code>switch</code> parameter is an <code>Enum</code> and if all the constants of this enum are used in the <code>case</code> statements,
 then no <code>default</code> clause is expected.</p>
 <p>Example:</p>
@@ -55,7 +56,7 @@ <h2>Exceptions</h2>
     break;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/478">MITRE, CWE-478</a> - Missing Default Case in Switch Statement </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/RtYxBQ">CERT, MSC01-C.</a> - Strive for logical completeness </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1310.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1310.html
index c6848dec51d..b524f5201b7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1310.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1310.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows you to track the use of the PMD suppression comment mechanism.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // NOPMD
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1312.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1312.html
index f1c228f094e..735d8d3cd11 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1312.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1312.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Regardless of the logging framework in use (logback, log4j, commons-logging, java.util.logging, …​), loggers should be:</p>
 <ul>
   <li> <code>private</code>: never be accessible outside of its parent class. If another class needs to log something, it should instantiate its own
@@ -6,15 +7,15 @@
   provided in the messages but the logger should be created at class level to prevent creating a logger along with each object. </li>
   <li> <code>final</code>: be created once and only once per class. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a default regular expression of <code>LOG(?:GER)?</code>:</p>
 <pre>
 public Logger logger = LoggerFactory.getLogger(Foo.class);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private static final Logger LOGGER = LoggerFactory.getLogger(Foo.class);
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Variables of type <code>org.apache.maven.plugin.logging.Log</code> are ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1314.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1314.html
index 1306dc844dc..a2850356e3b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1314.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1314.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Integer literals starting with a zero are octal rather than decimal values. While using octal values is fully supported, most developers do not
 have experience with them. They may not recognize octal values as such, mistaking them instead for decimal values.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int myNumber = 010; // Noncompliant. myNumber will hold 8, not 10 - was this really expected?
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int myNumber = 8;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/atYxBQ">CERT, DCL18-C.</a> - Do not begin integer constants with 0 when specifying a decimal
   value </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1315.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1315.html
index 48ffb4692a0..84742b82c4a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1315.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1315.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows you to track the use of the Checkstyle suppression comment mechanism.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // CHECKSTYLE:OFF
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
index b8f3318cdc1..3f75d6dab1c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Instantiating a <code>StringBuilder</code> or a <code>StringBuffer</code> with a character is misleading because most Java developers would expect
 the character to be the initial value of the <code>StringBuffer</code>.</p>
 <p>What actually happens is that the int representation of the character is used to determine the initial size of the <code>StringBuffer</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 StringBuffer foo = new StringBuffer('x');   //equivalent to StringBuffer foo = new StringBuffer(120);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 StringBuffer foo = new StringBuffer("x");
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
index f0356e599f5..73130e1a7b4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The purpose of the Java Collections API is to provide a well defined hierarchy of interfaces in order to hide implementation details.</p>
 <p>Implementing classes must be used to instantiate new collections, but the result of an instantiation should ideally be stored in a variable whose
 type is a Java Collection interface.</p>
@@ -7,7 +8,7 @@
   <li> is accepted as an argument to a <code>public</code> method. </li>
   <li> is exposed as a <code>public</code> member. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Employees {
   private HashSet&lt;Employee&gt; employees = new HashSet&lt;Employee&gt;();  // Noncompliant - "employees" should have type "Set" rather than "HashSet"
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Employees {
   private Set&lt;Employee&gt; employees = new HashSet&lt;Employee&gt;();      // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S134.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S134.html
index e7f227313fb..9b4717c0b77 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S134.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S134.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Nested <code>if</code>, <code>for</code>, <code>while</code>, <code>switch</code>, and <code>try</code> statements are key ingredients for making
 what’s known as "Spaghetti code".</p>
 <p>Such code is hard to read, refactor and therefore maintain.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold of 3:</p>
 <pre>
 if (condition1) {                  // Compliant - depth = 1
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S135.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S135.html
index 9329ad37209..b6e04b9d5ab 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S135.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S135.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Restricting the number of <code>break</code> and <code>continue</code> statements in a loop is done in the interest of good structured
 programming.</p>
 <p>Only one <code>break</code> or one <code>continue</code> statement is acceptable in a loop, since it facilitates optimal coding. If there is more
 than one, the code should be refactored to increase readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 1; i &lt;= 10; i++) {     // Noncompliant - 2 continue - one might be tempted to add some logic in between
   if (i % 2 == 0) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S138.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S138.html
index 137b533acaf..707652c06e8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S138.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S138.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A method that grows too large tends to aggregate too many responsibilities. Such method inevitably become harder to understand and therefore harder
 to maintain.</p>
 <p>Above a specific threshold, it is strongly advised to refactor into smaller methods which focus on well-defined tasks. Those smaller methods will
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S139.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S139.html
index e7b6c1997b7..000e9758483 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S139.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S139.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>This rule verifies that single-line comments are not located at the ends of lines of code. The main idea behind this rule is that in order to be
 really readable, trailing comments would have to be properly written and formatted (correct alignment, no interference with the visual structure of
 the code, not too long to be visible) but most often, automatic code formatters would not handle this correctly: the code would end up less readable.
 Comments are far better placed on the previous empty line of code, where they will always be visible and properly formatted.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int a1 = b + c; // This is a trailing comment that can be very very long
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // This very long comment is better placed before the line of code
 int a2 = b + c;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1444.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1444.html
index 6d733e76934..845007168cc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1444.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1444.html
@@ -1,21 +1,22 @@
+<h2>Why is this an issue?</h2>
 <p>There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a
 state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to
 <code>null</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Greeter {
   public static Foo foo = new Foo();
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Greeter {
   public static final Foo FOO = new Foo();
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/500">MITRE, CWE-500</a> - Public Static Field Not Marked Final </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/WjdGBQ">CERT OBJ10-J.</a> - Do not use public static nonfinal fields </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1448.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1448.html
index 5b47c458177..94dbdbad909 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1448.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1448.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A class that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to maintain.
 Above a specific threshold, it is strongly advised to refactor the class into smaller ones which focus on well defined topics.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1449.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1449.html
index e8c043bf34b..095135732ad 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1449.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1449.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Failure to specify a locale when calling the methods <code>toLowerCase()</code>, <code>toUpperCase()</code> or <code>format()</code> on
 <code>String</code> objects means the system default encoding will be used, possibly creating problems with international characters or number
 representations. For instance with the Turkish language, when converting the small letter 'i' to upper case, the result is capital letter 'I' with a
@@ -5,15 +6,15 @@
 <p>Case conversion without a locale may work fine in its "home" environment, but break in ways that are extremely difficult to diagnose for customers
 who use different encodings. Such bugs can be nearly, if not completely, impossible to reproduce when it’s time to fix them. For locale-sensitive
 strings, the correct locale should always be used, but <code>Locale.ROOT</code> can be used for case-insensitive ones.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 myString.toLowerCase()
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 myString.toLowerCase(Locale.TR)
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4zdGBQ">CERT, STR02-J.</a> - Specify an appropriate locale when comparing locale-dependent data
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1450.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1450.html
index c931569bc34..8eed431b4ae 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1450.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1450.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When the value of a private field is always assigned to in a class' methods before being read, then it is not being used to store class
 information. Therefore, it should become a local variable in the relevant methods to prevent any misunderstanding.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
   private int a;
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo {
 
@@ -39,6 +40,6 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise any issue on annotated field.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1451.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1451.html
index d490cb4dfff..470269a45e6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1451.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1451.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Each source file should start with a header stating file ownership and the license which must be used to distribute the application.</p>
 <p>This rule must be fed with the header text that is expected at the beginning of every file.</p>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 /*
  * SonarQube, open source software quality management tool.
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
index 694bbcefe17..0a9122d37a2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>It is highly recommended <strong>not</strong> to use wildcard types as return types. Because the type inference rules are fairly complex it is
 unlikely the user of that API will know how to use it correctly.</p>
 <p>Let’s take the example of method returning a "List&lt;? extends Animal&gt;". Is it possible on this list to add a Dog, a Cat, …​ we simply don’t
 know. And neither does the compiler, which is why it will not allow such a direct use. The use of wildcard types should be limited to method
 parameters.</p>
 <p>This rule raises an issue when a method returns a wildcard type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;? extends Animal&gt; getAnimals(){...}
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;Animal&gt; getAnimals(){...}
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1479.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1479.html
index 351a2001441..76e4d0c2096 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1479.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1479.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>When <code>switch</code> statements have large sets of <code>case</code> clauses, it is usually an attempt to map two sets of data. A real map
 structure would be more readable and maintainable, and should be used instead.</p>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule ignores <code>switch</code>es over <code>Enum</code>s and empty, fall-through cases.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html
index 6ecea883650..992330e5ba0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>If a local variable is declared but not used, it is dead code and should be removed. Doing so will improve maintainability because developers will
 not wonder what the variable is used for.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int numberOfMinutes(int hours) {
   int seconds = 0;   // seconds is never used
   return hours * 60;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int numberOfMinutes(int hours) {
   return hours * 60;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1488.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1488.html
index f564addc4cd..caf1f8de54a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1488.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1488.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Declaring a variable only to immediately return or throw it is a bad practice.</p>
 <p>Some developers argue that the practice improves code readability, because it enables them to explicitly name what is being returned. However, this
 variable is an internal implementation detail that is not exposed to the callers of the method. The method name should be sufficient for callers to
 know exactly what will be returned.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public long computeDurationInMilliseconds() {
   long duration = (((hours * 60) + minutes) * 60 + seconds ) * 1000 ;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   throw myException;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public long computeDurationInMilliseconds() {
   return (((hours * 60) + minutes) * 60 + seconds ) * 1000 ;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1541.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1541.html
index acab16da505..76b9e66da9e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1541.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1541.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The cyclomatic complexity of methods should not exceed a defined threshold.</p>
 <p>Complex code can perform poorly and will in any case be difficult to understand and therefore to maintain.</p>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>While having a large number of fields in a class may indicate that it should be split, this rule nonetheless ignores high complexity in
 <code>equals</code> and <code>hashCode</code> methods.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
index 75132e801cb..67a017fcd3f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Since the introduction of generics in Java 5, the use of generic types such as <code>List&lt;String&gt;</code> is recommended over the use of raw
 ones such as <code>List</code>. Assigning a raw type to a generic one is not type safe, and will generate a warning. The old <code>EMPTY_...</code>
 fields of the <code>Collections</code> class return raw types, whereas the newer <code>empty...()</code> methods return generic ones.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;String&gt; collection1 = Collections.EMPTY_LIST;  // Noncompliant
 Map&lt;String, String&gt; collection2 = Collections.EMPTY_MAP;  // Noncompliant
 Set&lt;String&gt; collection3 = Collections.EMPTY_SET;  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; collection1 = Collections.emptyList();
 Map&lt;String, String&gt; collection2 = Collections.emptyMap();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
index efe812258be..bf725f930ca 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>By convention, a Java class' physical location (source directories) and its logical representation (packages) should be kept in sync. Thus a Java
 file located at <code>"src/org/bar/Foo.java"</code> should have a package of <code>"org.bar"</code>.</p>
 <p>Unfortunately, this convention is not enforced by Java compilers, and nothing prevents a developer from making the "Foo.java" class part of the
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
index 6a36b17f6f3..15a06d678ff 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>There are two ways to write lambdas that contain single statement, but one is definitely more compact and readable than the other.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 x -&gt; {System.out.println(x+1);}
 (a, b) -&gt; { return a+b; }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 x -&gt; System.out.println(x+1)
 (a, b) -&gt; a+b    //For return statement, the return keyword should also be dropped
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
index ccf13a938dd..0aa8f54e30a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Before Java 8, the only way to partially support closures in Java was by using anonymous inner classes. But the syntax of anonymous classes may
 seem unwieldy and unclear.</p>
 <p>With Java 8, most uses of anonymous inner classes should be replaced by lambdas to highly increase the readability of the source code.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 myCollection.stream().map(new Mapper&lt;String,String&gt;() {
   public String map(String input) {
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 myCollection.stream().map(input -&gt; new StringBuilder(input).reverse().toString());
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1607.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1607.html
index 46ed9df247d..39cf48f93a2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1607.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1607.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When a test fails due, for example, to infrastructure issues, you might want to ignore it temporarily. But without some kind of notation about why
 the test is being ignored, it may never be reactivated. Such tests are difficult to address without comprehensive knowledge of the project, and end up
 polluting their projects.</p>
@@ -7,7 +8,7 @@
   <li> For Junit5, this rule targets the @Disabled annotation. </li>
   <li> Cases where assumeTrue(false) or assumeFalse(true) are used to skip tests are targeted as well. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Ignore  // Noncompliant
 @Test
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   Assume.assumeFalse(true); // Noncompliant
   // ...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 @Ignore("See Ticket #1234")
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
index 8d8f700b613..828fdbbd23a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>With Java 8’s "default method" feature, any abstract class without direct or inherited field should be converted into an interface. However, this
 change may not be appropriate in libraries or other applications where the class is intended to be used as an API.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public abstract class Car {
   public abstract void start(Environment c);
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface Car {
   public void start(Environment c);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
index 846fedd8fd1..0e6af4a0006 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>There are two possible syntaxes for a lambda having only one input parameter with an inferred type: with and without parentheses around that single
 parameter. The simpler syntax, without parentheses, is more compact and readable than the one with parentheses, and is therefore preferred.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 (x) -&gt; x * 2
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 x -&gt; x * 2
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
index 61c1ed4187d..0db3ee29b4d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Method/constructor references are commonly agreed to be more readable than lambdas in most situations, and are therefore preferred.</p>
 <p>However, method references are sometimes less concise than lambdas. In such cases, it might be fine to keep the lambda if it is better for
 readability. This choice is ultimately up to the programmer. Therefore, this rule only raises issues on lambda functions that could be replaced by
@@ -6,7 +7,7 @@
 <code>casts</code> can be replaced with <code>SomeClass.class::cast</code> and <code>instanceof</code> can be replaced with
 <code>SomeClass.class::isInstance</code>.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class A {
   void process(List&lt;A&gt; list) {
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class A {
   void process(List&lt;A&gt; list) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
index e2cb7c3d5be..fa657247342 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When all the keys of a Map are values from the same enum, the <code>Map</code> can be replaced with an <code>EnumMap</code>, which can be much more
 efficient than other sets because the underlying data structure is a simple array.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1641.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1641.html
index 28823abf3e2..7297f8594f3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1641.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1641.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When all the elements in a Set are values from the same enum, the Set can be replaced with an EnumSet, which can be much more efficient than other
 sets because the underlying data structure is a simple bitmap.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1643.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1643.html
index 755bc4fb8ec..c739f4a72df 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1643.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1643.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>Strings are immutable objects, so concatenation doesn’t simply add the new String to the end of the existing string. Instead, in each loop
 iteration, the first String is converted to an intermediate object type, the second string is appended, and then the intermediate object is converted
 back to a String. Further, performance of these intermediate operations degrades as the String gets longer. Therefore, the use of StringBuilder is
 preferred.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String str = "";
 for (int i = 0; i &lt; arrayOfStrings.length ; ++i) {
   str = str + arrayOfStrings[i];
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 StringBuilder bld = new StringBuilder();
   for (int i = 0; i &lt; arrayOfStrings.length; ++i) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1656.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1656.html
index 9b186a89b44..73096256d18 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1656.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1656.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>There is no reason to re-assign a variable to itself. Either this statement is redundant and should be removed, or the re-assignment is a mistake
 and some other value or variable was intended for the assignment instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void setName(String name) {
   name = name;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void setName(String name) {
   this.name = name;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1659.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1659.html
index 0b29910721e..f2f62c42fbe 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1659.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1659.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Declaring multiple variables on one line is difficult to read.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass {
 
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
 
@@ -23,7 +24,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/YTZGBQ">CERT, DCL52-J.</a> - Do not declare more than one variable per declaration </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/EtcxBQ">CERT, DCL04-C.</a> - Do not declare more than one variable per declaration </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1694.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1694.html
index 86d7e6d51cd..73eb2f48771 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1694.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1694.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>The purpose of an abstract class is to provide some heritable behaviors while also defining methods which must be implemented by sub-classes.</p>
 <p>A class with no abstract methods that was made abstract purely to prevent instantiation should be converted to a concrete class (i.e. remove the
 <code>abstract</code> keyword) with a private constructor.</p>
 <p>A class with only abstract methods and no inheritable behavior should be converted to an interface.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public abstract class Animal {  // Noncompliant; should be an interface
   abstract void move();
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface Animal {
   void move();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1695.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1695.html
index d4058387389..2d6d90b6b8d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1695.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1695.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>NullPointerException</code> should indicate that a <code>null</code> value was unexpectedly encountered. Good programming practice dictates
 that code is structured to avoid NPE’s.</p>
 <p>Explicitly throwing <code>NullPointerException</code> forces a method’s callers to explicitly catch it, rather than coding to avoid it. Further, it
@@ -5,13 +6,13 @@
 throw an NPE.</p>
 <p>If an NPE is being thrown to indicate that a parameter to the method should not have been null, use the <code>@NotNull</code> annotation
 instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething (String aString) throws NullPointerException {
      throw new NullPointerException();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething (@NotNull String aString) {
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1696.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1696.html
index 2550fa1a995..52ba30d6ee9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1696.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1696.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>NullPointerException</code> should be avoided, not caught. Any situation in which <code>NullPointerException</code> is explicitly caught can
 easily be converted to a <code>null</code> test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of
 the conditional.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int lengthPlus(String str) {
   int len = 2;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   return len;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int lengthPlus(String str) {
   int len = 2;
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   return len;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/395">MITRE, CWE-395</a> - Use of NullPointerException Catch to Detect NULL Pointer Dereference
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1698.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1698.html
index a8eabd690a3..4ee853bd4dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1698.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1698.html
@@ -1,22 +1,23 @@
+<h2>Why is this an issue?</h2>
 <p>It is equivalent to use the equality <code>==</code> operator and the <code>equals</code> method to compare two objects if the <code>equals</code>
 method inherited from <code>Object</code> has not been overridden. In this case both checks compare the object references.</p>
 <p>But as soon as <code>equals</code> is overridden, two objects not having the same reference but having the same value can be equal. This rule spots
 suspicious uses of <code>==</code> and <code>!=</code> operators on objects whose <code>equals</code> methods are overridden.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String firstName = getFirstName(); // String overrides equals
 String lastName = getLastName();
 
 if (firstName == lastName) { ... }; // Non-compliant; false even if the strings have the same value
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String firstName = getFirstName();
 String lastName = getLastName();
 
 if (firstName != null &amp;&amp; firstName.equals(lastName)) { ... };
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Comparing two instances of the <code>Class</code> object will not raise an issue:</p>
 <pre>
 Class c;
@@ -51,7 +52,7 @@ <h2>Exceptions</h2>
  }
 </pre>
 <p>Comparing with <code>java.lang.String</code> and boxed types <code>java.lang.Integer</code>, …​ will not raise an issue.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> {rule:java:S4973} - Strings and Boxed types should be compared using "equals()" </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/595">MITRE, CWE-595</a> - Comparison of Object References Instead of Object Contents </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1699.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1699.html
index 6a62e739b76..62e221e2bf9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1699.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1699.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Calling an overridable method from a constructor could result in failures or strange behaviors when instantiating a subclass which overrides the
 method.</p>
 <p>For example:</p>
@@ -7,7 +8,7 @@
   <li> If the behavior of the child class method depends on fields that are initialized in the child class constructor, unexpected behavior (like a
   <code>NullPointerException</code>) can result, because the fields aren’t initialized yet. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Parent {
 
@@ -35,7 +36,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/8zZGBQ">CERT, MET05-J.</a> - Ensure that constructors do not call overridable methods </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6ns-BQ">CERT, OOP50-CPP.</a> - Do not invoke virtual functions from constructors or destructors
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1700.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1700.html
index ac3bc04d07c..153e4f81e6f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1700.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1700.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>It’s confusing to have a class member with the same name (case differences aside) as its enclosing class. This is particularly so when you consider
 the common practice of naming a class instance for the class itself.</p>
 <p>Best practice dictates that any field or member with the same name as the enclosing class be renamed to be more descriptive of the particular
 aspect of the class it represents or holds.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
   private String foo;
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 Foo foo = new Foo();
 foo.getFoo() // what does this return?
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo {
   private String name;
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
 Foo foo = new Foo();
 foo.getName()
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When the type of the field is the containing class and that field is static, no issue is raised to allow singletons named like the type.</p>
 <pre>
 public class Foo {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
index 57ee36e0f04..f7d87a8907b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Before Java 8 if you needed to use multiple instances of the same annotation, they had to be wrapped in a container annotation. With Java 8, that’s
 no longer necessary, allowing for cleaner, more readable code.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @SomeAnnotations({  // Noncompliant
   @SomeAnnotation(..a..),
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @SomeAnnotation(..a..)
 @SomeAnnotation(..b..)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1711.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1711.html
index 339ca932aeb..0535845ff8d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1711.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1711.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Just as there is little justification for writing your own String class, there is no good reason to re-define one of the existing, standard
 functional interfaces.</p>
 <p>Doing so may seem tempting, since it would allow you to specify a little extra context with the name. But in the long run, it will be a source of
 confusion, because maintenance programmers will wonder what is different between the custom functional interface and the standard one.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @FunctionalInterface
 public interface MyInterface { // Noncompliant
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @FunctionalInterface
 public interface ExtendedBooleanSupplier extends BooleanSupplier { // Compliant, extends java.util.function.BooleanSupplier
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1751.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1751.html
index 9d083e9987a..8c7e94c268c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1751.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1751.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>A loop with at most one iteration is equivalent to the use of an <code>if</code> statement to conditionally execute one piece of code. No developer
 expects to find such a use of a loop statement. If the initial intention of the author was really to conditionally execute one piece of code, an
 <code>if</code> statement should be used instead.</p>
 <p>At worst that was not the initial intention of the author and so the body of the loop should be fixed to use the nested <code>return</code>,
 <code>break</code> or <code>throw</code> statements in a more appropriate way.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 0; i &lt; 10; i++) { // noncompliant, loop only executes once
   printf("i is %d", i);
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (int i = 0; i &lt; 10; i++) {
   printf("i is %d", i);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1764.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1764.html
index 6a82846bf7a..e28f663bead 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1764.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1764.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Using the same value on either side of a binary operator is almost always a mistake. In the case of logical operators, it is either a copy/paste
 error and therefore a bug, or it is simply wasted code, and should be simplified. In the case of bitwise operators and most binary mathematical
 operators, having the same value on both sides of an operator yields predictable results, and should be simplified.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if ( a == a ) { // always true
   doZ();
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
 
 c.equals(c); //always true
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <ul>
   <li> This rule ignores <code>*</code>, <code>+</code>, and <code>=</code>. </li>
   <li> The specific case of testing a floating point value against itself is a valid test for <code>NaN</code> and is therefore ignored. </li>
@@ -36,7 +37,7 @@ <h2>Exceptions</h2>
 int i = 1 &lt;&lt; 1; // Compliant
 int j = a &lt;&lt; a; // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1774.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1774.html
index a3dc2037548..2992f0272ce 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1774.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1774.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>While the ternary operator is pleasingly compact, its use can make code more difficult to read. It should therefore be avoided in favor of the more
 verbose <code>if</code>/<code>else</code> structure.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 System.out.println(i&gt;10?"yes":"no");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (i &gt; 10) {
   System.out.println(("yes");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1820.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1820.html
index 0f67a7a5320..3e1c438afe5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1820.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1820.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A class that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to maintain, and
 having a lot of fields is an indication that a class has grown too large.</p>
 <p>Above a specific threshold, it is strongly advised to refactor the class into smaller ones which focus on well defined topics.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1821.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1821.html
index cb41fb23498..fc578f8460f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1821.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1821.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Nested <code>switch</code> structures are difficult to understand because you can easily confuse the cases of an inner <code>switch</code> as
 belonging to an outer statement or expression. Therefore nested <code>switch</code> statements and expressions should be avoided.</p>
 <p>Specifically, you should structure your code to avoid the need for nested <code>switch</code> statements or expressions, but if you cannot, then
 consider moving the inner <code>switch</code> to another method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void foo(int n, int m) {
   switch (n) {
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void foo(int n, int m) {
   switch (n) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
index ae76c153b4f..6f7884be272 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>From the Java API documentation:</p>
 <blockquote>
   <p><code>Condition</code> factors out the <code>Object</code> monitor methods (<code>wait</code>, <code>notify</code> and <code>notifyAll</code>)
@@ -7,14 +8,14 @@
 </blockquote>
 <p>The purpose of implementing the <code>Condition</code> interface is to gain access to its more nuanced <code>await</code> methods. Therefore,
 calling the method <code>Object.wait(...)</code> on a class implementing the <code>Condition</code> interface is silly and confusing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 final Lock lock = new ReentrantLock();
 final Condition notFull  = lock.newCondition();
 ...
 notFull.wait();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 final Lock lock = new ReentrantLock();
 final Condition notFull  = lock.newCondition();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1845.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1845.html
index bff20abe4c5..dcfd5787a13 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1845.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1845.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is
 confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field
 with exactly the same name and visibility.</p>
@@ -6,7 +7,7 @@
 <p>Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the
 case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be
 disruptive to callers. Therefore renaming the member is the recommended action.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Car{
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
   public void driveFast(){...} //Huh?
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Car{
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
index 14ffbd505b1..b2869aff9c1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Calling <code>Iterator.hasNext()</code> is not supposed to have any side effects, and therefore should not change the state of the iterator.
 <code>Iterator.next()</code> advances the iterator by one item. So calling it inside <code>Iterator.hasNext()</code>, breaks the
 <code>hasNext()</code> contract, and will lead to unexpected behavior in production.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class FibonacciIterator implements Iterator&lt;Integer&gt;{
 ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1854.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1854.html
index eb4f39f7bd1..c4f96d3e1de 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1854.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1854.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>A dead store happens when a local variable is assigned a value that is not read by any subsequent instruction. Calculating or retrieving a value
 only to then overwrite it or throw it away, could indicate a serious error in the code. Even if it’s not an error, it is at best a waste of resources.
 Therefore all calculated values should be used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 i = a + b; // Noncompliant; calculation result not used before value is overwritten
 i = compute();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 i = a + b;
 i += compute();
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule ignores initializations to -1, 0, 1, <code>null</code>, <code>true</code>, <code>false</code> and <code>""</code>.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/563">MITRE, CWE-563</a> - Assignment to Variable without Use ('Unused Variable') </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/39UxBQ">CERT, MSC13-C.</a> - Detect and remove unused values </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1858.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1858.html
index 7789b450e42..6d34b8c2ff1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1858.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1858.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Invoking a method designed to return a string representation of an object which is already a string is a waste of keystrokes. This redundant
 construction may be optimized by the compiler, but will be confusing in the meantime.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String message = "hello world";
 System.out.println(message.toString()); // Noncompliant;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String message = "hello world";
 System.out.println(message);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
index 2ec0f51dcdd..eab93a229dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Objects which are pooled and potentially reused should not be used for synchronization. If they are, it can cause unrelated threads to deadlock
 with unhelpful stacktraces. Specifically, <code>String</code> literals, and boxed primitives such as Integers should not be used as lock objects
 because they are pooled and reused. The story is even worse for <code>Boolean</code> objects, because there could possibly be only two instances of
@@ -14,7 +15,7 @@
   <li> The implementation classes of the collection factories in java.util: List.of, List.copyOf, Set.of, Set.copyOf, Map.of, Map.copyOf,
   Map.ofEntries, and Map.entry. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private static final Boolean bLock = Boolean.FALSE;
 private static final Integer iLock = Integer.valueOf(0);
@@ -36,7 +37,7 @@ <h2>Noncompliant Code Example</h2>
     // ...
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private static final Object lock1 = new Object();
 private static final Object lock2 = new Object();
@@ -58,7 +59,7 @@ <h2>Compliant Solution</h2>
     // ...
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/1zdGBQ">CERT, LCK01-J.</a> - Do not synchronize on objects that may be reused </li>
   <li> <a href="https://openjdk.java.net/jeps/390">JEP-390.</a> - JEP 390: Warnings for Value-Based Classes </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1862.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1862.html
index be0b892d4c4..e342c1dd3ca 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1862.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1862.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>A chain of <code>if</code>/<code>else if</code> statements is evaluated from top to bottom. At most, only one branch will be executed: the first
 one with a condition that evaluates to <code>true</code>.</p>
 <p>Therefore, duplicating a condition automatically leads to dead code. Usually, this is due to a copy/paste error. At best, it’s simply dead code and
 at worst, it’s a bug that is likely to induce further bugs as the code is maintained, and obviously it could lead to unexpected behavior.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (param == 1)
   openWindow();
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   moveWindowToTheBackground();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (param == 1)
   openWindow();
@@ -22,7 +23,7 @@ <h2>Compliant Solution</h2>
   moveWindowToTheBackground();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5dUxBQ">CERT, MSC12-C.</a> - Detect and remove code that has no effect or is never executed
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1871.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1871.html
index ee3b397044c..8c8c4b46163 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1871.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1871.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Having two <code>cases</code> in a <code>switch</code> statement or two branches in an <code>if</code> chain with the same implementation is at
 best duplicate code, and at worst a coding error. If the same logic is truly needed for both instances, then in an <code>if</code> chain they should
 be combined, or for a <code>switch</code>, one should fall through to the other.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (i) {
   case 1:
@@ -34,7 +35,7 @@ <h2>Noncompliant Code Example</h2>
   doTheRest();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Blocks in an <code>if</code> chain that contain a single line of code are ignored, as are blocks in a <code>switch</code> statement that contain a
 single line of code with or without a following <code>break</code>.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1872.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1872.html
index 98721f0d213..3f6e761d263 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1872.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1872.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>There is no requirement that class names be unique, only that they be unique within a package. Therefore trying to determine an object’s type based
 on its class name is an exercise fraught with danger. One of those dangers is that a malicious user will send objects of the same name as the trusted
 class and thereby gain trusted access.</p>
 <p>Instead, the <code>instanceof</code> operator or the <code>Class.isAssignableFrom()</code> method should be used to check the object’s underlying
 type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 package computer;
 class Pear extends Laptop { ... }
@@ -28,7 +29,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Store {
 
@@ -47,7 +48,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/486">MITRE, CWE-486</a> - Comparison of Classes by Name </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/eDdGBQ">CERT, OBJ09-J.</a> - Compare classes and not class names </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1874.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1874.html
index b799d45ac47..43a9fcce07a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1874.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1874.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Once deprecated, classes, and interfaces, and their members should be avoided, rather than used, inherited or extended. Deprecation is a warning
 that the class or interface has been superseded, and will eventually be removed. The deprecation period allows you to make a smooth transition away
 from the aging, soon-to-be-retired technology.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 /**
  * @deprecated  As of release 1.3, replaced by {@link #Fee}
@@ -31,7 +32,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/477">MITRE, CWE-477</a> - Use of Obsolete Functions </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6TdGBQ">CERT, MET02-J.</a> - Do not use deprecated or obsolete classes or methods </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1905.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1905.html
index 18fe592c497..adfc63d4934 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1905.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1905.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Unnecessary casting expressions make the code harder to read and understand.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void example() {
   for (Foo obj : (List&lt;Foo&gt;) getFoos()) {  // Noncompliant; cast unnecessary because List&lt;Foo&gt; is what's returned
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   return this.foos;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void example() {
   for (Foo obj : getFoos()) {
@@ -23,7 +24,7 @@ <h2>Compliant Solution</h2>
   return this.foos;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Casting may be required to distinguish the method to call in the case of overloading:</p>
 <pre>
 class A {}
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1939.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1939.html
index 97833e741cb..8a3b6c97632 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1939.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1939.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>All classes extend <code>Object</code> implicitly. Doing so explicitly is redundant.</p>
 <p>Further, declaring the implementation of an interface <em>and</em> one if its parents is also redundant. If you implement the interface, you also
 implicitly implement its parents and there’s no need to do so explicitly.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public interface MyFace {
   // ...
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface MyFace {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1940.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1940.html
index f7979ec2c50..c54639d41b2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1940.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1940.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>It is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if ( !(a == 2)) { ...}  // Noncompliant
 boolean b = !(i &lt; 10);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (a != 2) { ...}
 boolean b = (i &gt;= 10);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1941.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1941.html
index 43e9f079bdf..2759b82e68d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1941.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1941.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>For the sake of clarity, variables should be declared as close to where they’re used as possible. This is particularly true when considering
 methods that contain early returns and the potential to throw exceptions. In these cases, it is not only pointless, but also confusing to declare a
 variable that may never be used because conditions for an early return are met first.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public boolean isConditionMet(int a, int b) {
   int difference = a - b;
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   return false;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean isConditionMet(int a, int b) {
   int difference = a - b;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1942.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1942.html
index 918e01ddf2b..146abdb8674 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1942.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1942.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Java’s <code>import</code> mechanism allows the use of simple class names. Therefore, using a class' fully qualified name in a file that
 <code>import</code>s the class is redundant and confusing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import java.util.List;
 import java.sql.Timestamp;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
 java.util.List&lt;String&gt; myList;  // Noncompliant
 java.sql.Timestamp tStamp; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import java.util.List;
 import java.sql.Timestamp;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1943.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1943.html
index cfbb0eec312..315057448cf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1943.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1943.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Using classes and methods that rely on the default system encoding can result in code that works fine in its "home" environment. But that code may
 break for customers who use different encodings in ways that are extremely difficult to diagnose and nearly, if not completely, impossible to
 reproduce when it’s time to fix them.</p>
@@ -64,7 +65,7 @@
       <li> <code>FileUtils.writeStringToFile(File, String)</code> </li>
     </ul>  </li>
 </ul>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/pzdGBQ">CERT, STR04-J.</a> - Use compatible character encodings when communicating string data
   between JVMs </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
index 6744e3be09a..0cf082d5e09 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Fields in a <code>Serializable</code> class must themselves be either <code>Serializable</code> or <code>transient</code> even if the class is
 never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly
 <code>Serializable</code> object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In
@@ -5,7 +6,7 @@
 <p>This rule raises an issue on non-<code>Serializable</code> fields, and on collection fields when they are not <code>private</code> (because they
 could be assigned non-<code>Serializable</code> values externally), and when they are assigned non-<code>Serializable</code> types within the
 class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Address {
   //...
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   private Address address;  // Noncompliant; Address isn't serializable
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Address implements Serializable {
   private static final long serialVersionUID = 2405172041950251807L;
@@ -31,7 +32,7 @@ <h2>Compliant Solution</h2>
   private Address address;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The alternative to making all members <code>serializable</code> or <code>transient</code> is to implement special methods which take on the
 responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:</p>
 <pre>
@@ -40,7 +41,7 @@ <h2>Exceptions</h2>
  private void readObject(java.io.ObjectInputStream in)
      throws IOException, ClassNotFoundException;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/594">MITRE, CWE-594</a> - Saving Unserializable Objects to Disk </li>
   <li> <a href="https://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html">Oracle Java 6, Serializable</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
index 2e4d429bcb2..a2944ca3f42 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Even though the signatures for methods in a servlet include <code>throws IOException, ServletException</code>, it’s a bad idea to let such
 exceptions be thrown. Failure to catch exceptions in a servlet could leave a system in a vulnerable state, possibly resulting in denial-of-service
 attacks, or the exposure of sensitive information because when a servlet throws an exception, the servlet container typically sends debugging
 information back to the user. And that information could be very valuable to an attacker.</p>
 <p>This rule checks all exceptions in methods named "do*" are explicitly handled in servlet classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws IOException, ServletException {
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws IOException, ServletException {
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1994.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1994.html
index 04501727e53..71a819056e8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1994.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1994.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>It can be extremely confusing when a <code>for</code> loop’s counter is incremented outside of its increment clause. In such cases, the increment
 should be moved to the loop’s increment clause if at all possible.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (i = 0; i &lt; 10; j++) { // Noncompliant
   // ...
   i++;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (i = 0; i &lt; 10; i++, j++) {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1996.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1996.html
index 14151d57dbf..902972ee261 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1996.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1996.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to maintain. This
 is doubly true for a file with multiple top-level classes and interfaces. It is strongly advised to divide the file into one top-level class or
 interface per file.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2039.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2039.html
index 74f95314b7f..9c3c35f766e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2039.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2039.html
@@ -1,6 +1,8 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
+<h2>Why is this an issue?</h2>
 <p>Failing to explicitly declare the visibility of a member variable could result it in having a visibility you don’t expect, and potentially leave it
 open to unexpected modification by other classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Ball {
     String color="red";  // Noncompliant
@@ -10,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   int a;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Ball {
     private String color="red";  // Compliant
@@ -20,7 +22,7 @@ <h2>Compliant Solution</h2>
   private int a;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Members annotated with <code>@VisibleForTesting</code> annotation are ignored, as it indicates that visibility has been purposely relaxed to make
 the code testable.</p>
 <pre>
@@ -29,6 +31,4 @@ <h2>Exceptions</h2>
   Logger logger; // Compliant
 }
 </pre>
-<h2>Deprecated</h2>
-<p>This rule is deprecated, and will eventually be removed.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2047.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2047.html
index 6d1ed7c7ed9..7c1350b1ad0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2047.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2047.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Well-named functions can allow the users of your code to understand at a glance what to expect from the function - even before reading the
 documentation. Toward that end, methods returning a boolean should have names that start with "is" or "has" rather than with "get".</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public boolean getFoo() { // Noncompliant
   // ...
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean isFoo() {
   // ...
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   // ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Overriding methods are excluded.</p>
 <pre>
 @Override
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2053.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2053.html
index f02d36bd973..af70c105723 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2053.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2053.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In cryptography, a "salt" is an extra piece of data which is included when hashing a password. This makes <code>rainbow-table attacks</code> more
 difficult. Using a cryptographic hash function without an unpredictable salt increases the likelihood that an attacker could successfully find the
 hash value in databases of precomputed hashes (called <code>rainbow-tables</code>).</p>
@@ -9,7 +10,7 @@ <h2>Recommended Secure Coding Practices</h2>
   <li> Use hashing functions generating their own secure salt or generate a secure random value of at least 16 bytes. </li>
   <li> The salt should be unique by user password. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>Below, the hashed password use a predictable salt:</p>
 <pre>
 byte[] salt = "notrandom".getBytes();
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
 PBEParameterSpec cipherSpec = new PBEParameterSpec(salt, 10000); // Noncompliant, predictable salt
 PBEKeySpec spec = new PBEKeySpec(chars, salt, 10000, 256); // Noncompliant, predictable salt
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Use <code>java.security.SecureRandom</code> to generate an unpredictable salt:</p>
 <pre>
 SecureRandom random = new SecureRandom();
@@ -27,7 +28,7 @@ <h2>Compliant Solution</h2>
 PBEParameterSpec cipherSpec = new PBEParameterSpec(salt, 10000); // Compliant
 PBEKeySpec spec = new PBEKeySpec(chars, salt, 10000, 256); // Compliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
index 8b3f95816a5..66c20ae8a49 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>When a <code>Serializable</code> object has a non-serializable ancestor in its inheritance chain, object deserialization (re-instantiating the
 object from file) starts at the first non-serializable class, and proceeds down the chain, adding the properties of each subsequent child class, until
 the final object has been instantiated.</p>
 <p>In order to create the non-serializable ancestor, its no-argument constructor is called. Therefore the non-serializable ancestor of a
 <code>Serializable</code> class must have a no-arg constructor. Otherwise the class is <code>Serializable</code> but not deserializable.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit {
   private Season ripe;
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
   public String getVarity() {...}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit {
   private Season ripe;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2057.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2057.html
index 3b2ff7eabac..52c2d3217f4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2057.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2057.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>serialVersionUID</code> field is strongly recommended in all <code>Serializable</code> classes. If you do not provide one, one will be
 calculated for you by the compiler. The danger in not explicitly choosing the value is that when the class changes, the compiler will generate an
 entirely new id, and you will be suddenly unable to deserialize (read from file) objects that were serialized with the previous version of the
 class.</p>
 <p><code>serialVersionUID</code>'s should be declared with all of these modifiers: <code>static final long</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Raspberry extends Fruit  // Noncompliant; no serialVersionUID.
         implements Serializable {
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
         implements Serializable {
   private final int serialVersionUID = 1; // Noncompliant; not static &amp; int rather than long
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Raspberry extends Fruit
         implements Serializable {
@@ -30,10 +31,10 @@ <h2>Compliant Solution</h2>
   public String getVarity() {...}
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Records, Swing and AWT classes, <code>abstract</code> classes, <code>Throwable</code> and its subclasses (<code>Exception</code>s and
 <code>Error</code>s), and classes marked with <code>@SuppressWarnings("serial")</code> are ignored.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ajdGBQ">CERT, SER00-J.</a> - Enable serialization compatibility during class evolution </li>
   <li> <a href="https://docs.oracle.com/en/java/javase/16/docs/specs/serialization/serial-arch.html#serialization-of-records">Record Serialization</a>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2059.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2059.html
index e6734e513dd..4d6576ec461 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2059.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2059.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Serializing a non-<code>static</code> inner class will result in an attempt at serializing the outer class as well. If the outer class is actually
 serializable, then the serialization will succeed but possibly write out far more data than was intended.</p>
 <p>Making the inner class <code>static</code> (i.e. "nested") avoids this problem, therefore inner classes should be <code>static</code> if possible.
@@ -6,7 +7,7 @@
   <li> an inner class can only be instantiated within the context of an instance of the outer class. </li>
   <li> a nested (<code>static</code>) class can be instantiated independently of the outer class. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Raspberry implements Serializable {
   // ...
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Raspberry implements Serializable {
   // ...
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ZTdGBQ">CERT, SER05-J.</a> - Do not serialize instances of inner classes </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
index d8312e3952c..34287dc0e0c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>An <code>Externalizable</code> class is one which handles its own <code>Serialization</code> and deserialization. During deserialization, the first
 step in the process is a default instantiation using the class' no-argument constructor. Therefore an <code>Externalizable</code> class without a
 no-arg constructor cannot be deserialized.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Tomato implements Externalizable {  // Noncompliant; no no-arg constructor
 
   public Tomato (String color, int weight) { ... }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Tomato implements Externalizable {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2061.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2061.html
index 98e3444df7e..20546a7173d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2061.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2061.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Writers of <code>Serializable</code> classes can choose to let Java’s automatic mechanisms handle serialization and deserialization, or they can
 choose to handle it themselves by implementing specific methods. However, if the signatures of those methods are not exactly what is expected, they
 will be ignored and the default serialization mechanisms will kick back in.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Watermelon implements Serializable {
   // ...
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   {...}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Watermelon implements Serializable {
   // ...
@@ -43,7 +44,7 @@ <h2>Compliant Solution</h2>
   private Object writeReplace() throws ObjectStreamException
   {...}
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/WTdGBQ">CERT, SER01-J.</a> - Do not deviate from the proper signatures of serialization methods
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2062.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2062.html
index f91ba5c241e..ae42c69c68b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2062.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2062.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>readResolve()</code> method allows final tweaks to the state of an object during deserialization. Non-final classes which implement
 <code>readResolve()</code>, should not set its visibility to <code>private</code> since it will then be unavailable to child classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit implements Serializable {
   private static final long serialVersionUID = 1;
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit implements Serializable {
   private static final long serialVersionUID = 1;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2063.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2063.html
index 42ee7126d26..c0276339154 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2063.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2063.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>A non-serializable <code>Comparator</code> can prevent an otherwise-<code>Serializable</code> ordered collection from being serializable. Since the
 overhead to make a <code>Comparator</code> serializable is usually low, doing so can be considered good defensive programming.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class FruitComparator implements Comparator&lt;Fruit&gt; {  // Noncompliant
   int compare(Fruit f1, Fruit f2) {...}
   boolean equals(Object obj) {...}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class FruitComparator implements Comparator&lt;Fruit&gt;, Serializable {
   private static final long serialVersionUID = 1;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2065.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2065.html
index fba8a2f02ab..9733c1434a9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2065.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2065.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p><code>transient</code> is used to mark fields in a <code>Serializable</code> class which will not be written out to file (or stream). In a class
 that does not implement <code>Serializable</code>, this modifier is simply wasted keystrokes, and should be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Vegetable {  // does not implement Serializable
   private transient Season ripe;  // Noncompliant
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Vegetable {
   private Season ripe;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2066.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2066.html
index 9bf5f301d4d..c2c13dd589f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2066.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2066.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Serializing a non-<code>static</code> inner class will result in an attempt at serializing the outer class as well. If the outer class is not
 serializable, then serialization will fail, resulting in a runtime error.</p>
 <p>Making the inner class <code>static</code> (i.e. "nested") avoids this problem, therefore inner classes should be <code>static</code> if possible.
@@ -6,7 +7,7 @@
   <li> an inner class can only be instantiated within the context of an instance of the outer class. </li>
   <li> a nested (<code>static</code>) class can be instantiated independently of the outer class. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Pomegranate {
   // ...
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Pomegranate {
   // ...
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ZTdGBQ">CERT SER05-J.</a> - Do not serialize instances of inner classes </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2093.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2093.html
index 4accafda1af..fb969b8c398 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2093.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2093.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Java 7 introduced the try-with-resources statement, which guarantees that the resource in question will be closed. Since the new syntax is closer
 to bullet-proof, it should be preferred over the older <code>try</code>/<code>catch</code>/<code>finally</code> version.</p>
 <p>This rule checks that <code>close</code>-able resources are opened in a try-with-resources statement.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 FileReader fr = null;
 BufferedReader br = null;
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try (
     FileReader fr = new FileReader(fileName);
@@ -42,7 +43,7 @@ <h2>Compliant Solution</h2>
 }
 catch (...) {}
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6DZGBQ">CERT, ERR54-J.</a> - Use a try-with-resources statement to safely handle closeable
   resources </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2094.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2094.html
index aa66446be34..460c0a00f85 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2094.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2094.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>There is no good excuse for an empty class. If it’s being used simply as a common extension point, it should be replaced with an
 <code>interface</code>. If it was stubbed in as a placeholder for future development it should be fleshed-out. In any other case, it should be
 eliminated.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Nothing {  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface Nothing {
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Empty classes can be used as marker types (for Spring for instance), therefore empty classes that are annotated will be ignored.</p>
 <pre>
 @Configuration
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2095.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2095.html
index 6b40ac7de02..3500c1323f7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2095.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2095.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Connections, streams, files, and other classes that implement the <code>Closeable</code> interface or its super-interface,
 <code>AutoCloseable</code>, needs to be closed after use. Further, that <code>close</code> call must be made in a <code>finally</code> block otherwise
 an exception could keep the call from being made. Preferably, when class implements <code>AutoCloseable</code>, resource should be created using
 "try-with-resources" pattern and will be closed automatically.</p>
 <p>Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application
 is on to their knees.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private void readTheFile() throws IOException {
   Path path = Paths.get(this.fileName);
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private void readTheFile(String fileName) throws IOException {
     Path path = Paths.get(fileName);
@@ -57,7 +58,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Instances of the following classes are ignored by this rule because <code>close</code> has no effect:</p>
 <ul>
   <li> <code>java.io.ByteArrayOutputStream</code> </li>
@@ -77,7 +78,7 @@ <h2>Exceptions</h2>
   //...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/459">MITRE, CWE-459</a> - Incomplete Cleanup </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/772">MITRE, CWE-772</a> - Missing Release of Resource after Effective Lifetime </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2096.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2096.html
index 944d95ffdf8..b69d2e0e144 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2096.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2096.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no reason for a <code>main</code> method to <code>throw</code> anything. After all, what’s going to catch it?</p>
 <p>Instead, the method should itself gracefully handle any exceptions that may bubble up to it, attach as much contextual information as possible, and
 perform whatever logging or user communication is necessary, and <code>exit</code> with a non-zero (i.e. non-success) exit code if necessary.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static void main(String args[]) throws Exception { // Noncompliant
   doSomething();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static void main(String args[]) {
  try {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2097.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2097.html
index a12d2473a67..09a8d4db4d4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2097.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2097.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Because the <code>equals</code> method takes a generic <code>Object</code> as a parameter, any type of object may be passed to it. The method
 should not assume it will only be used to test objects of its class type. It must instead check the parameter’s type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public boolean equals(Object obj) { // Noncompliant
   MyClass mc = (MyClass)obj;
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean equals(Object obj) {
   if (obj == null)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2109.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2109.html
index a1743f0f561..7e4d7e41cbc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2109.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2109.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The writer of an annotation can set one of three retention policies for it:</p>
 <ul>
   <li> <code>RetentionPolicy.SOURCE</code> - these annotations are dropped during compilation, E.G. <code>@Override</code>,
@@ -9,7 +10,7 @@
 <p>Only annotations that have been given a <code>RUNTIME</code> retention policy will be available to reflection. Testing for annotations with any
 other retention policy is simply an error, since the test will always return false.</p>
 <p>This rule checks that reflection is not used to detect annotations that do not have <code>RUNTIME</code> retention.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Method m = String.class.getMethod("getBytes", new Class[] {int.class,
 int.class, byte[].class, int.class});
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2110.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2110.html
index 56baf381ae6..a900b05841d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2110.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2110.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Whether the valid value ranges for <code>Date</code> fields start with 0 or 1 varies by field. For instance, month starts at 0, and day of month
 starts at 1. Enter a date value that goes past the end of the valid range, and the date will roll without error or exception. For instance, enter 12
 for month, and you’ll get January of the following year.</p>
@@ -38,7 +39,7 @@
   </tbody>
 </table>
 <p>Note that this rule does not check for invalid leap years, leap seconds (second = 61), or invalid uses of the 31st day of the month.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Date d = new Date();
 d.setDate(25);
@@ -50,7 +51,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Date d = new Date();
 d.setDate(25);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
index a346f432b3d..bf1486fc7f6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Because of floating point imprecision, you’re unlikely to get the value you expect from the <code>BigDecimal(double)</code> constructor.</p>
 <p>From <a href="http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#BigDecimal(double)">the JavaDocs</a>:</p>
 <blockquote>
@@ -9,21 +10,21 @@
 </blockquote>
 <p>Instead, you should use <code>BigDecimal.valueOf</code>, which uses a string under the covers to eliminate floating point rounding errors, or the
 constructor that takes a <code>String</code> argument.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 double d = 1.1;
 
 BigDecimal bd1 = new BigDecimal(d); // Noncompliant; see comment above
 BigDecimal bd2 = new BigDecimal(1.1); // Noncompliant; same result
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 double d = 1.1;
 
 BigDecimal bd1 = BigDecimal.valueOf(d);
 BigDecimal bd2 = new BigDecimal("1.1"); // using String constructor will result in precise value
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/kzdGBQ">CERT, NUM10-J.</a> - Do not construct BigDecimal objects from floating-point literals
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
index 90d040f014d..73c609cd7ad 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>equals</code> and <code>hashCode</code> methods of <code>java.net.URL</code> both may trigger a name service (usually DNS) lookup to
 resolve the host name or IP address. Depending on the configuration, and network status, that can take a long time. <code>URI</code> on the other hand
 makes no such calls and should be used instead unless the specific <code>URL</code> functionality is required.</p>
@@ -5,7 +6,7 @@
 <code>URI</code> to a <code>URL</code> using <code>URI.toURL()</code>.</p>
 <p>This rule checks for uses of <code>URL</code> 's in <code>Map</code> and <code>Set</code> , and for explicit calls to the <code>equals</code> and
 <code>hashCode</code> methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void checkUrl(URL url) {
   Set&lt;URL&gt; sites = new HashSet&lt;URL&gt;();  // Noncompliant
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void checkUrl(URL url) {
   Set&lt;URI&gt; sites = new HashSet&lt;URI&gt;();  // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.html
index 19e9d860d6f..65451e311b4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Passing a collection as an argument to the collection’s own method is either an error - some other argument was intended - or simply nonsensical
 code.</p>
 <p>Further, because some methods require that the argument remain unmodified during the execution, passing a collection to itself can result in
 undefined behavior.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List &lt;Object&gt; objs = new ArrayList&lt;Object&gt;();
 objs.add("Hello");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2115.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2115.html
index b8aa31ce9c6..7f00d097be9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2115.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2115.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>When relying on the password authentication mode for the database connection, a secure password should be chosen.</p>
 <p>This rule raises an issue when an empty password is used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Connection conn = DriverManager.getConnection("jdbc:derby:memory:myDB;create=true", "login", "");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String password = System.getProperty("database.password");
 Connection conn = DriverManager.getConnection("jdbc:derby:memory:myDB;create=true", "login", password);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
index d9dd729db73..fe09a2b4faf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>While <code>hashCode</code> and <code>toString</code> are available on arrays, they are largely useless. <code>hashCode</code> returns the array’s
 "identity hash code", and <code>toString</code> returns nearly the same value. Neither method’s output actually reflects the array’s contents.
 Instead, you should pass the array to the relevant static <code>Arrays</code> method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static void main( String[] args )
 {
     String argStr = args.toString(); // Noncompliant
     int argHash = args.hashCode(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static void main( String[] args )
 {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
index cae2e1d8ac5..2db349b4c2f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Nothing in a non-serializable class will be written out to file, and attempting to serialize such a class will result in an exception being thrown.
 Only a class that <code>implements Serializable</code> or one that extends such a class can successfully be serialized (or de-serialized).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Vegetable {  // neither implements Serializable nor extends a class that does
   //...
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Vegetable implements Serializable {  // can now be serialized
   //...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
index 07276f56135..13188fa3d02 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>Creating a new <code>Random</code> object each time a random value is needed is inefficient and may produce numbers which are not random depending
 on the JDK. For better efficiency and randomness, create a single <code>Random</code>, then store, and reuse it.</p>
 <p>The <code>Random()</code> constructor tries to set the seed with a distinct value every time. However there is no guarantee that the seed will be
 random or even uniformly distributed. Some JDK will use the current time as seed, which makes the generated numbers not random at all.</p>
 <p>This rule finds cases where a new <code>Random</code> is created each time a method is invoked.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomethingCommon() {
   Random rand = new Random();  // Noncompliant; new instance created with each invocation
   int rValue = rand.nextInt();
   //...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Random
 
@@ -18,10 +19,10 @@ <h2>Compliant Solution</h2>
   int rValue = this.rand.nextInt();
   //...
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>A class which uses a <code>Random</code> in its constructor or in a static <code>main</code> function and nowhere else will be ignored by this
 rule.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
index 9a93fa1a26f..6041f3c22d1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Creating a substring from 0 to the end is silly. You’ll end up with the same string you started with. Using the value of <code>String.length</code>
 as either the start or end of a substring has similarly predictable results.</p>
 <p>Calling <code>String.contains</code> with the argument being identical to the String on which contains is invoked doesn’t make sense.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String speech = "Now is the time for all good people to come to the aid of their country.";
 
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
  // always true
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String speech = "Now is the time for all good people to come to the aid of their country.";
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
index 6ed7bc2c392..05008afddd1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>java.util.concurrent.ScheduledThreadPoolExecutor</code>'s pool is sized with <code>corePoolSize</code>, so setting <code>corePoolSize</code>
 to zero means the executor will have no threads and run nothing.</p>
 <p>This rule detects instances where <code>corePoolSize</code> is set to zero, via either its setter or the object constructor.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void do(){
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2123.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2123.html
index cebda0984d5..0823315912c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2123.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2123.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>A value that is incremented or decremented and then not stored is at best wasted code and at worst a bug.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int pickNumber() {
   int i = 0;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   return j++; // Noncompliant; 0 returned
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int pickNumber() {
   int i = 0;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
index a514285e0b2..aa458561775 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>Double.longBitsToDouble</code> expects a 64-bit, <code>long</code> argument. Pass it a smaller value, such as an <code>int</code> and the
 mathematical conversion into a <code>double</code> simply won’t work as anticipated because the layout of the bits will be interpreted incorrectly, as
 if a child were trying to use an adult’s gloves.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int i = 42;
 double d = Double.longBitsToDouble(i);  // Noncompliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
index bb10eadf3ef..02c1af0a1dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Constructors for <code>String</code>, <code>BigInteger</code>, <code>BigDecimal</code> and the objects used to wrap primitives should never be
 used. Doing so is less clear and uses more memory than simply using the desired value in the case of strings, and using <code>valueOf</code> for
 everything else.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String empty = new String(); // Noncompliant; yields essentially "", so just use that.
 String nonempty = new String("Hello world"); // Noncompliant
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 BigInteger bigInteger2 = new BigInteger("9223372036854775807"); // Noncompliant
 BigInteger bigInteger3 = new BigInteger("111222333444555666777888999"); // Compliant, greater than Long.MAX_VALUE
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String empty = "";
 String nonempty = "Hello world";
@@ -23,7 +24,7 @@ <h2>Compliant Solution</h2>
 BigInteger bigInteger2 = BigInteger.valueOf(9223372036854775807L);
 BigInteger bigInteger3 = new BigInteger("111222333444555666777888999");
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>BigDecimal</code> constructor with <code>double</code> argument is ignored as using <code>valueOf</code> instead might change resulting
 value. See {rule:java:S2111} .</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
index faf4e4fcd81..dbc3103791e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>Rather than creating a boxed primitive from a <code>String</code> to extract the primitive value, use the relevant <code>parse</code> method
 instead. It will be clearer and more efficient.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String myNum = "12.2";
 
 float f = (new Float(myNum)).floatValue();  // Noncompliant; creates &amp; discards a Float
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String myNum = "12.2";
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2131.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2131.html
index a9b200ce73f..8f40777d26d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2131.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2131.html
@@ -1,18 +1,18 @@
+<p>This rule is deprecated; use {rule:java:S1158} instead.</p>
+<h2>Why is this an issue?</h2>
 <p>"Boxing" is the process of putting a primitive value into a primitive-wrapper object. When that’s done purely to use the wrapper class'
 <code>toString</code> method, it’s a waste of memory and cycles because those methods are <code>static</code>, and can therefore be used without a
 class instance. Similarly, using the <code>static</code> method <code>valueOf</code> in the primitive-wrapper classes with a non-<code>String</code>
 argument should be avoided.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int myInt = 4;
 String myIntString = (new Integer(myInt)).toString(); // Noncompliant; creates &amp; discards an Integer object
 myIntString = Integer.valueOf(myInt).toString(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int myInt = 4;
 String myIntString = Integer.toString(myInt);
 </pre>
-<h2>Deprecated</h2>
-<p>This rule is deprecated; use {rule:java:S1158} instead.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
index 75749d56e5f..7617d712fdd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Creating an object for the sole purpose of calling <code>getClass</code> on it is a waste of memory and cycles. Instead, simply use the class'
 <code>.class</code> property.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 MyObject myOb = new MyObject();  // Noncompliant
 Class c = myOb.getClass();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Class c = MyObject.class;
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
index 8b225698176..027caa97e92 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java API documentation:</p>
 <blockquote>
   <p>There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the
@@ -7,14 +8,14 @@
 </blockquote>
 <p>By definition, extending the Thread class without overriding the <code>run</code> method doesn’t make sense, and implies that the contract of the
 <code>Thread</code> class is not well understood.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyRunner extends Thread { // Noncompliant; run method not overridden
 
   public void doSometing() {...}
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>If <code>run()</code> is not overridden in a class extending <code>Thread</code>, it means that starting the thread will actually call
 <code>Thread.run()</code>. However, <code>Thread.run()</code> does nothing if it has not been fed with a target <code>Runnable</code>. The rule
 consequently ignore classes extending <code>Thread</code> if they are calling, in their constructors, the <code>super(...)</code> constructor with a
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2139.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2139.html
index 550300be50d..8ced552c95d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2139.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2139.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>In applications where the accepted practice is to log an <code>Exception</code> and then rethrow it, you end up with miles-long logs that contain
 multiple instances of the same exception. In multi-threaded applications debugging this type of log can be particularly hellish because messages from
 other threads will be interwoven with the repetitions of the logged-and-thrown <code>Exception</code>. Instead, exceptions should be either logged or
 rethrown, not both.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 catch (SQLException e) {
   ...
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   throw new MySQLException(contextInfo, e);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 catch (SQLException e) {
   ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
index 3c2dac15809..6acc5369d3d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>There is no need to multiply the output of <code>Random</code>'s <code>nextDouble</code> method to get a random integer. Use the
 <code>nextInt</code> method instead.</p>
 <p>This rule raises an issue when the return value of any of <code>Random</code>'s methods that return a floating point value is converted to an
 integer.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Random r = new Random();
 int rand = (int)r.nextDouble() * 50;  // Noncompliant way to get a pseudo-random value between 0 and 50
 int rand2 = (int)r.nextFloat(); // Noncompliant; will always be 0;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Random r = new Random();
 int rand = r.nextInt(50);  // returns pseudo-random value between 0 and 50
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2141.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2141.html
index c48789d133c..30301c71f9b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2141.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2141.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Because <code>Object</code> implements <code>hashCode</code>, any Java class can be put into a hash structure. However, classes that define
 <code>equals(Object)</code> but not <code>hashCode()</code> aren’t truly hash-able because instances that are equivalent according to the
 <code>equals</code> method can return different hashes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Student {  // no hashCode() method; not hash-able
   // ...
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
 
   // ...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Student {  // has hashCode() method; hash-able
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
index 36dbb22a7dc..f3913c6f2fb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>InterruptedExceptions</code> should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The
 throwing of the <code>InterruptedException</code> clears the interrupted state of the Thread, so if the exception is not handled properly the
 information that the thread was interrupted will be lost. Instead, <code>InterruptedExceptions</code> should either be rethrown - immediately or after
@@ -8,7 +9,7 @@
 <blockquote>
   <p>If <code>ThreadDeath</code> is caught by a method, it is important that it be rethrown so that the thread actually dies.</p>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void run () {
   try {
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void run () {
   try {
@@ -34,7 +35,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/391">MITRE, CWE-391</a> - Unchecked Error Condition </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2143.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2143.html
index 113a673936d..0d40765e0d5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2143.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2143.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The old, much-derided <code>Date</code> and <code>Calendar</code> classes have always been confusing and difficult to use properly, particularly in
 a multi-threaded context. <code>JodaTime</code> has long been a popular alternative, but now an even better option is built-in. Java 8’s JSR 310
 implementation offers specific classes for:</p>
@@ -67,14 +68,14 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Date now = new Date();  // Noncompliant
 DateFormat df = new SimpleDateFormat("dd.MM.yyyy");
 Calendar christmas  = Calendar.getInstance();  // Noncompliant
 christmas.setTime(df.parse("25.12.2020"));
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 LocalDate now = LocalDate.now();  // gets calendar date. no time component
 LocalTime now2 = LocalTime.now(); // gets current time. no date component
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2147.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2147.html
index ecd2acca3b3..abff849c0bb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2147.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2147.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Since Java 7 it has been possible to catch multiple exceptions at once. Therefore, when multiple <code>catch</code> blocks have the same code, they
 should be combined for better readability.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 catch (IOException e) {
   doCleanup();
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   throw e;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 catch (IOException|SQLException e) {
   doCleanup();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2148.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2148.html
index 46e22faab69..9202132a456 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2148.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2148.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Beginning with Java 7, it is possible to add underscores ('_') to numeric literals to enhance readability. The addition of underscores in this
 manner has no semantic meaning, but makes it easier for maintainers to understand the code.</p>
 <p>The number of digits to the left of a decimal point needed to trigger this rule varies by base.</p>
@@ -33,13 +34,13 @@
 </table>
 <p>It is only the presence of underscores, not their spacing that is scrutinized by this rule.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int i = 10000000;  // Noncompliant; is this 10 million or 100 million?
 int  j = 0b01101001010011011110010101011110;  // Noncompliant
 long l = 0x7fffffffffffffffL;  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int i = 10_000_000;
 int  j = 0b01101001_01001101_11100101_01011110;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
index 38ce1f57584..0e1c1ebe6e0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Running finalizers on JVM exit is disabled by default. It can be enabled with <code>System.runFinalizersOnExit</code> and
 <code>Runtime.runFinalizersOnExit</code>, but both methods are deprecated because they are inherently unsafe.</p>
 <p>According to the Oracle Javadoc:</p>
@@ -6,7 +7,7 @@
   behavior or deadlock.</p>
 </blockquote>
 <p>If you really want to execute something when the virtual machine begins its shutdown sequence, you should attach a shutdown hook.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static void main(String [] args) {
   ...
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   doSomething();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static void main(String [] args) {
   Runtime.addShutdownHook(new Runnable() {
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   });
   //...
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
index 505edc4483d..5d88d6e17d4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Boxing is the process of putting a primitive value into an analogous object, such as creating an <code>Integer</code> to hold an <code>int</code>
 value. Unboxing is the process of retrieving the primitive value from such an object.</p>
 <p>Since the original value is unchanged during boxing and unboxing, there’s no point in doing either when not needed. This also applies to autoboxing
 and auto-unboxing (when Java implicitly handles the primitive/object transition for you).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void examineInt(int a) {
   //...
@@ -28,7 +29,7 @@ <h2>Noncompliant Code Example</h2>
   Integer iger2 = new Integer(iger1); // Noncompliant; unnecessary unboxing, value can be reused
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void examineInt(int a) {
   //...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2154.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2154.html
index ec65e1111d2..b8304906bc0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2154.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2154.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>If wrapped primitive values (e.g. <code>Integers</code> and <code>Floats</code>) are used in a ternary operator (e.g. <code>a?b:c</code>), both
 values will be unboxed and coerced to a common type, potentially leading to unexpected results. To avoid this, add an explicit cast to a compatible
 type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Integer i = 123456789;
 Float f = 1.0f;
 Number n = condition ? i : f;  // Noncompliant; i is coerced to float. n = 1.23456792E8
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Integer i = 123456789;
 Float f = 1.0f;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2156.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2156.html
index 4080d758d74..4fbbe148158 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2156.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2156.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>The difference between <code>private</code> and <code>protected</code> visibility is that child classes can see and use <code>protected</code>
 members, but they cannot see <code>private</code> ones. Since a <code>final</code> class will have no children, marking the members of a
 <code>final</code> class <code>protected</code> is confusingly pointless.</p>
 <p>Note that the <code>protected</code> members of a class can also be seen and used by other classes that are placed within the same package, this
 could lead to accidental, unintended access to otherwise private members.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public final class MyFinalClass {
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
     // ...
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public final class MyFinalClass {
 
@@ -21,7 +22,7 @@ <h2>Compliant Solution</h2>
     // ...
   }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Members annotated with&nbsp;<code>@VisibleForTesting</code> annotation are ignored, as it indicates that visibility has been purposely relaxed to
 make the code testable.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
index 665466a2b5a..37a7fa94c98 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Simply implementing <code>Cloneable</code> without also overriding <code>Object.clone()</code> does not necessarily make the class cloneable. While
 the <code>Cloneable</code> interface does not include a <code>clone</code> method, it is required by convention, and ensures true cloneability.
 Otherwise the default JVM <code>clone</code> will be used, which copies primitive values and object references from the source to the target. I.e.
 without overriding <code>clone</code>, any cloned instances will potentially share members with the source instance.</p>
 <p>Removing the <code>Cloneable</code> implementation and providing a good copy constructor is another viable (some say preferable) way of allowing a
 class to be copied.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Team implements Cloneable {  // Noncompliant
   private Person coach;
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   public Person getCoach() {...}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Team implements Cloneable {
   private Person coach;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2159.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2159.html
index 9a8b8a770ea..34ff0b7471a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2159.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2159.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Comparisons of dissimilar types will always return false. The comparison and all its dependent code can simply be removed. This includes:</p>
 <ul>
   <li> comparing an object with null </li>
@@ -13,7 +14,7 @@
 <p>However, some developers might expect <code>Array.equals(Object obj)</code> to do more than a simple memory address comparison, comparing for
 instance the size and content of the two arrays. Instead, the <code>==</code> operator or <code>Arrays.equals(array1, array2)</code> should always be
 used with arrays.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 interface KitchenTool { ... };
 interface Plant {...}
@@ -50,7 +51,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/5zdGBQ">CERT, EXP02-J.</a> - Do not use the Object.equals() method to compare two arrays </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
index d0f57942915..c91e33ad9f5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Extend a class that overrides <code>equals</code> and add fields without overriding <code>equals</code> in the subclass, and you run the risk of
 non-equivalent instances of your subclass being seen as equal, because only the superclass fields will be considered in the equality test.</p>
 <p>This rule looks for classes that do all of the following:</p>
@@ -6,7 +7,7 @@
   <li> do not themselves override <code>equals</code>. </li>
   <li> add fields. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit {
   private Season ripe;
@@ -30,7 +31,7 @@ <h2>Noncompliant Code Example</h2>
   private Color ripeColor;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit {
   private Season ripe;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2162.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2162.html
index 3b621e8d621..c6d9a4ee64d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2162.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2162.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A key facet of the <code>equals</code> contract is that if <code>a.equals(b)</code> then <code>b.equals(a)</code>, i.e. that the relationship is
 symmetric.</p>
 <p>Using <code>instanceof</code> breaks the contract when there are subclasses, because while the child is an <code>instanceof</code> the parent, the
@@ -19,7 +20,7 @@
 method for subclasses. Instead, make the comparison dynamic.</p>
 <p>Further, comparing to an unrelated class type breaks the contract for that unrelated type, because while
 <code>thisClass.equals(unrelatedClass)</code> can return true, <code>unrelatedClass.equals(thisClass)</code> will not.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit extends Food {
   private Season ripe;
@@ -42,7 +43,7 @@ <h2>Noncompliant Code Example</h2>
     }
     //...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit extends Food {
   private Season ripe;
@@ -60,7 +61,7 @@ <h2>Compliant Solution</h2>
     return false;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/AzZGBQ">CERT, MET08-J.</a> - Preserve the equality contract when overriding the equals() method
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2164.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2164.html
index 94aa086f509..5c9966d6a1a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2164.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2164.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>For small numbers, <code>float</code> math has enough precision to yield the expected value, but for larger numbers, it does not.
 <code>BigDecimal</code> is the best alternative, but if a primitive is required, use a <code>double</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 float a = 16777216.0f;
 float b = 1.0f;
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
 
 double d = a + b; // Noncompliant; addition is still between 2 floats
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 float a = 16777216.0f;
 float b = 1.0f;
@@ -16,13 +17,13 @@ <h2>Compliant Solution</h2>
 
 double d = (double)a + (double)b;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise an issue when the mathematical expression is only used to build a string.</p>
 <pre>
 System.out.println("["+getName()+"] " +
            "\n\tMax time to retrieve connection:"+(max/1000f/1000f)+" ms.");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/CtcxBQ">CERT, FLP02-C.</a> - Avoid using floating-point numbers when precise computation is
   needed </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
index 1c0a3f90f1a..e0bc9b9efb3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>There is no point in setting class fields to <code>null</code> in a finalizer. If this this is a hint to the garbage collector, it is unnecessary -
 the object will be garbage collected anyway - and doing so may actually cause extra work for the garbage collector.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
   private String name;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2166.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2166.html
index 349885b4b9b..226c0974422 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2166.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2166.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Clear, communicative naming is important in code. It helps maintainers and API users understand the intentions for and uses of a unit of code.
 Using "exception" in the name of a class that does not extend <code>Exception</code> or one of its subclasses is a clear violation of the expectation
 that a class' name will indicate what it is and/or does.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class FruitException {  // Noncompliant; this has nothing to do with Exception
   private Fruit expected;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   public CarException(String message, Throwable cause) {
   // ...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class FruitSport {
   private Fruit expected;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2167.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2167.html
index 52e8e1f6854..4dde62e9419 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2167.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2167.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>It is the sign, rather than the magnitude of the value returned from <code>compareTo</code> that matters. Returning <code>Integer.MIN_VALUE</code>
 does <em>not</em> convey a higher degree of inequality, and doing so can cause errors because the return value of <code>compareTo</code> is sometimes
 inversed, with the expectation that negative values become positive. However, inversing <code>Integer.MIN_VALUE</code> yields
 <code>Integer.MIN_VALUE</code> rather than <code>Integer.MAX_VALUE</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int compareTo(MyClass) {
   if (condition) {
     return Integer.MIN_VALUE;  // Noncompliant
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int compareTo(MyClass) {
   if (condition) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2168.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2168.html
index b1423b64f4e..7fdd43adfd6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2168.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2168.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Double-checked locking is the practice of checking a lazy-initialized object’s state both before and after a <code>synchronized</code> block is
 entered to determine whether or not to initialize the object.</p>
 <p>It does not work reliably in a platform-independent manner without additional synchronization for mutable instances of anything other than
@@ -8,7 +9,7 @@
 With early versions of the JVM, synchronizing the whole method was generally advised against for performance reasons. But <code>synchronized</code>
 performance has improved a lot in newer JVMs, so this is now a preferred solution. If you prefer to avoid using <code>synchronized</code> altogether,
 you can use an inner <code>static class</code> to hold the reference instead. Inner static classes are guaranteed to load lazily.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @NotThreadSafe
 public class DoubleCheckedLocking {
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @ThreadSafe
 public class SafeLazyInitialization {
@@ -83,7 +84,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html">The "Double-Checked Locking is Broken" Declaration</a> </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6zdGBQ">CERT, LCK10-J.</a> - Use a correct form of the double-checked locking idiom </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2175.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2175.html
index 2649d694f02..7ad900c1160 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2175.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2175.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>java.util.Collection</code> API has methods that accept <code>Object</code> parameters such as <code>Collection.remove(Object o)</code>,
 and <code>Collection.contains(Object o)</code>. When the actual type of the object provided to these methods is not consistent with the type declared
 on the <code>Collection</code> instantiation, those methods will always return <code>false</code> or <code>null</code>. This is most likely unintended
@@ -17,7 +18,7 @@
   <li> <code>Map.remove(Object key)</code> </li>
   <li> <code>Map.remove(Object key, Object value)</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class S2175 {
 
@@ -37,7 +38,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/uDdGBQ">CERT, EXP04-J.</a> - Do not pass arguments to certain Java Collections Framework methods
   that are a different type than the collection parameter type </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2176.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2176.html
index 3e8023636ed..af3aba4f2d8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2176.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2176.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>While it’s perfectly legal to give a class the same simple name as a class in another package that it extends or interface it implements, it’s
 confusing and could cause problems in the future.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 package my.mypackage;
 
 public class Foo implements a.b.Foo { // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package my.mypackage;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2177.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2177.html
index d71d086927b..fa7364d6d5c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2177.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2177.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When a method in a child class has the same signature as a method in a parent class, it is assumed to be an override. However, that’s not the case
 when:</p>
 <ul>
@@ -8,7 +9,7 @@
 <p>Typically, these things are done unintentionally; the private parent class method is overlooked, the <code>static</code> keyword in the parent
 declaration is overlooked, or the wrong class is imported in the child. But if the intent is truly for the child class method to be different, then
 the method should be renamed to prevent confusion.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // Parent.java
 import computer.Pear;
@@ -37,7 +38,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // Parent.java
 import computer.Pear;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2178.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2178.html
index 6b9e1988493..1080e2239aa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2178.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2178.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>The use of non-short-circuit logic in a boolean context is likely a mistake - one that could cause serious program errors as conditions are
 evaluated under the wrong circumstances.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if(getTrue() | getFalse()) { ... } // Noncompliant; both sides evaluated
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if(getTrue() || getFalse()) { ... } // true short-circuit logic
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/WNYxBQ">CERT, EXP46-C.</a> - Do not use a bitwise operator with a Boolean-like operand </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2183.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2183.html
index 9b3612ec6ef..ba35c401688 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2183.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2183.html
@@ -1,23 +1,24 @@
+<h2>Why is this an issue?</h2>
 <p>Since an <code>int</code> is a 32-bit variable, shifting by more than +/-31 is confusing at best and an error at worst. When the runtime shifts
 32-bit integers, it uses the lowest 5 bits of the shift count operand. In other words, shifting an <code>int</code> by 32 is the same as shifting it
 by 0, and shifting it by 33 is the same as shifting it by 1.</p>
 <p>Similarly, when shifting 64-bit integers, the runtime uses the lowest 6 bits of the shift count operand and shifting <code>long</code> by 64 is the
 same as shifting it by 0, and shifting it by 65 is the same as shifting it by 1.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public int shift(int a) {
   int x = a &gt;&gt; 32; // Noncompliant
   return a &lt;&lt; 48;  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public int shift(int a) {
   int x = a &gt;&gt; 31;
   return a &lt;&lt; 16;
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise an issue when the shift by zero is obviously for cosmetic reasons:</p>
 <ul>
   <li> When the value shifted is a literal. </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2184.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2184.html
index 43c2de3df58..1148cbb39bd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2184.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2184.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When arithmetic is performed on integers, the result will always be an integer. You can assign that result to a <code>long</code>,
 <code>double</code>, or <code>float</code> with automatic type conversion, but having started as an <code>int</code> or <code>long</code>, the result
 will likely not be what you expect.</p>
@@ -5,7 +6,7 @@
 assignment. Likewise, if the result of multiplication is assigned to a <code>long</code>, it may have already overflowed before the assignment.</p>
 <p>In either case, the result will not be what was expected. Instead, at least one operand should be cast or promoted to the final type before the
 operation takes place.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 float twoThirds = 2/3; // Noncompliant; int division. Yields 0.0
 long millisInYear = 1_000*3_600*24*365; // Noncompliant; int multiplication. Yields 1471228928
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   return factor / 123;  //Noncompliant, will be rounded to closest long integer
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 float twoThirds = 2f/3; // 2 promoted to float. Yields 0.6666667
 long millisInYear = 1_000L*3_600*24*365; // 1000 promoted to long. Yields 31_536_000_000
@@ -53,7 +54,7 @@ <h2>Compliant Solution</h2>
   return factor / 123;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/190">MITRE, CWE-190</a> - Integer Overflow or Wraparound </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/AjdGBQ">CERT, NUM50-J.</a> - Convert integers to floating point for floating-point operations
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2185.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2185.html
index b5e5068d343..b645f9172ee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2185.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2185.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Certain math operations are just silly and should not be performed because their results are predictable.</p>
 <p>In particular, <code>anyValue % 1</code> is silly because it will always return 0.</p>
 <p>Casting a non-floating-point value to floating-point and then passing it to <code>Math.round</code>, <code>Math.ceil</code>, or
@@ -91,7 +92,7 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doMath(int a) {
   double floor = Math.floor((double)a); // Noncompliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2186.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2186.html
index efbef716e82..f9e8887f626 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2186.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2186.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>JUnit assertions should not be made from the <code>run</code> method of a <code>Runnable</code>, because failed assertions result in
 <code>AssertionError</code>s being thrown. If the error is thrown from a thread other than the one that ran the test, the thread will exit but the
 test won’t fail.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void run() {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2187.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2187.html
index 0108ff1f58c..90779dc947d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2187.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2187.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no point in having a JUnit <code>TestCase</code> without any test methods. Similarly, you shouldn’t have a file in the tests directory
 named <code>*Test</code>, <code>*Tests</code>, or <code>*TestCase</code>, but no tests in the file. Doing either of these things may lead someone to
 think that uncovered classes have been tested.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2188.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2188.html
index 85d7a39a7cf..fd1765be78e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2188.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2188.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Overriding a parent class method prevents that method from being called unless an explicit <code>super</code> call is made in the overriding
 method. In some cases not calling the <code>super</code> method is acceptable, but not with <code>setUp</code> and <code>tearDown</code> in a JUnit 3
 <code>TestCase</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClassTest extends MyAbstractTestCase {
 
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
       myClass = new MyClass();
     }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClassTest extends MyAbstractTestCase {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2189.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2189.html
index a85aa6cb2cf..91444f670fc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2189.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2189.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>An infinite loop is one that will never end while the program is running, i.e., you have to kill the program to get out of the loop. Whether it is
 by meeting the loop’s end condition or via a <code>break</code>, every loop should have an end condition.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (;;) {  // Noncompliant; end condition omitted
   // ...
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   k++;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int j;
 while (true) { // reachable end condition added
@@ -34,7 +35,7 @@ <h2>Compliant Solution</h2>
   b = k &lt; Integer.MAX_VALUE;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/lzZGBQ">CERT, MSC01-J.</a> - Do not use an empty infinite loop </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2196.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2196.html
index 1b0aa8bdb5b..c23ebc35915 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2196.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2196.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Since Java 7, <code>String</code>s can be used as <code>switch</code> arguments. So when a single <code>String</code> is tested against three or
 more values in an <code>if</code>/<code>else if</code> structure, it should be converted to a switch instead for greater readability.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if ("red".equals(choice)) {  // Noncompliant
   dispenseRed();
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   promptUser();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch(choice) {
   case "Red":
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2197.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2197.html
index 6ce83c4ec7d..6adcb17e697 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2197.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2197.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>When the modulus of a negative number is calculated, the result will either be negative or zero. Thus, comparing the modulus of a variable for
 equality with a positive number (or a negative one) could result in unexpected results.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public boolean isOdd(int x) {
   return x % 2 == 1;  // Noncompliant; if x is an odd negative, x % 2 == -1
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean isOdd(int x) {
   return x % 2 != 0;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/pDdGBQ">CERT, NUM51-J.</a> - Do not assume that the remainder operator always returns a
   nonnegative result for integral operands </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2200.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2200.html
index b3c42d20aec..e30b12340e1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2200.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2200.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>While most <code>compareTo</code> methods return -1, 0, or 1, some do not, and testing the result of a <code>compareTo</code> against a specific
 value other than 0 could result in false negatives.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (myClass.compareTo(arg) == -1) {  // Noncompliant
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (myClass.compareTo(arg) &lt; 0) {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2201.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2201.html
index 5f193f39aa1..8d8af052f5c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2201.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2201.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the call to a function doesn’t have any side effects, what is the point of making the call if the results are ignored? In such case, either
 the function call is useless and should be dropped or the source code doesn’t behave as expected.</p>
 <p>To prevent generating any false-positives, this rule triggers an issue only on the following predefined list of immutable classes in the Java API
@@ -69,21 +70,21 @@
       <li> <code>toList</code> </li>
     </ul>  </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void handle(String command){
   command.toLowerCase(); // Noncompliant; result of method thrown away
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void handle(String command){
   String formattedCommand = command.toLowerCase();
   ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule will not raise an issue when both these conditions are met:</p>
 <ul>
   <li> The method call is in a <code>try</code> block with an associated <code>catch</code> clause. </li>
@@ -100,7 +101,7 @@ <h2>Exceptions</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/xzdGBQ">CERT, EXP00-J.</a> - Do not ignore values returned by methods </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2203.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2203.html
index fd11a714db1..a2518e417a6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2203.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2203.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>While you can use either <code>forEach(list::add)</code> or <code>collect</code> with a <code>Stream</code>, <code>collect</code> is by far the
 better choice because it’s automatically thread-safe and parallellizable.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;String&gt; bookNames = new ArrayList&lt;&gt;();
 books.stream().filter(book -&gt; book.getIsbn().startsWith("0"))
                 .map(Book::getTitle)
                 .forEach(bookNames::add);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; bookNames = books.stream().filter(book -&gt; book.getIsbn().startsWith("0"))
                 .map(Book::getTitle)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2204.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2204.html
index 347531abd1a..37ffc9eb533 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2204.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2204.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p><code>AtomicInteger</code>, and <code>AtomicLong</code> extend <code>Number</code>, but they’re distinct from <code>Integer</code> and
 <code>Long</code> and should be handled differently. <code>AtomicInteger</code> and <code>AtomicLong</code> are designed to support lock-free,
 thread-safe programming on single variables. As such, an <code>AtomicInteger</code> will only ever be "equal" to itself. Instead, you should
 <code>.get()</code> the value and make comparisons on it.</p>
 <p>This applies to all the atomic, seeming-primitive wrapper classes: <code>AtomicInteger</code>, <code>AtomicLong</code>, and
 <code>AtomicBoolean</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 AtomicInteger aInt1 = new AtomicInteger(0);
 AtomicInteger aInt2 = new AtomicInteger(0);
 
 if (aInt1.equals(aInt2)) { ... }  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 AtomicInteger aInt1 = new AtomicInteger(0);
 AtomicInteger aInt2 = new AtomicInteger(0);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2208.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2208.html
index 34a681a770e..e3bd459bcbd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2208.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2208.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Blindly importing all the classes in a package clutters the class namespace and could lead to conflicts between classes in different packages with
 the same name. On the other hand, specifically listing the necessary classes avoids that problem and makes clear which versions were wanted.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import java.sql.*; // Noncompliant
 import java.util.*; // Noncompliant
 
 private Date date; // Date class exists in java.sql and java.util. Which one is this?
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import java.sql.Date;
 import java.util.List;
@@ -15,7 +16,7 @@ <h2>Compliant Solution</h2>
 
 private Date date;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Static imports are ignored by this rule. E.G.</p>
 <pre>
 import static java.lang.Math.*;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2209.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2209.html
index 6523f8e759e..60b4b381855 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2209.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2209.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>While it is <em>possible</em> to access <code>static</code> members from a class instance, it’s bad form, and considered by most to be misleading
 because it implies to the readers of your code that there’s an instance of the member per class instance.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class A {
   public static int counter = 0;
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class A {
   public static int counter = 0;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2211.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2211.html
index 756a4198b62..3cbb23d9624 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2211.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2211.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions allow teams to collaborate effectively. While types for lambda arguments are optional, specifying them anyway makes the
 code clearer and easier to read.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Arrays.sort(rosterAsArray,
     (a, b) -&gt; {  // Noncompliant
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
     }
 );
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Arrays.sort(rosterAsArray,
     (Person a, Person b) -&gt; {
@@ -16,7 +17,7 @@ <h2>Compliant Solution</h2>
     }
 );
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When the lambda has one or two parameters and does not have a block this rule will not fire up an issue as things are considered more readable in
 those cases.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2221.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2221.html
index 6d23373e8b4..e119b85f92c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2221.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2221.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Catching <code>Exception</code> seems like an efficient way to handle multiple possible exceptions. Unfortunately, it traps all exception types,
 both checked and runtime exceptions, thereby casting too broad a net. Indeed, was it really the intention of developers to also catch runtime
 exceptions? To prevent any misunderstanding, if both checked and runtime exceptions are really expected to be caught, they should be explicitly listed
 in the <code>catch</code> clause.</p>
 <p>This rule raises an issue if <code>Exception</code> is caught when it is not explicitly thrown by a method in the <code>try</code> block.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try {
   // do something that might throw an UnsupportedDataTypeException or UnsupportedEncodingException
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   // log exception ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try {
   // do something
@@ -27,7 +28,7 @@ <h2>Compliant Solution</h2>
   // log exception ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/396">MITRE, CWE-396</a> - Declaration of Catch for Generic Exception </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2222.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2222.html
index 5b910e6705b..2ca56f6b9b7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2222.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2222.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>If a lock is acquired and released within a method, then it must be released along all execution paths of that method.</p>
 <p>Failing to do so will expose the conditional locking logic to the method’s callers and hence be deadlock-prone.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   public void doSomething() {
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   public void doSomething() {
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/459">MITRE, CWE-459</a> - Incomplete Cleanup </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2225.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2225.html
index 4d1625c5cc8..09d864ac110 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2225.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2225.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Calling <code>toString()</code> or <code>clone()</code> on an object should always return a string or an object. Returning <code>null</code>
 instead contravenes the method’s implicit contract.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String toString () {
   if (this.collection.isEmpty()) {
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
   } else {
     // ...
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public String toString () {
   if (this.collection.isEmpty()) {
@@ -16,7 +17,7 @@ <h2>Compliant Solution</h2>
   } else {
     // ...
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/476">MITRE, CWE-476</a> - NULL Pointer Dereference </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/aDdGBQ">CERT, EXP01-J.</a> - Do not use a null in a case where an object is required </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2226.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2226.html
index 57b0e3b7fd0..68746310e8a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2226.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2226.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>By contract, a servlet container creates one instance of each servlet and then a dedicated thread is attached to each new incoming HTTP request to
 process the request. So all threads share the servlet instances and by extension their instance fields. To prevent any misunderstanding and unexpected
 behavior at runtime, all servlet fields should then be either <code>static</code> and/or <code>final</code>, or simply removed.</p>
 <p>With Struts 1.X, the same constraint exists on <code>org.apache.struts.action.Action</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyServlet extends HttpServlet {
   private String userName;  //As this field is shared by all users, it's obvious that this piece of information should be managed differently
@@ -16,13 +17,13 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <ul>
   <li> Fields annotated with <code>@javax.inject.Inject</code>, <code>@javax.ejb.EJB</code>,
   <code>@org.springframework.beans.factory.annotation.Autowired</code>, <code>@javax.annotation.Resource</code> </li>
   <li> Fields initialized in <code>init()</code> or <code>init(ServletConfig config)</code> methods </li>
 </ul>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/2TZGBQ">CERT, MSC11-J.</a> - Do not let session information leak within a servlet </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2229.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2229.html
index 0fae2e31207..f14a9229f40 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2229.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2229.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When using Spring proxies, calling a method in the same class (e.g. <code>this.aMethod()</code>) with an incompatible <code>@Transactional</code>
 requirement will result in runtime exceptions because Spring only "sees" the caller and makes no provisions for properly invoking the callee.</p>
 <p>Therefore, certain calls should never be made within the same class:</p>
@@ -47,7 +48,7 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Override
 public void doTheThing() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2230.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2230.html
index 899a14951a9..9bff3730d5a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2230.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2230.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Marking a non-public method <code>@Transactional</code> is both useless and misleading because Spring doesn’t "see" non-<code>public</code>
 methods, and so makes no provision for their proper invocation. Nor does Spring make provision for the methods invoked by the method it called.</p>
 <p>Therefore marking a <code>private</code> method, for instance, <code>@Transactional</code> can only result in a runtime error or exception if the
 method is actually written to be <code>@Transactional</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Transactional  // Noncompliant
 private void doTheThing(ArgClass arg) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2232.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2232.html
index ce6073750c8..38dd2d4586a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2232.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2232.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>There are several reasons to avoid <code>ResultSet.isLast()</code>. First, support for this method is optional for <code>TYPE_FORWARD_ONLY</code>
 result sets. Second, it can be expensive (the driver may need to fetch the next row to answer the question). Finally, the specification is not clear
 on what should be returned when the <code>ResultSet</code> is empty, so some drivers may return the opposite of what is expected.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 stmt.executeQuery("SELECT name, address FROM PERSON");
 ResultSet rs = stmt.getResultSet();
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   // process row
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ResultSet rs = stmt.executeQuery("SELECT name, address FROM PERSON");
 while (rs.next()) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2234.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2234.html
index 37874494f57..af26089d970 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2234.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2234.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When the names of parameters in a method call match the names of the method arguments, it contributes to clearer, more readable code. However, when
 the names match, but are passed in a different order than the method arguments, it indicates a mistake in the parameter order which will likely lead
 to unexpected results.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public double divide(int divisor, int dividend) {
   return divisor/dividend;
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public double divide(int divisor, int dividend) {
   return divisor/dividend;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
index 4c934c0e06f..669126ff67e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to Oracle Javadoc:</p>
 <blockquote>
   <p><code>IllegalMonitorStateException</code> is thrown when a thread has attempted to wait on an object’s monitor or to notify other threads waiting
@@ -5,7 +6,7 @@
 </blockquote>
 <p>In other words, this exception can be thrown only in case of bad design because <code>Object.wait(...)</code>, <code>Object.notify()</code> and
 <code>Object.notifyAll()</code> methods should never be called on an object whose monitor is not held.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(){
   ...
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(){
   ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
index bd493a8286b..f63ac98959e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The methods <code>wait(...)</code>, <code>notify()</code> and <code>notifyAll()</code> are available on a <code>Thread</code> instance, but only
 because all classes in Java extend <code>Object</code> and therefore automatically inherit those methods. But there are two very good reasons for not
 calling them on a <code>Thread</code>:</p>
@@ -7,7 +8,7 @@
   <li> It is not clear (perhaps even to the original coder) what is really expected. For instance, it is waiting for the execution of the Thread to
   suspended, or is it the acquisition of the object monitor that is waited for? </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Thread myThread = new Thread(new RunnableJob());
 ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2250.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2250.html
index c24d5badd7c..ee1edb80f96 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2250.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2250.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The time complexity of method calls on collections is not always obvious. For instance, for most collections the <code>size()</code> method takes
 constant time, but the time required to execute <code>ConcurrentLinkedQueue.size()</code> is O(n), i.e. directly proportional to the number of
 elements in the collection. When the collection is large, this could therefore be an expensive operation.</p>
@@ -36,7 +37,7 @@
       <li> <code>remove</code> </li>
     </ul>  </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ConcurrentLinkedQueue queue = new ConcurrentLinkedQueue();
 //...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2251.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2251.html
index bc9150d7b26..1777418849a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2251.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2251.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>for</code> loop with a counter that moves in the wrong direction is not an infinite loop. Because of wraparound, the loop will eventually
 reach its stop condition, but in doing so, it will run many, many more times than anticipated, potentially causing unexpected behavior.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(String [] strings) {
   for (int i = 0; i &lt; strings.length; i--) { // Noncompliant;
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
     //...
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(String [] strings) {
   for (int i = 0; i &lt; strings.length; i++) {
@@ -16,7 +17,7 @@ <h2>Compliant Solution</h2>
     //...
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/aTdGBQ">CERT, MSC54-J.</a> - Avoid inadvertent wrapping of loop counters </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2252.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2252.html
index c0531b4a4dc..0cdb06578e4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2252.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2252.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>If a <code>for</code> loop’s condition is false before the first loop iteration, the loop will never be executed. Such loops are almost always
 bugs, particularly when the initial value and stop conditions are hard-coded.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 10; i &lt; 10; i++) {  // Noncompliant
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2253.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2253.html
index 849c3b43d8b..ae1b7d5249b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2253.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2253.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows banning certain methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>Given parameters:</p>
 <ul>
   <li> className:java.lang.String </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2254.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2254.html
index b66e3a0ba1d..7162c45e1b9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2254.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2254.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Oracle Java API, the <code>HttpServletRequest.getRequestedSessionId()</code> method:</p>
 <blockquote>
   <p>Returns the session ID specified by the client. This may not be the same as the ID of the current valid session for this request. If the client
@@ -15,13 +16,13 @@
 <p>Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (E.G.
 Tomcat or Jetty) to see if the value matches the ID of an an existing session. If it does not, the user should be considered unauthenticated.
 Moreover, this session ID should never be logged as is but using a one-way hash to prevent hijacking of active sessions.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if(isActiveSession(request.getRequestedSessionId()) ){
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2259.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2259.html
index 20fb6ad7b73..5db5b20f8e2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2259.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2259.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>A reference to <code>null</code> should never be dereferenced/accessed. Doing so will cause a <code>NullPointerException</code> to be thrown. At
 best, such an exception will cause abrupt program termination. At worst, it could expose debugging information that would be useful to an attacker, or
 it could allow an attacker to bypass security measures.</p>
 <p>Note that when they are present, this rule takes advantage of <code>@CheckForNull</code> and <code>@Nonnull</code> annotations defined in <a
 href="https://jcp.org/en/jsr/detail?id=305">JSR-305</a> to understand which values are and are not nullable except when <code>@Nonnull</code> is used
 on the parameter to <code>equals</code>, which by contract should always work with null.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @CheckForNull
 String getName(){...}
@@ -44,7 +45,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/476">MITRE, CWE-476</a> - NULL Pointer Dereference </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/QdcxBQ">CERT, EXP34-C.</a> - Do not dereference null pointers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2260.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2260.html
index c562cb96d5b..c7c30eaa2e4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2260.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2260.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the Java parser fails, it is possible to record the failure as a violation on the file. This way, not only it is possible to track the number
 of files that do not parse but also to easily find out why they do not parse.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2272.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2272.html
index 4b196c71706..0e11c468fda 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2272.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2272.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>By contract, any implementation of the <code>java.util.Iterator.next()</code> method should throw a <code>NoSuchElementException</code> exception
 when the iteration has no more elements. Any other behavior when the iteration is done could lead to unexpected behavior for users of this
 <code>Iterator</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyIterator implements Iterator&lt;String&gt;{
   ...
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyIterator implements Iterator&lt;String&gt;{
   ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2273.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2273.html
index 0bd665d10c6..0183c80a922 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2273.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2273.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>By contract, the method <code>Object.wait(...)</code>, <code>Object.notify()</code> and <code>Object.notifyAll()</code> should be called by a
 thread that is the owner of the object’s monitor. If this is not the case an <code>IllegalMonitorStateException</code> exception is thrown. This rule
 reinforces this constraint by making it mandatory to call one of these methods only inside a <code>synchronized</code> method or statement.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private void removeElement() {
   while (!suitableCondition()){
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   ... // Perform removal
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private void removeElement() {
   synchronized(obj) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2274.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2274.html
index 19adcee42e2..0a756c117b9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2274.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2274.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the documentation of the Java <code>Condition</code> interface:</p>
 <blockquote>
   <p>When waiting upon a <code>Condition</code>, a "spurious wakeup" is permitted to occur, in general, as a concession to the underlying platform
@@ -17,7 +18,7 @@
 }
 </pre>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 synchronized (obj) {
   if (!suitableCondition()){
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
    ... // Perform action appropriate to condition
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 synchronized (obj) {
   while (!suitableCondition()){
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
    ... // Perform action appropriate to condition
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/EzdGBQ">CERT THI03-J.</a> - Always invoke wait() and await() methods inside a loop </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2275.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2275.html
index 545f3166e06..0fd008ea279 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2275.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2275.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Because <code>printf</code>-style format strings are interpreted at runtime, rather than validated by the Java compiler, they can contain errors
 that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of <code>printf</code>-style formats when calling
 the <code>format(...)</code> methods of <code>java.util.Formatter</code>, <code>java.lang.String</code>, <code>java.io.PrintStream</code>,
 <code>MessageFormat</code>, and <code>java.io.PrintWriter</code> classes and the <code>printf(...)</code> methods of <code>java.io.PrintStream</code>
 or <code>java.io.PrintWriter</code> classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String.format("The value of my integer is %d", "Hello World");  // Noncompliant; an 'int' is expected rather than a String
 String.format("Duke's Birthday year is %tX", c);  //Noncompliant; X is not a supported time conversion character
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
 org.apache.logging.log4j.Logger log4jLog;
 log4jLog.debug("message {}"); // Noncompliant - Not enough arguments.
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String.format("The value of my integer is %d", 3);
 String.format("Duke's Birthday year is %tY", c);
@@ -49,7 +50,7 @@ <h2>Compliant Solution</h2>
 org.apache.logging.log4j.Logger log4jLog;
 log4jLog.debug("message {}", 1);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.securecoding.cert.org/confluence/x/wQA1">CERT, FIO47-C.</a> - Use valid format strings </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2276.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2276.html
index 9fdb33f3a1e..e92e64e48bc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2276.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2276.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>If <code>Thread.sleep(...)</code> is called when the current thread holds a lock, it could lead to performance and scalability issues, or even
 worse to deadlocks because the execution of the thread holding the lock is frozen. It’s better to call <code>wait(...)</code> on the monitor object to
 temporarily release the lock and allow other threads to run.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(){
   synchronized(monitor) {
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(){
   synchronized(monitor) {
@@ -25,7 +26,7 @@ <h2>Compliant Solution</h2>
   ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/YTdGBQ">CERT, LCK09-J.</a> - Do not perform operations that can block while holding a lock </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2293.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2293.html
index 8cf4c7b44e0..f44b68d877b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2293.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2293.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Java 7 introduced the diamond operator (<code>&lt;&gt;</code>) to reduce the verbosity of generics code. For instance, instead of having to declare
 a <code>List</code>'s type in both its declaration and its constructor, you can now simplify the constructor declaration with <code>&lt;&gt;</code>,
 and the compiler will infer the type.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;String&gt; strings = new ArrayList&lt;String&gt;();  // Noncompliant
 Map&lt;String,List&lt;Integer&gt;&gt; map = new HashMap&lt;String,List&lt;Integer&gt;&gt;();  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; strings = new ArrayList&lt;&gt;();
 Map&lt;String,List&lt;Integer&gt;&gt; map = new HashMap&lt;&gt;();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2301.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2301.html
index ff29fe1b625..bd8fffb0ab4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2301.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2301.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>A selector argument is a <code>boolean</code> argument that’s used to determine which of two paths to take through a method. Specifying such a
 parameter may seem innocuous, particularly if it’s well named.</p>
 <p>Unfortunately, the maintainers of the code calling the method won’t see the parameter name, only its value. They’ll be forced either to guess at
 the meaning or to take extra time to look the method up.</p>
 <p>Instead, separate methods should be written.</p>
 <p>This rule finds methods with a <code>boolean</code> that’s used to determine which path to take through the method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String tempt(String name, boolean ofAge) {
   if (ofAge) {
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   tempt("Joe", false); // does this mean not to temp Joe?
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void temptAdult(String name) {
   offerLiquor(name);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2308.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2308.html
index 33ed771e89c..8c734f32744 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2308.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2308.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Use of <code>File.deleteOnExit()</code> is not recommended for the following reasons:</p>
 <ul>
   <li> The deletion occurs only in the case of a normal JVM shutdown but not when the JVM crashes or is killed. </li>
   <li> For each file handler, the memory associated with the handler is released only at the end of the process. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 File file = new File("file.txt");
 file.deleteOnExit();  // Noncompliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2309.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2309.html
index d02d02a2e6d..b2680ba5216 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2309.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2309.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Files with no lines of code clutter a project and should be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 //package org.foo;
 //
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2325.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2325.html
index ea293de7a70..be8b344e28b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2325.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2325.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Non-overridable methods (<code>private</code> or <code>final</code>) that don’t access instance data can be <code>static</code> to prevent any
 misunderstanding about the contract of the method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Utilities {
   private static String magicWord = "magic";
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Utilities {
   private static String magicWord = "magic";
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>When <code>java.io.Serializable</code> is implemented the following three methods are excluded by the rule:</p>
 <ul>
   <li> <code>private void writeObject(java.io.ObjectOutputStream out) throws IOException;</code> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2326.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2326.html
index 7dbe2410245..e48e89425cf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2326.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2326.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Type parameters that aren’t used are dead code, which can only distract and possibly confuse developers during maintenance. Therefore, unused type
 parameters should be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int &lt;T&gt; Add(int a, int b) // Noncompliant; &lt;T&gt; is ignored
 {
   return a + b;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int Add(int a, int b)
 {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2333.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2333.html
index 4d3006784cb..93ed720f251 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2333.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2333.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The methods declared in an <code>interface</code> are <code>public</code> and <code>abstract</code> by default. Any variables are automatically
 <code>public static final</code>. Finally, <code>class</code> and <code>interface</code> are automatically <code>public static</code>. There is no
 need to explicitly declare them so.</p>
@@ -5,13 +6,13 @@
 <p>Similarly, the <code>final</code> modifier is redundant on any method of a <code>final</code> class, <code>private</code> is redundant on the
 constructor of an <code>Enum</code>, and <code>static</code> is redundant for <code>interface</code> nested into a <code>class</code> or
 <code>enum</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public interface Vehicle {
 
   public void go(int speed, Direction direction);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public interface Vehicle {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.html
index 47db4b5687d..9221bac7efc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.html
@@ -1,9 +1,10 @@
-<p>Mutable objects are those whose state can be changed. For instance, an array is mutable, but a String is not. Mutable class members should never be
-returned to a caller or accepted and stored directly. Doing so leaves you vulnerable to unexpected changes in your class state.</p>
+<h2>Why is this an issue?</h2>
+<p>Mutable objects are those whose state can be changed. For instance, an array is mutable, but a String is not. Private mutable class members should
+never be returned to a caller or accepted and stored directly. Doing so leaves you vulnerable to unexpected changes in your class state.</p>
 <p>Instead use an unmodifiable <code>Collection</code> (via <code>Collections.unmodifiableCollection</code>,
 <code>Collections.unmodifiableList</code>, …​) or make a copy of the mutable object, and store or return the copy instead.</p>
-<p>This rule checks that arrays, collections and Dates are not stored or returned directly.</p>
-<h2>Noncompliant Code Example</h2>
+<p>This rule checks that private arrays, collections and Dates are not stored or returned directly.</p>
+<h3>Noncompliant code example</h3>
 <pre>
 class A {
   private String [] strings;
@@ -30,7 +31,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class A {
   private String [] strings;
@@ -57,7 +58,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/374">MITRE, CWE-374</a> - Passing Mutable Objects to an Untrusted Method </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/375">MITRE, CWE-375</a> - Returning a Mutable Object to an Untrusted Caller </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.json
index 3673ed506e0..75b1c0dd05a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2384.json
@@ -1,5 +1,5 @@
 {
-  "title": "Mutable members should not be stored or returned directly",
+  "title": "Private mutable members should not be stored or returned directly",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2386.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2386.html
index 06c08ca3927..79a35f82926 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2386.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2386.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There is no good reason to have a mutable object as the <code>public</code> (by default), <code>static</code> member of an <code>interface</code>.
 Such variables should be moved into classes and their visibility lowered.</p>
 <p>Similarly, mutable <code>static</code> members of classes and enumerations which are accessed directly, rather than through getters and setters,
@@ -5,7 +6,7 @@
 <p>Note that making a mutable field, such as an array, <code>final</code> will keep the variable from being reassigned, but doing so has no effect on
 the mutability of the internal state of the array (i.e. it doesn’t accomplish the goal).</p>
 <p>This rule raises issues for <code>public static</code> array, <code>Collection</code>, <code>Date</code>, and <code>awt.Point</code> members.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public interface MyInterface {
   public static String [] strings; // Noncompliant
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/582">MITRE, CWE-582</a> - Array Declared Public, Final, and Static </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/607">MITRE, CWE-607</a> - Public Static Final Field References Mutable Object </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2387.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2387.html
index a07b94d5ff2..36496e8574e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2387.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2387.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Having a variable with the same name in two unrelated classes is fine, but do the same thing within a class hierarchy and you’ll get confusion at
 best, chaos at worst.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit {
   protected Season ripe;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   private static Color FLESH; // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit {
   protected Season ripe;
@@ -29,7 +30,7 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule ignores same-name fields that are <code>static</code> in both the parent and child classes. This rule ignores <code>private</code> parent
 class fields, but in all other such cases, the child class field should be renamed.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2388.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2388.html
index e474dc1b96b..62d551fbe6f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2388.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2388.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When an inner class extends another class, and both its outer class and its parent class have a method with the same name, calls to that method can
 be confusing. The compiler will resolve the call to the superclass method, but maintainers may be confused, so the superclass method should be called
 explicitly, using <code>super.</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Parent {
   public void foo() { ... }
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Parent {
   public void foo() { ... }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
index 35f4a4a7765..067219e1aa8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When a parent class references a member of a subclass during its own initialization, the results might not be what you expect because the child
 class might not have been initialized yet. This could create what is known as an "initialisation cycle", or even a deadlock in some extreme cases.</p>
 <p>To make things worse, these issues are very hard to diagnose so it is highly recommended you avoid creating this kind of dependencies.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Parent {
   static int field1 = Child.method(); // Noncompliant
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.securecoding.cert.org/confluence/display/java/DCL00-J.+Prevent+class+initialization+cycles">CERT, DCL00-J.</a> - Prevent
   class initialization cycles </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.html
index 5918b10e7a1..3393be30b7d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Certain bit operations are just silly and should not be performed because their results are predictable.</p>
 <p>Specifically, using <code>&amp; -1</code> with any value will always result in the original value, as will <code>anyValue ^ 0</code> and
 <code>anyValue | 0</code>.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
index 0b977bbf95d..af44e9bfd97 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>While it is technically correct to use a <code>Thread</code> where a <code>Runnable</code> is called for, the semantics of the two objects are
 different, and mixing them is a bad practice that will likely lead to headaches in the future.</p>
 <p>The crux of the issue is that <code>Thread</code> is a larger concept than <code>Runnable</code>. A <code>Runnable</code> is an object whose
 running should be managed. A <code>Thread</code> expects to manage the running of itself or other <code>Runnables</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 	public static void main(String[] args) {
 		Thread r =new Thread() {
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
 		};
 		new Thread(r).start();  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 	public static void main(String[] args) {
 		Runnable r =new Runnable() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2440.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2440.html
index d1351ce7042..14bcfe99fc2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2440.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2440.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p><code>static</code> methods can be accessed without an instance of the enclosing class, so there’s no reason to instantiate a class that has only
 <code>static</code> methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class TextUtils {
   public static String stripHtml(String source) {
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class TextUtils {
   public static String stripHtml(String source) {
@@ -40,7 +41,8 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See Also</h2>
+<h2>Resources</h2>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S1118} - Utility classes should not have public constructors </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
index 7b01b65a807..258aa22c68c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>If you have no intention of writting an <code>HttpSession</code> object to file, then storing non-<code>serializable</code> objects in it may not
 seem like a big deal. But whether or not you explicitly serialize the session, it may be written to disk anyway, as the server manages its memory use
 in a process called "passivation". Further, some servers automatically write their active sessions out to file at shutdown &amp; deserialize any such
 sessions at startup.</p>
 <p>The point is, that even though <code>HttpSession</code> does not <code>extend Serializable</code>, you must nonetheless assume that it will be
 serialized, and understand that if you’ve stored non-serializable objects in the session, errors will result.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Address {
   //...
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
 HttpSession session = request.getSession();
 session.setAttribute("address", new Address());  // Noncompliant; Address isn't serializable
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/579">MITRE, CWE-579</a> - J2EE Bad Practices: Non-serializable Object Stored in Session </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
index 3893fb8dc9e..2a186cd9ad0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
@@ -1,20 +1,21 @@
+<h2>Why is this an issue?</h2>
 <p><code>java.util.concurrent.locks.Lock</code> offers far more powerful and flexible locking operations than are available with
 <code>synchronized</code> blocks. So synchronizing on a <code>Lock</code> throws away the power of the object, and is just silly. Instead, such
 objects should be locked and unlocked using <code>tryLock()</code> and <code>unlock()</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Lock lock = new MyLockImpl();
 synchronized(lock) {  // Noncompliant
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Lock lock = new MyLockImpl();
 lock.tryLock();
 //...
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/qjdGBQ">CERT, LCK03-J.</a> - Do not synchronize on the intrinsic locks of high-level concurrency
   objects </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2444.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2444.html
index abec34eec7a..e3b185205c2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2444.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2444.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>In a multi-threaded situation, un-<code>synchronized</code> lazy initialization of static fields could mean that a second thread has access to a
 half-initialized object while the first thread is still creating it. Allowing such access could cause serious bugs. Instead. the initialization block
 should be <code>synchronized</code>.</p>
 <p>Similarly, updates of such fields should also be <code>synchronized</code>.</p>
 <p>This rule raises an issue whenever a lazy static initialization is done on a class with at least one <code>synchronized</code> method, indicating
 intended usage in multi-threaded applications.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private static Properties fPreferences = null;
 
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private static Properties fPreferences = null;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
index 56698c76a70..1b2f7ce09af 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Synchronizing on a class field synchronizes not on the field itself, but on the object assigned to it. So synchronizing on a non-<code>final</code>
 field makes it possible for the field’s value to change while a thread is in a block synchronized on the old value. That would allow a second thread,
 synchronized on the new value, to enter the block at the same time.</p>
 <p>The story is very similar for synchronizing on parameters; two different threads running the method in parallel could pass two different object
 instances in to the method as parameters, completely undermining the synchronization.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private String color = "red";
 
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private String color = "red";
 private final Object lockObj = new Object();
@@ -31,7 +32,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/412">MITRE, CWE-412</a> - Unrestricted Externally Accessible Lock </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/413">MITRE, CWE-413</a> - Improper Resource Locking </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
index b1ecb319063..210809a6078 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p><code>notify</code> and <code>notifyAll</code> both wake up sleeping threads, but <code>notify</code> only rouses one, while <code>notifyAll</code>
 rouses all of them. Since <code>notify</code> might not wake up the right thread, <code>notifyAll</code> should be used instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyThread extends Thread{
 
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyThread extends Thread{
 
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/MTdGBQ">CERT, THI02-J.</a> - Notify all waiting threads rather than a single thread </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
index 52fc3f289e3..73ed54d3a45 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>While <code>null</code> is technically a valid <code>Boolean</code> value, that fact, and the distinction between <code>Boolean</code> and
 <code>boolean</code> is easy to forget. So returning <code>null</code> from a <code>Boolean</code> method is likely to cause problems with callers'
 code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public Boolean isUsable() {
   // ...
   return null;  // Noncompliant
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/476">MITRE, CWE-476</a> - NULL Pointer Dereference </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/aDdGBQ">CERT, EXP01-J.</a> - Do not use a null in a case where an object is required </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2479.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2479.html
index 56001ce2436..09051ad510d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2479.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2479.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Non-encoded control characters and whitespace characters are often injected in the source code because of a bad manipulation. They are either
 invisible or difficult to recognize, which can result in bugs when the string is not what the developer expects. If you actually need to use a control
 character use their encoded version (ex: ASCII <code>\n,\t,</code>…​ or Unicode <code>U+000D, U+0009,</code>…​).</p>
@@ -9,13 +10,13 @@
   <li> Unicode characters <code>U+200B, U+200C, U+200D, U+2060, U+FEFF, U+2028, U+2029</code> </li>
 </ul>
 <p>No issue will be raised on the simple space character. Unicode <code>U+0020</code>, ASCII 32.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String tabInside = "A	B";  // Noncompliant, contains a tabulation
 String zeroWidthSpaceInside = "foo​bar"; // Noncompliant, it contains a U+200B character inside
 char tab = '	';
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String tabInside = "A\tB";  // Compliant, uses escaped value
 String zeroWidthSpaceInside = "foo\u200Bbar";  // Compliant, uses escaped value
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
index 251d22f2adc..f1953883f94 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Conditional expressions which are always <code>true</code> or <code>false</code> can lead to dead code. Such code is always buggy and should never
 be used in production.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 a = false;
 if (a) { // Noncompliant
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   doSomethingElse(); // never executed
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule will not raise an issue in either of these cases:</p>
 <ul>
   <li> When the condition is a single <code>final boolean</code> </li>
@@ -34,7 +35,7 @@ <h2>Exceptions</h2>
 }
 </pre>
 <p>In these cases it is obvious the code is as intended.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/570">MITRE, CWE-570</a> - Expression is Always False </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/571">MITRE, CWE-571</a> - Expression is Always True </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2589.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2589.html
index b3adbb53b4f..8e1febad831 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2589.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2589.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>If a boolean expression doesn’t change the evaluation of the condition, then it is entirely unnecessary, and can be removed. If it is gratuitous
 because it does not match the programmer’s intent, then it’s a bug and the expression should be fixed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 a = true;
 if (a) { // Noncompliant
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   doSomething();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 a = true;
 if (foo(a)) {
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
   doSomething();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/571">MITRE, CWE-571</a> - Expression is Always True </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/570">MITRE, CWE-570</a> - Expression is Always False </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
index ea632b5334f..d914c824b40 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Passing message arguments that require further evaluation into a Guava <code>com.google.common.base.Preconditions</code> check can result in a
 performance penalty. That’s because whether or not they’re needed, each argument must be resolved before the method is actually called.</p>
 <p>Similarly, passing concatenated strings into a logging method can also incur a needless performance hit because the concatenation will be performed
@@ -6,7 +7,7 @@
 calls.</p>
 <p>Specifically, the built-in string formatting should be used instead of string concatenation, and if the message is the result of a method call,
 then <code>Preconditions</code> should be skipped altogether, and the relevant exception should be conditionally thrown instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 logger.log(Level.DEBUG, "Something went wrong: " + message);  // Noncompliant; string concatenation performed even when log level too high to show DEBUG messages
 
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
 
 Preconditions.checkState(condition, "message: %s", formatMessage());  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 logger.log(Level.SEVERE, "Something went wrong: {0} ", message);  // String formatting only applied if needed
 
@@ -44,7 +45,7 @@ <h2>Compliant Solution</h2>
   throw new IllegalStateException("message: " + formatMessage());
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>catch</code> blocks are ignored, because the performance penalty is unimportant on exceptional paths (catch block should not be a part of
 standard program flow). Getters are ignored as well as methods called on annotations which can be considered as getters. This rule accounts for
 explicit test-level testing with SLF4J methods <code>isXXXEnabled</code> and ignores the bodies of such <code>if</code> statements.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2637.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2637.html
index 27513406124..c1629dc3e54 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2637.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2637.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Fields, parameters and return values marked <code>@NotNull</code>, <code>@NonNull</code>, or <code>@Nonnull</code> are assumed to have non-null
 values and are not typically null-checked before use. Therefore setting one of these values to <code>null</code>, or failing to set such a class field
 in a constructor, could cause <code>NullPointerException</code>s at runtime.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MainClass {
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
     return mix;  // Noncompliant; return value is Nonnull, but null is returned.
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/476">MITRE, CWE-476</a> - NULL Pointer Dereference </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/aDdGBQ">CERT, EXP01-J.</a> - Do not use a null in a case where an object is required </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2638.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2638.html
index fe26796a425..a77ab90674f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2638.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2638.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Because a subclass instance may be cast to and treated as an instance of the superclass, overriding methods should uphold the aspects of the
 superclass contract that relate to the Liskov Substitution Principle. Specifically, if the parameters or return type of the superclass method are
 marked with any of the following: <code>@Nullable</code>, <code>@CheckForNull</code>, <code>@NotNull</code>, <code>@NonNull</code>, and
 <code>@Nonnull</code>, then subclass parameters are not allowed to tighten the contract, and return values are not allowed to loosen it.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit {
 
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Wikipedia - Liskov substitution principle</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2639.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2639.html
index 50b85c330af..0c9bd17b93f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2639.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2639.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Regular expressions are powerful but tricky, and even those long used to using them can make mistakes.</p>
 <p>The following should not be used as regular expressions:</p>
 <ul>
@@ -5,7 +6,7 @@
   <li> <code>|</code> - normally used as an option delimiter. Used stand-alone, it matches the space between characters </li>
   <li> <code>File.separator</code> - matches the platform-specific file path delimiter. On Windows, this will be taken as an escape character </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String str = "/File|Name.txt";
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2647.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2647.html
index a151ba8cf60..458db88efee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2647.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2647.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Basic authentication’s only means of obfuscation is Base64 encoding. Since Base64 encoding is easily recognized and reversed, it offers only the
 thinnest veil of protection to your users, and should not be used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // Using HttpPost from Apache HttpClient
 String encoding = Base64Encoder.encode ("login:passwd");
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
 conn.setDoOutput(true);
 conn.setRequestProperty("Authorization", "Basic " + encoding); // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2658.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2658.html
index 8b6acf79af9..49c45db29c2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2658.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2658.html
@@ -1,17 +1,17 @@
+<p>This rule is deprecated; use {rule:javasecurity:S6173} instead.</p>
+<h2>Why is this an issue?</h2>
 <p>Dynamically loaded classes could contain malicious code executed by a static class initializer. I.E. you wouldn’t even have to instantiate or
 explicitly invoke methods on such classes to be vulnerable to an attack.</p>
 <p>This rule raises an issue for each use of dynamic class loading.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String className = System.getProperty("messageClassName");
 Class clazz = Class.forName(className);  // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/470">MITRE, CWE-470</a> - Use of Externally-Controlled Input to Select Classes or Code ('Unsafe
   Reflection') </li>
 </ul>
-<h2>Deprecated</h2>
-<p>This rule is deprecated; use {rule:javasecurity:S6173} instead.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2674.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2674.html
index 2886e103037..4831e051a12 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2674.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2674.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>You cannot assume that any given stream reading call will fill the <code>byte[]</code> passed in to the method. Instead, you must check the value
 returned by the read method to see how many bytes were read. Fail to do so, and you introduce bug that is both harmful and difficult to reproduce.</p>
 <p>Similarly, you cannot assume that <code>InputStream.skip</code> will actually skip the requested number of bytes, but must check the value returned
@@ -5,7 +6,7 @@
 <p>This rule raises an issue when an <code>InputStream.read</code> method that accepts a <code>byte[]</code> is called, but the return value is not
 checked, and when the return value of <code>InputStream.skip</code> is not checked. The rule also applies to <code>InputStream</code> child
 classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(String fileName) {
   try {
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   } catch (IOException e) { ... }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(String fileName) {
   try {
@@ -29,7 +30,7 @@ <h2>Compliant Solution</h2>
   } catch (IOException e) { ... }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/VzdGBQ">CERT, FIO10-J.</a> - Ensure the array is filled when using read() to fill an array </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2675.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2675.html
index a4cd3a17130..dcc7deae0d3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2675.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2675.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>readObject</code> method is written when a <code>Serializable</code> object needs special handling to be rehydrated from file. It should be
 the case that the object being created by <code>readObject</code> is only visible to the thread that invoked the method, and the
 <code>synchronized</code> keyword is not needed, and using <code>synchronized</code> anyway is just confusing. If this is not the case, the method
 should be refactored to make it the case.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private synchronized void readObject(java.io.ObjectInputStream in)
      throws IOException, ClassNotFoundException { // Noncompliant
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private void readObject(java.io.ObjectInputStream in)
      throws IOException, ClassNotFoundException { // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2676.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2676.html
index 716501979b5..d7c63286bbb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2676.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2676.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>It is possible for a call to <code>hashCode</code> to return <code>Integer.MIN_VALUE</code>. Take the absolute value of such a hashcode and you’ll
 still have a negative number. Since your code is likely to assume that it’s a positive value instead, your results will be unreliable.</p>
 <p>Similarly, <code>Integer.MIN_VALUE</code> could be returned from <code>Random.nextInt()</code> or any object’s <code>compareTo</code> method, and
 <code>Long.MIN_VALUE</code> could be returned from <code>Random.nextLong()</code>. Calling <code>Math.abs</code> on values returned from these methods
 is similarly ill-advised.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(String str) {
   if (Math.abs(str.hashCode()) &gt; 0) { // Noncompliant
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(String str) {
   if (str.hashCode() != 0) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2677.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2677.html
index e855cf81314..0d7aea7e023 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2677.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2677.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>When a method is called that returns data read from some data source, that data should be stored rather than thrown away. Any other course of
 action is surely a bug.</p>
 <p>This rule raises an issue when the return value of any of the following is ignored or merely null-checked: <code>BufferedReader.readLine()</code>,
 <code>Reader.read()</code>, and these methods in any child classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomethingWithFile(String fileName) {
   BufferedReader buffReader = null;
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomethingWithFile(String fileName) {
   BufferedReader buffReader = null;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
index d9ea8704745..684e83d9a94 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Curly braces can be omitted from a one-line block, such as with an <code>if</code> statement or <code>for</code> loop, but doing so can be
 misleading and induce bugs.</p>
 <p>This rule raises an issue when the whitespacing of the lines after a one line block indicates an intent to include those lines in the block, but
 the omission of curly braces means the lines will be unconditionally executed once.</p>
 <p>Note that this rule considers tab characters to be equivalent to 1 space. If you mix spaces and tabs you will sometimes see issues in code which
 look fine in your editor but are confusing when you change the size of tabs.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (condition)
   firstActionInBlock();
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
   str = array[i];
   doTheThing(str);  // Noncompliant; executed only on last array element
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (condition) {
   firstActionInBlock();
@@ -37,7 +38,7 @@ <h2>Compliant Solution</h2>
   doTheThing(str);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/483">MITRE, CWE-483</a> - Incorrect Block Delimitation </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/MzZGBQ">CERT, EXP52-J.</a> - Use braces for the body of an if, for, or while statement </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2689.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2689.html
index ae234c08c4a..6045f2130bd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2689.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2689.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p><code>ObjectOutputStream</code>s are used with serialization, and the first thing an <code>ObjectOutputStream</code> writes is the serialization
 stream header. This header should appear once per file, at the beginning. Pass a file opened in append mode into an <code>ObjectOutputStream</code>
 constructor and the serialization stream header will be added to the end of the file before your object is then also appended.</p>
 <p>When you’re trying to read your object(s) back from the file, only the first one will be read successfully, and a
 <code>StreamCorruptedException</code> will be thrown after that.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 FileOutputStream fos = new FileOutputStream (fileName , true);  // fos opened in append mode
 ObjectOutputStream out = new ObjectOutputStream(fos);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 FileOutputStream fos = new FileOutputStream (fileName);
 ObjectOutputStream out = new ObjectOutputStream(fos);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
index 1e7fa097df5..034d1ecfa67 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Most checks against an <code>indexOf</code> value compare it with -1 because 0 is a valid index. Any checks which look for values &gt;0 ignore the
 first element, which is likely a bug. If the intent is merely to check inclusion of a value in a <code>String</code> or a <code>List</code>, consider
 using the <code>contains</code> method instead.</p>
 <p>This rule raises an issue when an <code>indexOf</code> value retrieved either from a <code>String</code> or a <code>List</code> is tested against
 <code>&gt;0</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String color = "blue";
 String name = "ishmael";
@@ -22,7 +23,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String color = "blue";
 String name = "ishmael";
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2693.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2693.html
index a4cafa8da15..22c27727423 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2693.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2693.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The problem with invoking <code>Thread.start()</code> in a constructor is that you’ll have a confusing mess on your hands if the class is ever
 extended because the superclass' constructor will start the thread before the child class has truly been initialized.</p>
 <p>This rule raises an issue any time <code>start</code> is invoked in the constructor of a non-<code>final</code> class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/FDdGBQ">CERT, TSM02-J.</a> - Do not use background threads during class initialization </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2694.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2694.html
index fd765c07b60..17138c17dd2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2694.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2694.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A non-static inner class has a reference to its outer class, and access to the outer class' fields and methods. That class reference makes the
 inner class larger and could cause the outer class instance to live in memory longer than necessary.</p>
 <p>If the reference to the outer class isn’t used, it is more efficient to make the inner class <code>static</code> (also called nested). If the
@@ -9,7 +10,7 @@
   <li> an inner class can only be instantiated within the context of an instance of the outer class. </li>
   <li> a nested (<code>static</code>) class can be instantiated independently of the outer class. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Fruit {
   // ...
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Fruit {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2695.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2695.html
index 826bee47bc6..4fb96cc3f9f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2695.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2695.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The parameters in a <code>PreparedStatement</code> are indexed beginning at 1, not 0, so using any "set" method of a <code>PreparedStatement</code>
 with a number less than 1 is a bug, as is using an index higher than the number of parameters. The same indexing style also applies to
 <code>ResultSet</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 PreparedStatement ps = con.prepareStatement("SELECT fname, lname FROM employees where hireDate &gt; ? and salary &lt; ?");
 ps.setDate(0, date);  // Noncompliant
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 PreparedStatement ps = con.prepareStatement("SELECT fname, lname FROM employees where hireDate &gt; ? and salary &lt; ?");
 ps.setDate(1, date);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2696.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2696.html
index 2d5fd0907eb..f19499f6052 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2696.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2696.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Correctly updating a <code>static</code> field from a non-static method is tricky to get right and could easily lead to bugs if there are multiple
 class instances and/or multiple threads in play. Ideally, <code>static</code> fields are only updated from <code>synchronized static</code>
 methods.</p>
 <p>This rule raises an issue each time a <code>static</code> field is updated from a non-static method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2698.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2698.html
index 060dd0a7915..ca08e333e18 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2698.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2698.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Adding messages to JUnit, FEST and AssertJ assertions is an investment in your future productivity. Spend a few seconds writing them now, and
 you’ll save a lot of time on the other end when either the tests fail and you need to quickly diagnose the problem, or when you need to maintain the
 tests and the assertion messages work as a sort of documentation.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertEquals(4, list.size());  // Noncompliant
 
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   assertThat(list.get(0)).isEqualTo("pear");  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertEquals("There should have been 4 Fruits in the list", 4, list.size());
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2699.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2699.html
index 75f9643270c..f9611040070 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2699.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2699.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A test case without assertions ensures only that no exceptions are thrown. Beyond basic runnability, it ensures nothing about the behavior of the
 code under test.</p>
 <p>This rule raises an exception when no assertions from any of the following known frameworks are found in a test:</p>
@@ -25,7 +26,7 @@
 <code>&lt;FullyQualifiedClassName&gt;#&lt;MethodName&gt;</code>, where <code>MethodName</code> can end with the wildcard character. For constructors,
 the pattern should be <code>&lt;FullyQualifiedClassName&gt;#&lt;init&gt;</code>.</p>
 <p>Example:&nbsp;<code>com.company.CompareToTester#compare*,com.company.CustomAssert#customAssertMethod,com.company.CheckVerifier#&lt;init&gt;</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void testDoSomething() {  // Noncompliant
@@ -33,7 +34,7 @@ <h2>Noncompliant Code Example</h2>
   myClass.doSomething();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Example when <code>com.company.CompareToTester#compare*</code> is used as parameter to the rule.</p>
 <pre>
 import com.company.CompareToTester;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2701.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2701.html
index 49a940d470f..75aca2cbad9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2701.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2701.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no reason to use literal boolean values or nulls in assertions. Instead of using them with <em>assertEquals</em>, <em>assertNotEquals</em>
 and similar methods, you should be using <em>assertTrue</em>, <em>assertFalse</em>, <em>assertNull</em> or <em>assertNotNull</em> instead (or
 <em>isNull</em> etc. when using Fest). Using them with assertions unrelated to equality (such as <em>assertNull</em>) is most likely a bug.</p>
@@ -8,7 +9,7 @@
   <li> JUnit5 </li>
   <li> Fest assert </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Assert.assertTrue(true);  // Noncompliant
 assertThat(null).isNull(); // Noncompliant
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
 assertEquals(true, something()); // Noncompliant
 assertNotEquals(null, something()); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertTrue(something());
 assertNotNull(something());
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2718.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2718.html
index 3d7bbce0e8e..554d7e66423 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2718.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2718.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>The use of the <code>ZonedDateTime</code> class introduced in Java 8 to truncate a date can be significantly faster than the <code>DateUtils</code>
 class from Commons Lang.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public Date trunc(Date date) {
   return DateUtils.truncate(date, Calendar.SECOND);  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public Date trunc(Date date) {
   Instant instant = date.toInstant();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2737.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2737.html
index fd2e52e7fd8..290b0ea9e7f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2737.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2737.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>catch</code> clause that only rethrows the caught exception has the same effect as omitting the <code>catch</code> altogether and letting
 it bubble up automatically, but with more code and the additional detriment of leaving maintainers scratching their heads.</p>
 <p>Such clauses should either be eliminated or populated with the appropriate logic.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String readFile(File f) {
   StringBuilder sb = new StringBuilder();
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   return sb.toString();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public String readFile(File f) {
   StringBuilder sb = new StringBuilder();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2755.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2755.html
index 4705531a01d..f1cc822ef78 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2755.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2755.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>XML standard allows the use of entities, declared in the DOCTYPE of the document, which can be <a
 href="https://www.w3.org/TR/xml/#sec-internal-ent">internal</a> or <a href="https://www.w3.org/TR/xml/#sec-external-ent">external</a>.</p>
 <p>When parsing the XML file, the content of the external entities is retrieved from an external storage such as the file system or network, which may
@@ -10,9 +11,10 @@
   <li> If external entities are necessary then:
     <ul>
       <li> Use XML processor features, if available, to authorize only required protocols (eg: https). </li>
-      <li> And use an entity resolver (and optionally an XML Catalog) to resolve only trusted entities. == Noncompliant Code Example </li>
+      <li> And use an entity resolver (and optionally an XML Catalog) to resolve only trusted entities. </li>
     </ul>  </li>
 </ul>
+<h3>Noncompliant code example</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/stream/XMLInputFactory.html">XMLInput</a>, <a
@@ -37,7 +39,7 @@
 <pre>
 SAXBuilder builder = new SAXBuilder(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/stream/XMLInputFactory.html">XMLInput</a>, <a
@@ -101,7 +103,7 @@ <h2>Compliant Solution</h2>
 builder.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
 builder.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>
   <li> <a
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
index 174e495fbad..25a5641d3e5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>The use of operators pairs ( <code>=+</code>, <code>=-</code> or <code>=!</code> ) where the reversed, single operator was meant (<code>+=</code>,
 <code>-=</code> or <code>!=</code>) will compile and run, but not produce the expected results.</p>
 <p>This rule raises an issue when <code>=+</code>, <code>=-</code>, or <code>=!</code> is used without any spacing between the two operators and when
 there is at least one whitespace character after.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int target = -5;
 int num = 3;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
 target =- num;  // Noncompliant; target = -3. Is that really what's meant?
 target =+ num; // Noncompliant; target = 3
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int target = -5;
 int num = 3;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
index a467d2dd86d..3a00dc423d5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>The needless repetition of an operator is usually a typo. There is no reason to write <code>!!!i</code> when <code>!i</code> will do.</p>
 <p>On the other hand, the repetition of increment and decrement operators may have been done on purpose, but doing so obfuscates the meaning, and
 should be simplified.</p>
 <p>This rule raises an issue for sequences of: <code>!</code>, <code>~</code>, <code>-</code>, and <code>+</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int i = 1;
 
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 boolean b = false;
 boolean c = !!!b;   // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int i =  1;
 
@@ -24,6 +25,6 @@ <h2>Compliant Solution</h2>
 boolean b = false;
 boolean c = !b;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Overflow handling for GWT compilation using <code>~~</code> is ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2786.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2786.html
index d240f8749a7..43e68953880 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2786.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2786.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>According to <a href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9">the Java Language Specification-8.9</a>:</p>
 <blockquote>
   <p>Nested enum types are implicitly <code>static</code>.</p>
 </blockquote>
 <p>So there’s no need to declare them <code>static</code> explicitly.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Flower {
   static enum Color { // Noncompliant; static is redundant here
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Flower {
   enum Color { // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2789.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2789.html
index d2962124135..f1d6199df52 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2789.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2789.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The concept of <code>Optional</code> is that it will be used when <code>null</code> could cause errors. In a way, it replaces <code>null</code>,
 and when <code>Optional</code> is in use, there should never be a question of returning or receiving <code>null</code> from a call.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething () {
   Optional&lt;String&gt; optional = getOptional();
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   return null;  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething () {
   Optional&lt;String&gt; optional = getOptional();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2864.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2864.html
index 6584ebb780b..a81973ee5b1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2864.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2864.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When only the keys from a map are needed in a loop, iterating the <code>keySet</code> makes sense. But when both the key and the value are needed,
 it’s more efficient to iterate the <code>entrySet</code>, which will give access to both the key and value, instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomethingWithMap(Map&lt;String,Object&gt; map) {
   for (String key : map.keySet()) {  // Noncompliant; for each key the value is retrieved
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomethingWithMap(Map&lt;String,Object&gt; map) {
   for (Map.Entry&lt;String,Object&gt; entry : map.entrySet()) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2885.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2885.html
index f9032cb6554..1a779855195 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2885.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2885.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Not all classes in the standard Java library were written to be thread-safe. Using them in a multi-threaded manner is highly likely to cause data
 problems or exceptions at runtime.</p>
 <p>This rule raises an issue when an instance of <code>Calendar</code>, <code>DateFormat</code>, <code>javax.xml.xpath.XPath</code>, or
 <code>javax.xml.validation.SchemaFactory</code> is marked <code>static</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   private static SimpleDateFormat format = new SimpleDateFormat("HH-mm-ss");  // Noncompliant
   private static Calendar calendar = Calendar.getInstance();  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   private SimpleDateFormat format = new SimpleDateFormat("HH-mm-ss");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2886.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2886.html
index f2aaab342cc..5e32212f804 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2886.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2886.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When one part of a getter/setter pair is <code>synchronized</code> the other part should be too. Failure to synchronize both sides of a pair may
 result in inconsistent behavior at runtime as callers access an inconsistent method state.</p>
 <p>This rule raises an issue when either the method or the contents of one method in a getter/setter pair are synchrnoized but the other is not.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Person {
   String name;
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Person {
   String name;
@@ -53,7 +54,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jdGBQ">CERT, VNA01-J.</a> - Ensure visibility of shared references to immutable objects </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2924.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2924.html
index 257bd68d9e4..7645b0fc26f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2924.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2924.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>While some <code>TestRule</code> classes have the desired effect without ever being directly referenced by a test, several others do not, and
 there’s no reason to leave them cluttering up the file if they’re not in use.</p>
 <p>This rule raises an issue when <code>Test</code> class fields of the following types aren’t used by any of the test methods:
 <code>TemporaryFolder</code>, and <code>TestName</code>.</p>
 <p>This rule also applies to the JUnit 5 equivalent classes: <code>TempDir</code>, and <code>TestInfo</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class ProjectDefinitionTest {
 
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class ProjectDefinitionTest {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.html
index 73dc3de54e5..d8ec81e05ac 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>Thread.sleep</code> in a test is just generally a bad idea. It creates brittle tests that can fail unpredictably depending on
 environment ("Passes on my machine!") or load. Don’t rely on timing (use mocks) or use libraries such as <code>Awaitility</code> for asynchroneous
 testing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void testDoTheThing(){
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   // assertions...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void testDoTheThing(){
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2959.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2959.html
index 66592d281e5..d25352241b7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2959.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2959.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Under the reasoning that cleaner code is better code, the semicolon at the end of a try-with-resources construct should be omitted because it can
 be omitted.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try (ByteArrayInputStream b = new ByteArrayInputStream(new byte[10]);  // ignored; this one's required
       Reader r = new InputStreamReader(b);)   // Noncompliant
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
    //do stuff
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try (ByteArrayInputStream b = new ByteArrayInputStream(new byte[10]);
       Reader r = new InputStreamReader(b))
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2970.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2970.html
index 4676a8d622d..961850c2ff1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2970.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2970.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>It is very easy to write incomplete assertions when using some test frameworks. This rule enforces complete assertions in the following cases:</p>
 <ul>
   <li> Fest: <code>assertThat</code> is not followed by an assertion invocation </li>
@@ -6,7 +7,7 @@
   <li> Truth: <code>assertXXX</code> is not followed by an assertion invocation </li>
 </ul>
 <p>In such cases, what is intended to be a test doesn’t actually verify anything</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // Fest
 boolean result = performAction();
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
 // let's check that "add" and "clear" methods are actually called
 Mockito.verify(mockedList); // Noncompliant; nothing is checked here, oups no call is chained to verify()
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // Fest
 boolean result = performAction();
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
 Mockito.verify(mockedList).add("one");
 Mockito.verify(mockedList).clear();
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Variable assignments and return statements are skipped to allow helper methods.</p>
 <pre>
 private BooleanAssert check(String filename, String key) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2972.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2972.html
index a1f45338750..94806f58e72 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2972.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2972.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Inner classes should be short and sweet, to manage complexity in the overall file. An inner class that has grown longer than a certain threshold
 should probably be externalized to its own file.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2973.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2973.html
index a0a050258ba..4a630448175 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2973.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2973.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>The use of Unicode escape sequences should be reserved for characters that would otherwise be ambiguous, such as unprintable characters.</p>
 <p>This rule ignores sequences composed entirely of Unicode characters, but otherwise raises an issue for each Unicode character that represents a
 printable character.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String prefix = "n\u00E9e"; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String prefix = "née";
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2974.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2974.html
index c9762a807f3..096e3c9e30a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2974.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2974.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Classes with only <code>private</code> constructors should be marked <code>final</code> to prevent any mistaken extension attempts.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class PrivateConstructorClass {  // Noncompliant
   private PrivateConstructorClass() {
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public final class PrivateConstructorClass {  // Compliant
   private PrivateConstructorClass() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
index 2484a1e2a35..fc7fffddfa0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Many consider <code>clone</code> and <code>Cloneable</code> broken in Java, largely because the rules for overriding <code>clone</code> are tricky
 and difficult to get right, according to Joshua Bloch:</p>
 <blockquote>
@@ -9,7 +10,7 @@
 </blockquote>
 <p>A copy constructor or copy factory should be used instead.</p>
 <p>This rule raises an issue when <code>clone</code> is overridden, whether or not <code>Cloneable</code> is implemented.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   // ...
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   // ...
@@ -29,11 +30,11 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.artima.com/intv/bloch13.html">Copy Constructor versus Cloning</a> </li>
 </ul>
-<h3>See Also</h3>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S2157} - "Cloneables" should implement "clone" </li>
   <li> {rule:java:S1182} - Classes that override "clone" should be "Cloneable" and call "super.clone()" </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3008.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3008.html
index 38d94ec0cd0..e9e07a35830 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3008.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3008.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate efficiently. This rule checks that static non-final field names match a provided regular
 expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
 <pre>
 public final class MyClass {
    private static String foo_bar;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass {
    private static String fooBar;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3010.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3010.html
index 45ad5c06420..537d3577dac 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3010.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3010.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Assigning a value to a <code>static</code> field in a constructor could cause unreliable behavior at runtime since it will change the value for all
 instances of the class.</p>
 <p>Instead remove the field’s <code>static</code> modifier, or initialize it statically.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Person {
   static Date dateOfBirth;
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Person {
   Date dateOfBirth;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
index b296108b420..afbd05ec6dc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>This rule raises an issue when reflection is used to change the visibility of a class, method or field, and when it is used to directly update a
 field value. Altering or bypassing the accessibility of classes, methods, or fields violates the encapsulation principle and could lead to run-time
 errors.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void makeItPublic(String methodName) throws NoSuchMethodException {
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   this.getClass().getDeclaredField(fieldName).setInt(this, value); // Noncompliant; bypasses controls in setter
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/_jZGBQ">CERT, SEC05-J.</a> - Do not use reflection to increase accessibility of classes,
   methods, or fields </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3012.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3012.html
index ce5e97193ed..0343236a566 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3012.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3012.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Using a loop to copy an array or a subset of an array is simply wasted code when there are built-in functions to do it for you. Instead, use
 <code>Arrays.copyOf</code> to copy an entire array into another array, use <code>System.arraycopy</code> to copy only a subset of an array into
 another array, and use <code>Arrays.asList</code> to feed the constructor of a new list with an array.</p>
 <p>Note that <code>Arrays.asList</code> simply puts a <code>Collections</code> wrapper around the original array, so further steps are required if a
 non-fixed-size <code>List</code> is desired.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void makeCopies(String[] source) {
 
@@ -19,14 +20,14 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void makeCopies(String[] source) {
   this.array = Arrays.copyOf(source, source.length);
   Collections.addAll(this.list, source);
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Rule detects only the most idiomatic patterns, it will not consider loops with non-trivial control flow. For example, array elements that are
 copied conditionally are ignored.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3014.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3014.html
index 01b0c6074ac..c4cb7c1f5cd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3014.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3014.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>There is little valid reason to use the methods of the <code>ThreadGroup</code> class. Some are deprecated (<code>allowThreadSuspension()</code>,
 <code>resume()</code>, <code>stop()</code>, and <code>suspend()</code>), some are obsolete, others aren’t thread-safe, and still others are insecure
 (<code>activeCount()</code>, <code>enumerate()</code>) . For these reasons, any use of <code>ThreadGroup</code> is suspicious and should be
 avoided.</p>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ThreadFactory threadFactory = Executors.defaultThreadFactory();
 ThreadPoolExecutor executorPool = new ThreadPoolExecutor(3, 10, 5, TimeUnit.SECONDS, new ArrayBlockingQueue&lt;Runnable&gt;(2), threadFactory);
@@ -14,7 +15,7 @@ <h2>Compliant Solution</h2>
 System.out.println(executorPool.getActiveCount()); // Compliant
 executorPool.shutdown();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/YzdGBQ">CERT, THI01-J.</a> - Do not invoke ThreadGroup methods </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3020.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3020.html
index 7f2a71c1768..29d57d5dd9d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3020.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3020.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Given no arguments, the <code>Collections.toArray</code> method returns an <code>Object []</code>, which will cause a
 <code>ClassCastException</code> at runtime if you try to cast it to an array of the proper class. Instead, pass an array of the correct type in to the
 call.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String [] getStringArray(List&lt;String&gt; strings) {
   return (String []) strings.toArray();  // Noncompliant; ClassCastException thrown
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public String [] getStringArray(List&lt;String&gt; strings) {
   return strings.toArray(new String[0]);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3030.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3030.html
index b43c079bd04..da7b8602e5c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3030.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3030.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Importing a class statically allows you to use its <code>public static</code> members without qualifying them with the class name. That can be
 handy, but if you import too many classes statically, your code can become confusing and difficult to maintain.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold value: 4</p>
 <pre>
 import static java.lang.Math.*;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3032.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3032.html
index 098adf8766a..880be593e55 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3032.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3032.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Using the standard <code>getClassLoader()</code> may not return the <em>right</em> class loader in a JEE context. Instead, go through the
 <code>currentThread</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ClassLoader cl = this.getClass().getClassLoader();  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ClassLoader cl = Thread.currentThread().getContextClassLoader();
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3034.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3034.html
index 3fd87ab5abe..747e169ccc7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3034.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3034.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When reading bytes in order to build other primitive values such as <code>int</code>s or <code>long</code>s, the <code>byte</code> values are
 automatically promoted, but that promotion can have unexpected results.</p>
 <p>For instance, the binary representation of the integer 640 is <code>0b0000_0010_1000_0000</code>, which can also be written with the array of
@@ -8,7 +9,7 @@
 <p>To prevent such accidental value conversion, use bitwise and (<code>&amp;</code>) to combine the <code>byte</code> value with <code>0xff</code>
 (255) and turn all the higher bits back off.</p>
 <p>This rule raises an issue any time a <code>byte</code> value is used as an operand without <code>&amp; 0xff</code>, when combined with shifts.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   int intFromBuffer() {
     int result = 0;
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
     return result;
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
   int intFromBuffer() {
     int result = 0;
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
     return result;
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/kDZGBQ">CERT, NUM52-J.</a> - Be aware of numeric promotion behavior </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3038.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3038.html
index 8a13cc671f4..91b54603f61 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3038.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3038.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no point in redundantly defining an <code>abstract</code> method with the same signature as a method in an <code>interface</code> that the
 class <code>implements</code>. Any concrete child classes will have to implement the method either way.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public interface Reportable {
   String getReport();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3039.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3039.html
index 9e4111fa29c..1b5b559d688 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3039.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3039.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Just as you can’t cut something into three halves, you can’t grab a <code>substring</code> that starts or ends outside the original
 <code>String</code>'s bounds, you can’t use <code>substring</code> to get a reversed portion of a <code>String</code>, and you can’t get the
 <code>charAt</code> a value that’s before the <code>String</code> starts or after it ends.</p>
 <p>This rule detects when negative literal or <code>String::length</code> is passed as an argument to the <code>String::substring</code>,
 <code>String::charAt</code> and related methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String speech = "Now is the time for all good people to come to the aid of their country.";
 
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
 String substr2 = speech.substring(speech.length(), 0); // Noncompliant, start value must be &lt; end value
 char ch = speech.charAt(speech.length());  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String speech = "Now is the time for all good people to come to the aid of their country.";
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3042.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3042.html
index f3e884a0b07..f22d4e2a535 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3042.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3042.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>The purpose of synchronization is to ensure that only one thread executes a given block of code at a time. There’s no real problem with marking
 <code>writeObject</code> <code>synchronized</code>, but it’s highly suspicious if this serialization-related method is the only
 <code>synchronized</code> code in a <code>class</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class RubberBall {
 
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class RubberBall {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3046.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3046.html
index 84c855d90cf..9512d0abf79 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3046.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3046.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When two locks are held simultaneously, a <code>wait</code> call only releases one of them. The other will be held until some other thread requests
 a lock on the awaited object. If no unrelated code tries to lock on that object, then all other threads will be locked out, resulting in a
 deadlock.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 synchronized (this.mon1) {  // threadB can't enter this block to request this.mon2 lock &amp; release threadA
 	synchronized (this.mon2) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3047.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3047.html
index 48d7d44f268..51ec6b2f6dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3047.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3047.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When a method loops multiple over the same set of data, whether it’s a list or a set of numbers, it is highly likely that the method could be made
 more efficient by combining the loops into a single set of iterations.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomethingToAList(List&lt;String&gt; strings) {
   for (String str : strings) {
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomethingToAList(List&lt;String&gt; strings) {
   for (String str : strings) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3052.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3052.html
index 51d82cedf4b..f16f1510f81 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3052.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3052.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>The compiler automatically initializes class fields to their default values before setting them with any initialization values, so there is no need
 to explicitly set a field to its default value. Further, under the logic that cleaner code is better code, it’s considered poor style to do so.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
 
@@ -18,6 +19,6 @@ <h2>Compliant Solution</h2>
 
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>final</code> fields are ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3064.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3064.html
index 337e7fcfecf..3c1d32a91e9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3064.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3064.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Double-checked locking can be used for lazy initialization of <code>volatile</code> fields, but only if field assignment is the last step in the
 <code>synchronized</code> block. Otherwise you run the risk of threads accessing a half-initialized object.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
 
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
 
@@ -41,11 +42,11 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6zdGBQ">CERT, LCK10-J.</a> - Use a correct form of the double-checked locking idiom </li>
 </ul>
-<h3>See Also</h3>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S2168} - Double-checked locking should not be used </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3065.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3065.html
index 281e2cc1c1d..46280eb15eb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3065.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3065.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When using <code>Math.min()</code> and <code>Math.max()</code> together for bounds checking, it’s important to feed the right operands to each
 method. <code>Math.min()</code> should be used with the <strong>upper</strong> end of the range being checked, and <code>Math.max()</code> should be
 used with the <strong>lower</strong> end of the range. Get it backwards, and the result will always be the same end of the range.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   private static final int UPPER = 20;
   private static final int LOWER = 0;
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
     return Math.max(UPPER, result);     // Noncompliant; result is now 20: even though 12 was in the range
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Swapping method <code>min()</code> and <code>max()</code> invocations without changing parameters.</p>
 <pre>
   private static final int UPPER = 20;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3066.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3066.html
index 2893eab2d3b..1f79d73033e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3066.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3066.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>enum</code>s are generally thought of as constant, but an <code>enum</code> with a <code>public</code> field or <code>public</code> setter is
 non-constant. Ideally fields in an <code>enum</code> are <code>private</code> and set in the constructor, but if that’s not possible, their visibility
 should be reduced as much as possible.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public enum Continent {
 
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
     this.landMass = landMass;
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public enum Continent {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3067.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3067.html
index 9874e8e9277..717ff84d6fc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3067.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3067.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p><code>getClass</code> should not be used for synchronization in non-<code>final</code> classes because child classes will synchronize on a
 different object than the parent or each other, allowing multiple threads into the code block at once, despite the <code>synchronized</code>
 keyword.</p>
 <p>Instead, hard code the name of the class on which to synchronize or make the class <code>final</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   public void doSomethingSynchronized(){
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
     }
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   public void doSomethingSynchronized(){
@@ -20,7 +21,7 @@ <h2>Compliant Solution</h2>
     }
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/qTdGBQ">CERT, LCK02-J.</a> - Do not synchronize on the class object returned by getClass() </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3077.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3077.html
index 7666abc6f7a..a370e7f5ce1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3077.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3077.html
@@ -1,20 +1,21 @@
+<h2>Why is this an issue?</h2>
 <p>Marking an array <code>volatile</code> means that the array itself will always be read fresh and never thread cached, but the items <em>in</em> the
 array will not be. Similarly, marking a mutable object field <code>volatile</code> means the object <em>reference</em> is <code>volatile</code> but
 the object itself is not, and other threads may not see updates to the object state.</p>
 <p>This can be salvaged with arrays by using the relevant AtomicArray class, such as <code>AtomicIntegerArray</code>, instead. For mutable objects,
 the <code>volatile</code> should be removed, and some other method should be used to ensure thread-safety, such as synchronization, or ThreadLocal
 storage.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private volatile int [] vInts;  // Noncompliant
 private volatile MyObj myObj;  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private AtomicIntegerArray vInts;
 private MyObj myObj;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/UzdGBQ">CERT, CON50-J.</a> - Do not assume that declaring a reference volatile guarantees safe
   publication of the members of the referenced object </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3078.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3078.html
index 38f8a83857a..ca39afeec1c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3078.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3078.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Using compound operators as well as increments and decrements (and toggling, in the case of <code>boolean</code>s) on primitive fields are not
 atomic operations. That is, they don’t happen in a single step. For instance, when a <code>volatile</code> primitive field is incremented or
 decremented you run the risk of data loss if threads interleave in the steps of the update. Instead, use a guaranteed-atomic class such as
 <code>AtomicInteger</code>, or synchronize the access.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private volatile int count = 0;
 private volatile boolean boo = false;
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   boo = !boo;  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private AtomicInteger count = 0;
 private boolean boo = false;
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   boo = !boo;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/SjdGBQ">CERT, VNA02-J.</a> - Ensure that compound operations on shared variables are atomic
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3242.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3242.html
index 74bba9ab1c4..69c0bad783d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3242.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3242.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>For maximum reusability, methods should accept parameters with as little specialization as possible. So unless specific features from a child class
 are required by a method, a type higher up the class hierarchy should be used instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void printSize(ArrayList&lt;Object&gt; list) {  // Collection can be used instead
     System.out.println(list.size());
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void printSize(Collection&lt;?&gt; list) {  // Collection can be used instead
     System.out.println(list.size());
@@ -24,7 +25,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Parameters in non-public methods are not checked, because such methods are not intended to be generally reusable. <code>java.lang.String</code>
 parameters are excluded, because String is immutable and can not be always substituted for more generic type. Parameters used in any other context
 than method invocation or enhanced for loop are also excluded.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3252.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3252.html
index 8298759abf0..c941a87509b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3252.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3252.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>In the interest of code clarity, <code>static</code> members of a <code>base</code> class should never be accessed using a derived type’s name.
 Doing so is confusing and could create the illusion that two different static members exist.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class Parent {
   public static int counter;
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class Parent {
   public static int counter;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3254.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3254.html
index 41bb4649bd5..ab884114da5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3254.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3254.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Specifying the default value for an annotation parameter is redundant. Such values should be omitted in the interests of readability.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @MyAnnotation(arg = "def")  // Noncompliant
 public class MyClass {
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   String arg() default "def";
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @MyAnnotation
 public class MyClass {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3305.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3305.html
index 8fedb623c0b..8af0073a487 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3305.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3305.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>When <code>@Autowired</code> is used, dependencies need to be resolved when the class is instantiated, which may cause early initialization of
 beans or lead the context to look in places it shouldn’t to find the bean. To avoid this tricky issue and optimize the way the context loads,
 dependencies should be requested as late as possible. That means using parameter injection instead of field injection for dependencies that are only
 used in a single <code>@Bean</code> method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Configuration
 public class ​FooConfiguration {
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Configuration
 public class ​FooConfiguration {
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Fields used in methods that are called directly by other methods in the application (as opposed to being invoked automatically by the Spring
 framework) are ignored by this rule so that direct callers don’t have to provide the dependencies themselves.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3306.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3306.html
index 71443340d40..6f3c9286d60 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3306.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3306.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Field injection seems like a tidy way to get your classes what they need to do their jobs, but it’s really a <code>NullPointerException</code>
 waiting to happen unless all your class constructors are <code>private</code>. That’s because any class instances that are constructed by callers,
 rather than instantiated by a Dependency Injection framework compliant with the JSR-330 (Spring, Guice, …​), won’t have the ability to perform the
 field injection.</p>
 <p>Instead <code>@Inject</code> should be moved to the constructor and the fields required as constructor parameters.</p>
 <p>This rule raises an issue when classes with non-<code>private</code> constructors (including the default constructor) use field injection.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyComponent {  // Anyone can call the default constructor
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyComponent {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3329.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3329.html
index 7baff3829da..32fde96cdcf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3329.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3329.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>When encrypting data with the Cipher Block Chaining (CBC) mode an Initialization Vector (IV) is used to randomize the encryption, ie under a given
 key the same plaintext doesn’t always produce the same ciphertext. The IV doesn’t need to be secret but should be unpredictable to avoid
 "Chosen-Plaintext Attack".</p>
 <p>To generate Initialization Vectors, NIST recommends to use a secure random number generator.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void encrypt(String key, String plainText) throws GeneralSecurityException {
     byte[] bytesIV = "7cVgr5cbdCZVw5WY".getBytes(StandardCharsets.UTF_8); // secondary
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
     cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv); // Noncompliant
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void encrypt(String key, String plainText) throws GeneralSecurityException {
     SecureRandom random = new SecureRandom();
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
     cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv);
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3346.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3346.html
index 9f35e0cd4de..47d74fe1d08 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3346.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3346.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>Since <code>assert</code> statements aren’t executed by default (they must be enabled with JVM flags) developers should never rely on their
 execution the evaluation of any logic required for correct program function.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assert myList.remove(myList.get(0));  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 boolean removed = myList.remove(myList.get(0));
 assert removed;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/mjdGBQ">CERT, EXP06-J.</a> - Expressions used in assertions must not produce side effects </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
index 1c9d2f13109..b8678c63e32 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Just because you <em>can</em> do something, doesn’t mean you should, and that’s the case with nested ternary operations. Nesting ternary operators
 results in the kind of code that may seem clear as day when you write it, but six months later will leave maintainers (or worse - future you)
 scratching their heads and cursing.</p>
 <p>Instead, err on the side of clarity, and use another line to express the nested operation as a separate statement.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String getReadableStatus(Job j) {
   return j.isRunning() ? "Running" : j.hasErrors() ? "Failed" : "Succeeded";  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public String getReadableStatus(Job j) {
   if (j.isRunning()) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3366.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3366.html
index 340f9b1bd4f..faf0f6ef4d8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3366.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3366.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In single-threaded environments, the use of <code>this</code> in constructors is normal, and expected. But in multi-threaded environments, it could
 expose partially-constructed objects to other threads, and should be used with caution.</p>
 <p>The classic example is a class with a <code>static</code> list of its instances. If the constructor stores <code>this</code> in the list, another
@@ -6,7 +7,7 @@
 <code>this</code> is exposed.</p>
 <p>This rule raises an issue when <code>this</code> is assigned to any globally-visible object in a constructor, and when it is passed to the method
 of another object in a constructor</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Monument {
 
@@ -21,10 +22,10 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule ignores instances of assigning <code>this</code> directly to a <code>static</code> field of the same class because that case is covered
 by {rule:java:S3010} .</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/iDdGBQ">CERT, TSM01-J.</a> - Do not let the this reference escape during object construction
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3398.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3398.html
index ad78bdd7a84..3e55775ab93 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3398.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3398.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When a <code>private</code> method is only invoked by an inner class, there’s no reason not to move it into that class. It will still have the same
 access to the outer class' members, but the outer class will be clearer and less cluttered.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Outie {
   private int i=0;
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Outie {
   private int i=0;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3400.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3400.html
index d85d1271f74..51662c3336a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3400.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3400.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no point in forcing the overhead of a method call for a method that always returns the same constant value. Even worse, the fact that a
 method call must be made will likely mislead developers who call the method thinking that something more is done. Declare a constant instead.</p>
 <p>This rule raises an issue if on methods that contain only one statement: the <code>return</code> of a constant value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int getBestNumber() {
   return 12;  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 static final int BEST_NUMBER = 12;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The following types of method are ignored:</p>
 <ul>
   <li> methods that override a method. </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3414.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3414.html
index 6733e70dc8c..025ddf451e8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3414.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3414.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>It is a good practice to isolate test classes in a separate package so that what is shipped to production is neither polluted by nor bloated with
 them. Further, including unit tests in code assemblies could affect build processes.</p>
 <p>This rule raises an issue when test classes are found in projects containing non-test-related code.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3415.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3415.html
index 45e8cbe38dd..4f3971d9e79 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3415.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3415.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The standard assertions library methods such as <code>org.junit.Assert.assertEquals</code>, and <code>org.junit.Assert.assertSame</code> expect the
 first argument to be the expected value and the second argument to be the actual value. For AssertJ, it’s the other way around, the argument of
 <code>org.assertj.core.api.Assertions.assertThat</code> is the actual value, and the subsequent calls contain the expected values. Swap them, and your
@@ -9,12 +10,12 @@
   <li> JUnit5 </li>
   <li> <a href="https://assertj.github.io/doc/">AssertJ</a> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 org.junit.Assert.assertEquals(runner.exitCode(), 0, "Unexpected exit code");  // Noncompliant; Yields error message like: Expected:&lt;-1&gt;. Actual:&lt;0&gt;.
 org.assertj.core.api.Assertions.assertThat(0).isEqualTo(runner.exitCode()); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 org.junit.Assert.assertEquals(0, runner.exitCode(), "Unexpected exit code");
 org.assertj.core.api.Assertions.assertThat(runner.exitCode()).isEqualTo(0);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3416.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3416.html
index e7819e5dcb4..4ca861d2ce6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3416.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3416.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>It is convention to name each class’s logger for the class itself. Doing so allows you to set up clear, communicative logger configuration. Naming
 loggers by some other convention confuses configuration, and using the same class name for multiple class loggers prevents the granular configuration
 of each class' logger. Some libraries, such as SLF4J warn about this, but not all do.</p>
 <p>This rule raises an issue when a logger is not named for its enclosing class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
   private final static Logger LOG = LoggerFactory.getLogger(WrongClass.class);  // Noncompliant; multiple classes using same logger
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyClass {
   private final static Logger LOG = LoggerFactory.getLogger(MyClass.class);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3436.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3436.html
index b43e7950ff3..e7b6b85ce17 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3436.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3436.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the documentation,</p>
 <blockquote>
   <p>A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly
@@ -20,14 +21,14 @@
 <code>MinguoDate</code>, <code>ThaiBuddhistDate</code>; and the optional classes: <code>Optional</code>, <code>OptionalDouble</code>,
 <code>OptionalLong</code>, <code>OptionalInt</code>.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Optional&lt;Foo&gt; fOpt = doSomething();
 synchronized (fOpt) {  // Noncompliant
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html">Value-based classes</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3437.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3437.html
index 30ef042dd92..f1a303b159f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3437.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3437.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to the documentation,</p>
 <blockquote>
   <p>A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly
@@ -21,21 +22,21 @@
 <p>This rule raises an issue when a <code>Serializable</code> class defines a non-transient, non-static field field whose type is a known serializable
 value-based class. Known serializable value-based classes are: all the classes in the <code>java.time</code> package except <code>Clock</code>; the
 date classes for alternate calendars: <code>HijrahDate</code>, <code>JapaneseDate</code>, <code>MinguoDate</code>, <code>ThaiBuddhistDate</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyClass implements Serializable {
   private HijrahDate date;  // Noncompliant; mark this transient
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyClass implements Serializable {
   private transient HijrahDate date;
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html">Value-based classes</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3457.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3457.html
index 68d2ab8da27..3b6078840ae 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3457.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3457.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Because <code>printf</code>-style format strings are interpreted at runtime, rather than validated by the compiler, they can contain errors that
 result in the wrong strings being created. This rule statically validates the correlation of <code>printf</code>-style format strings to their
 arguments when calling the <code>format(...)</code> methods of <code>java.util.Formatter</code>, <code>java.lang.String</code>,
 <code>java.io.PrintStream</code>, <code>MessageFormat</code>, and <code>java.io.PrintWriter</code> classes and the <code>printf(...)</code> methods of
 <code>java.io.PrintStream</code> or <code>java.io.PrintWriter</code> classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String.format("First {0} and then {1}", "foo", "bar");  //Noncompliant. Looks like there is a confusion with the use of {{java.text.MessageFormat}}, parameters "foo" and "bar" will be simply ignored here
 String.format("Display %3$d and then %d", 1, 2, 3);   //Noncompliant; the second argument '2' is unused
@@ -32,7 +33,7 @@ <h2>Noncompliant Code Example</h2>
 org.apache.logging.log4j.Logger log4jLog;
 log4jLog.debug("message", 1); // Noncompliant - String contains no format specifiers.
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String.format("First %s and then %s", "foo", "bar");
 String.format("Display %2$d and then %d", 1, 3);
@@ -60,7 +61,7 @@ <h2>Compliant Solution</h2>
 org.apache.logging.log4j.Logger log4jLog;
 log4jLog.debug("message {}", 1);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/J9YxBQ">CERT, FIO47-C.</a> - Use valid format strings </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3516.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3516.html
index 168061a4d29..bbf8b93c465 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3516.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3516.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When a method is designed to return an invariant value, it may be poor design, but it shouldn’t adversely affect the outcome of your program.
 However, when it happens on all paths through the logic, it is surely a bug.</p>
 <p>This rule raises an issue when a method contains several <code>return</code> statements that all return the same value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int foo(int a) {
   int b = 12;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3518.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3518.html
index 7b470496ed1..777ed4a2ff6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3518.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3518.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>If the denominator to a division or modulo operation is zero it would result in a fatal error.</p>
 <p>When working with <code>double</code> or <code>float</code>, no fatal error will be raised, but it will lead to unusual result and should be
 avoided anyway.</p>
 <p>This rule supports primitive <code>int</code>, <code>long</code>, <code>double</code>, <code>float</code> as well as <code>BigDecimal</code> and
 <code>BigInteger</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void test_divide() {
   int z = 0;
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   z = 1 / z; // Noncompliant, possible division by zero
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void test_divide() {
   int z = 0;
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
   z = 1 / z;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/369">MITRE, CWE-369</a> - Divide by zero </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/CTZGBQ">CERT, NUM02-J.</a> - Ensure that division and remainder operations do not result in
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3546.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3546.html
index da7e34b15e7..4675999700d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3546.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3546.html
@@ -1,7 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Leaking resources in an application is never a good idea, as it can lead to memory issues, and even the crash of the application. This rule
 template allows you to specify which constructions open a resource and how it is closed in order to raise issue within a method scope when custom
 resources are leaked.</p>
-<h2>See Also</h2>
+<h2>Resources</h2>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S2095} - Resources should be closed </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3551.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3551.html
index 7bef30ba0fc..100c3536bf8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3551.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3551.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When <code>@Overrides</code> of <code>synchronized</code> methods are not themselves <code>synchronized</code>, the result can be improper
 synchronization as callers rely on the thread-safety promised by the parent class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Parent {
 
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Parent {
 
@@ -36,7 +37,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/gzdGBQ">CERT, TSM00-J</a> - Do not override thread-safe methods with methods that are not
   thread-safe </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3553.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3553.html
index 6ca310e150d..8b342b4b245 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3553.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3553.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The Java language authors have been quite frank that <code>Optional</code> was intended for use only as a return type, as a way to convey that a
 method may or may not return a value.</p>
 <p>And for that, it’s valuable but using <code>Optional</code> on the input side increases the work you have to do in the method without really
@@ -7,7 +8,7 @@
 <p>The rule also checks for Guava’s <code>Optional</code>, as it was the inspiration for the JDK <code>Optional</code>. Although it is different in
 some aspects (serialization, being recommended for use as collection elements), using it as a parameter type causes exactly the same problems as for
 JDK <code>Optional</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public String sayHello(Optional&lt;String&gt; name) {  // Noncompliant
   if (name == null || !name.isPresent()) {
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public String sayHello(String name) {
   if (name == null) {
@@ -27,7 +28,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issues will be raised if a method is overriding, as the developer has no control over the signature at this point.</p>
 <pre>
 @Override
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3577.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3577.html
index 8931d6efec2..46f12cb4a00 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3577.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3577.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate efficiently. This rule raises an issue when a test class name does not match the provided
 regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default value: <code>^((Test|IT)[a-zA-Z0-9_]+|[A-Z][a-zA-Z0-9_]*(Test|Tests|TestCase|IT|ITCase))$</code></p>
 <pre>
 class Foo {  // Noncompliant
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class FooTest {
   @Test
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3578.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3578.html
index 1aedf14bf1e..98f2e667caf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3578.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3578.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate efficiently. This rule raises an issue when a test method name does not match the provided
 regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default value: <code>^test[A-Z][a-zA-Z0-9]*$</code></p>
 <pre>
 @Test
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void testFoo() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3599.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3599.html
index 19e3813d510..27435e5fffa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3599.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3599.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>Because Double Brace Initialization (DBI) creates an anonymous class with a reference to the instance of the owning object, its use can lead to
 memory leaks if the anonymous inner class is returned and held by other objects. Even when there’s no leak, DBI is so obscure that it’s bound to
 confuse most maintainers.</p>
 <p>For collections, use <code>Arrays.asList</code> instead, or explicitly add each item directly to the collection.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Map source = new HashMap(){{ // Noncompliant
     put("firstName", "John");
     put("lastName", "Smith");
 }};
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Map source = new HashMap();
 // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3626.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3626.html
index d8e181f5019..65be00b19c3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3626.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3626.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Jump statements such as <code>return</code> and <code>continue</code> let you change the default flow of program execution, but jump statements
 that direct the control flow to the original direction are just a waste of keystrokes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void foo() {
   while (condition1) {
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   return; // Noncompliant; this is a void method
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void foo() {
   while (condition1) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3631.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3631.html
index 194cbb73593..246ed6a5231 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3631.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3631.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>For arrays of objects, <code>Arrays.asList(T ... a).stream()</code> and <code>Arrays.stream(array)</code> are basically equivalent in terms of
 performance. However, for arrays of primitives, using <code>Arrays.asList</code> will force the construction of a list of boxed types, and then use
 <em>that</em> list as a stream. On the other hand, <code>Arrays.stream</code> uses the appropriate primitive stream type (<code>IntStream</code>,
 <code>LongStream</code>, <code>DoubleStream</code>) when applicable, with much better performance.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Arrays.asList("a1", "a2", "b1", "c2", "c1").stream()
     .filter(...)
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
     .filter(...)
     .forEach(...);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Arrays.asList("a1", "a2", "b1", "c2", "c1").stream()
     .filter(...)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3655.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3655.html
index 388005df99c..e3bf4a3a89b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3655.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3655.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p><code>Optional</code> value can hold either a value or not. The value held in the <code>Optional</code> can be accessed using the
 <code>get()</code> method, but it will throw a</p>
 <p><code>NoSuchElementException</code> if there is no value present. To avoid the exception, calling the <code>isPresent()</code> or <code>!
 isEmpty()</code> method should always be done before any call to <code>get()</code>.</p>
 <p>Alternatively, note that other methods such as <code>orElse(...)</code>, <code>orElseGet(...)</code> or <code>orElseThrow(...)</code> can be used
 to specify what to do with an empty <code>Optional</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Optional&lt;String&gt; value = this.getOptionalValue();
 
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
 }
 String value = methodThatReturnsOptional().get(); // Noncompliant: indirect access, we consider that two consecutive calls can return different values.
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 this.getOptionalValue().ifPresent(stringValue -&gt;
   // Do something with stringValue
@@ -49,7 +50,7 @@ <h2>Compliant Solution</h2>
 }
 String value = optional.get();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/476">MITRE, CWE-476</a> - NULL Pointer Dereference </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3658.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3658.html
index d0ce23f6e19..775d3617e8c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3658.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3658.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the code under test in a unit test throws an exception, the test itself fails. Therefore, there is no need to surround the tested code with a
 <code>try</code>-<code>catch</code> structure to detect failure. Instead, you can simply move the exception type to the method signature.</p>
 <p>This rule raises an issue when there is a fail assertion inside a <code>catch</code> block.</p>
@@ -9,7 +10,7 @@
   <li> Fest assert </li>
   <li> AssertJ </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void testMethod() {
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void testMethod() throws MyException {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3688.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3688.html
index 07c1a80edac..e9dc2c959ed 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3688.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3688.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows banning certain classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>Given parameters:</p>
 <ul>
   <li> className:java.lang.String </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3725.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3725.html
index 01955f8d7af..09d513f6ea5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3725.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3725.html
@@ -1,23 +1,24 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>Files.exists</code> method has noticeably poor performance in JDK 8, and can slow an application significantly when used to check files
 that don’t actually exist.</p>
 <p>The same goes for <code>Files.notExists</code>, <code>Files.isDirectory</code> and <code>Files.isRegularFile</code> from <code>java.nio.file</code>
 package.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is not 8.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Path myPath;
 if(java.nio.file.Files.exists(myPath)) {  // Noncompliant
  // do something
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Path myPath;
 if(myPath.toFile().exists())) {
  // do something
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://bugs.openjdk.java.net/browse/JDK-8153414">https://bugs.openjdk.java.net/browse/JDK-8153414</a> </li>
   <li> <a href="https://bugs.openjdk.java.net/browse/JDK-8154077">https://bugs.openjdk.java.net/browse/JDK-8154077</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3740.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3740.html
index 62d342c8be7..dd0c689b88d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3740.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3740.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Generic types shouldn’t be used raw (without type parameters) in variable declarations or return values. Doing so bypasses generic type checking,
 and defers the catch of unsafe code to runtime.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List myList; // Noncompliant
 Set mySet; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; myList;
 Set&lt;? extends Number&gt; mySet;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3749.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3749.html
index e30e4c0c163..4dfa1b31c56 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3749.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3749.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Spring <code>@Component</code>, <code>@Controller</code>, <code>@Service</code>, and <code>@Repository</code> classes are singletons by default,
 meaning only one instance of the class is ever instantiated in the application. Typically such a class might have a few <code>static</code> members,
 such as a logger, but all non-<code>static</code> members should be managed by Spring. That is, they should have one of these annotations:
@@ -12,7 +13,7 @@
   <li> <code>javax.annotation.Inject</code> </li>
   <li> <code>javax.annotation.Resource</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Controller
 public class HelloWorld {
@@ -30,7 +31,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3750.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3750.html
index b1d5e2cb799..df5988ad44c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3750.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3750.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>Spring <code>@Controller</code>s, <code>@Service</code>s, and <code>@Repository</code>s have <code>singleton</code> scope by default, meaning only
 one instance of the class is ever instantiated in the application. Defining any other scope for one of these class types will result in needless churn
 as new instances are created and destroyed. In a busy web application, this could cause a significant amount of needless additional load on the
 server.</p>
 <p>This rule raises an issue when the <code>@Scope</code> annotation is applied to a <code>@Controller</code>, <code>@Service</code>, or
 <code>@Repository</code> with any value but "singleton". <code>@Scope("singleton")</code> is redundant, but ignored.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Scope("prototype")  // Noncompliant
 @Controller
 public class HelloWorld {
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Controller
 public class HelloWorld {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3751.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3751.html
index da81f36ee35..337a146acd4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3751.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3751.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A method with a <code>@RequestMapping</code> annotation part of a class annotated with <code>@Controller</code> (directly or indirectly through a
 meta annotation - <code>@RestController</code> from Spring Boot is a good example) will be called to handle matching web requests. That will happen
 even if the method is <code>private</code>, because Spring invokes such methods via reflection, without checking visibility.</p>
@@ -7,17 +8,17 @@
 it. That’s because AOP proxies are not applied to private methods.</p>
 <p>In addition to <code>@RequestMapping</code>, this rule also considers the annotations introduced in Spring Framework 4.3: <code>@GetMapping</code>,
 <code>@PostMapping</code>, <code>@PutMapping</code>, <code>@DeleteMapping</code>, <code>@PatchMapping</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @RequestMapping("/greet", method = GET)
 private String greet(String greetee) {  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @RequestMapping("/greet", method = GET)
 public String greet(String greetee) {
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3753.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3753.html
index 97395991a4a..d44cb7108a6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3753.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3753.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>A Spring <code>@Controller</code> that uses <code>@SessionAttributes</code> is designed to handle a stateful / multi-post form. Such
 <code>@Controller</code>s use the specified <code>@SessionAttributes</code> to store data on the server between requests. That data should be cleaned
 up when the session is over, but unless <code>setComplete()</code> is called on the <code>SessionStatus</code> object from a
 <code>@RequestMapping</code> method, neither Spring nor the JVM will know it’s time to do that. Note that the <code>SessionStatus</code> object must
 be passed to that method as a parameter.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Controller
 @SessionAttributes("hello")  // Noncompliant; this doesn't get cleaned up
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Controller
 @SessionAttributes("hello")
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
index eeb64e3208e..73066d872eb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be
 difficult to maintain.</p>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>equals</code> and <code>hashCode</code> methods are ignored because they might be automatically generated and might end up being difficult to
 understand, especially in presence of many fields.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.sonarsource.com/docs/CognitiveComplexity.pdf">Cognitive Complexity</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3824.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3824.html
index 9060cc7baff..72cf1756499 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3824.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3824.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>It’s a common pattern to test the result of a <code>java.util.Map.get()</code> against <code>null</code> or calling
 <code>java.util.Map.containsKey()</code> before proceeding with adding or changing the value in the map. However the <code>java.util.Map</code> API
 offers a significantly better alternative in the form of the <code>computeIfPresent()</code> and <code>computeIfAbsent()</code> methods. Using these
 instead leads to cleaner and more readable code.</p>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is not 8.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 V value = map.get(key);
 if (value == null) {  // Noncompliant
@@ -20,14 +21,15 @@ <h2>Noncompliant Code Example</h2>
 }
 return value;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 return map.computeIfAbsent(key, k -&gt; V.createFor(k));
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule will not raise an issue when trying to add <code>null</code> to a map, because <code>computeIfAbsent</code> will not add the entry if the
 value returned by the function is <code>null</code>.</p>
-<h2>See Also</h2>
+<h2>Resources</h2>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S6104} - Map "computeIfAbsent()" and "computeIfPresent()" should not be used to add "null" values. </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3864.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3864.html
index b5b42101ca5..e111e37ba4b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3864.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3864.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>According to its JavaDocs, the intermediate Stream operation <code>java.util.Stream.peek()</code> “exists mainly to support debugging”
 purposes.</p>
 <p>A key difference with other intermediate Stream operations is that the Stream implementation is free to skip calls to <code>peek()</code> for
@@ -5,19 +6,19 @@
 <p>As a consequence, relying on <code>peek()</code> without careful consideration can lead to error-prone code.</p>
 <p>This rule raises an issue for each use of peek() to be sure that it is challenged and validated by the team to be meant for production
 debugging/logging purposes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Stream.of("one", "two", "three", "four")
          .filter(e -&gt; e.length() &gt; 3)
          .peek(e -&gt; System.out.println("Filtered value: " + e)); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Stream.of("one", "two", "three", "four")
          .filter(e -&gt; e.length() &gt; 3)
          .foreach(e -&gt; System.out.println("Filtered value: " + e));
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#peek-java.util.function.Consumer-">Java 8 API Documentation</a>
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3878.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3878.html
index 12bef3bc40d..a7937738339 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3878.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3878.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no point in creating an array solely for the purpose of passing it as a varargs (<code>...</code>) argument; varargs <em>is</em> an array.
 Simply pass the elements directly. They will be consolidated into an array automatically. Incidentally passing an array where <code>Object ...</code>
 is expected makes the intent ambiguous: Is the array supposed to be one object or a collection of objects?</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void callTheThing() {
   //...
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void callTheThing() {
   //...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
index 948489c3dc2..762051617d9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Having all branches in a <code>switch</code> or <code>if</code> chain with the same implementation is an error. Either a copy-paste error was made
 and something different should be executed, or there shouldn’t be a <code>switch</code>/<code>if</code> chain at all.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (b == 0) {  // Noncompliant
   doOneMoreThing();
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
     doSomething();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule does not apply to <code>if</code> chains without <code>else</code>-s, or to <code>switch</code>-es without <code>default</code>
 clauses.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3937.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3937.html
index 5372a35a113..b12ece1706d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3937.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3937.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>The use of punctuation characters to separate subgroups in a number can make the number more readable. For instance consider 1,000,000,000 versus
 1000000000. But when the grouping is irregular, such as 1,000,00,000; it indicates an error.</p>
 <p>This rule raises an issue when underscores (<code>_</code>) are used to break a number into irregular subgroups.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int thousand = 100_0;
 int tenThousand = 100_00;
 int million = 1_000_00_000;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int thousand = 1000;
 int tenThousand = 10_000;
@@ -15,7 +16,7 @@ <h2>Compliant Solution</h2>
 int duos = 1_00_00;
 int million = 100_000_000;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue will be raised on binary numbers (starting with <code>0b</code> or <code>0B</code>). Binary number bits are often grouped corresponding to
 certain meanings, resulting in irregular bit group sizes.</p>
 <pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3958.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3958.html
index 271f49463a6..01950156d38 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3958.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3958.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>There are two types of stream operations: intermediate operations, which return another stream, and terminal operations, which return something
 other than a stream. Intermediate operations are lazy, meaning they aren’t actually executed until and unless a terminal stream operation is performed
 on their results. Consequently, if the result of an intermediate stream operation is not fed to a terminal operation, it serves no purpose, which is
 almost certainly an error.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 widgets.stream().filter(b -&gt; b.getColor() == RED); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int sum = widgets.stream()
                       .filter(b -&gt; b.getColor() == RED)
@@ -17,7 +18,7 @@ <h2>Compliant Solution</h2>
                                  .mapToInt(b -&gt; b.getWeight());
 sum = pipeline.sum();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#StreamOps">Stream Operations</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3959.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3959.html
index fa17a417d5c..ca7ea71c547 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3959.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3959.html
@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Stream operations are divided into intermediate and terminal operations, and are combined to form stream pipelines. After the terminal operation is
 performed, the stream pipeline is considered consumed, and cannot be used again. Such a reuse will yield unexpected results.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Stream&lt;Widget&gt; pipeline = widgets.stream().filter(b -&gt; b.getColor() == RED);
 int sum1 = pipeline.sum();
 int sum2 = pipeline.mapToInt(b -&gt; b.getWeight()).sum(); // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <p><a href="https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#StreamOps">Stream Operations</a></p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
index 24a52f156c3..b9a7ad8f6a8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Code is clearest when each statement has its own line. Nonetheless, it is a common pattern to combine on the same line an <code>if</code> and its
 resulting <em>then</em> statement. However, when an <code>if</code> is placed on the same line as the closing <code>}</code> from a preceding
 <em>then</em>, <em>else</em> or <em>else if</em> part, it is either an error - <code>else</code> is missing - or the invitation to a future error as
 maintainers fail to understand that the two statements are unconnected.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (condition1) {
   // ...
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (condition1) {
   // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
index e1c99ea7966..43d0aee8aff 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>In the absence of enclosing curly braces, the line immediately after a conditional is the one that is conditionally executed. By both convention
 and good practice, such lines are indented. In the absence of both curly braces and indentation the intent of the original programmer is entirely
 unclear and perhaps not actually what is executed. Additionally, such code is highly likely to be confusing to maintainers.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (condition)  // Noncompliant
 doTheThing();
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
 
 foo();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (condition)
   doTheThing();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3981.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3981.html
index 9f84f344b06..9d986f07909 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3981.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3981.html
@@ -1,20 +1,14 @@
-<p>The size of a collection and the length of an array are always greater than or equal to zero. So testing that a size or length is greater than or
-equal to zero doesn’t make sense, since the result is always <code>true</code>. Similarly testing that it is less than zero will always return
-<code>false</code>. Perhaps the intent was to check the non-emptiness of the collection or array instead.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Why is this an issue?</h2>
+<p>The size of a collection and the length of an array are always greater than or equal to zero. Testing it doesn’t make sense, since the result is
+always <code>true</code>.</p>
 <pre>
-if (myList.size() &gt;= 0) { ... }
+if (myList.size() &gt;= 0) {...} // Noncompliant: always true
 
-if (myList.size() &lt; 0) { ... }
-
-boolean result = myArray.length &gt;= 0;
-
-if (0 &gt; myArray.length) { ... }
+boolean result = myArray.length &gt;= 0; // Noncompliant: true
 </pre>
-<h2>Compliant Solution</h2>
+<p>Similarly testing that it is less than zero will always return <code>false</code>.</p>
 <pre>
-if (!myList.isEmpty()) { ... }
-
-if (myArray.length &gt;= 42) { ... }
+if (myList.size() &lt; 0) {...} // Noncompliant: always false
 </pre>
+<p>Fix the code to properly check for emptiness if it was the intent, or remove the redundant code to keep the current behavior.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3984.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3984.html
index a223d4f2a12..d5677722d5c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3984.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3984.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Creating a new <code>Throwable</code> without actually throwing it is useless and is probably due to a mistake.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (x &lt; 0)
   new IllegalArgumentException("x must be nonnegative");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (x &lt; 0)
   throw new IllegalArgumentException("x must be nonnegative");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3985.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3985.html
index 1a661f5708a..4085cb9e19e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3985.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3985.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p><code>private</code> classes that are never used are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code
 decreases the size of the maintained codebase, making it easier to understand the program and preventing bugs from being introduced.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo
 {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3986.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3986.html
index 2ba24450ce9..086267c3b73 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3986.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3986.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Few developers are aware of the difference between <code>Y</code> for "Week year" and <code>y</code> for Year when formatting and parsing a date
 with <code>SimpleDateFormat</code> or <code>DateTimeFormatter</code>. That’s likely because for most dates, Week year and Year are the same, so
 testing at any time other than the first or last week of the year will yield the same value for both <code>y</code> and <code>Y</code>. But in the
@@ -11,19 +12,19 @@
   year 1997. If, however, getFirstDayOfWeek() is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998; the first three
   days of 1998 then are part of week 53 of 1997 and their week year is 1997.</p>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
 String result = new SimpleDateFormat("YYYY/MM/dd").format(date);   //Noncompliant; yields '2016/12/31'
 result = DateTimeFormatter.ofPattern("YYYY/MM/dd").format(date); //Noncompliant; yields '2016/12/31'
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
 String result = new SimpleDateFormat("yyyy/MM/dd").format(date);   //Yields '2015/12/31' as expected
 result = DateTimeFormatter.ofPattern("yyyy/MM/dd").format(date); //Yields '2015/12/31' as expected
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <pre>
 Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
 String result = new SimpleDateFormat("YYYY-ww").format(date);  //compliant, 'Week year' is used along with 'Week of year'. result = '2016-01'
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4011.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4011.html
index 9642d91235b..796de0b1430 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4011.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4011.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>This rule allows banning usage of certain constructors.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>Given parameters:</p>
 <ul>
   <li> className: java.util.Date </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4032.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4032.html
index e5c06743fdb..fbaf04080d7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4032.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4032.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There is no reason to have a package that is empty except for "package-info.java". Such packages merely clutter a project, taking up space but
 adding no value.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4034.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4034.html
index b9e4b08abff..5ad6f1ec01d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4034.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4034.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When using the <code>Stream</code> API, call chains should be simplified as much as possible. Not only does it make the code easier to read, it
 also avoid creating unnecessary temporary objects.</p>
 <p>This rule raises an issue when one of the following substitution is possible:</p>
@@ -35,11 +36,11 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 boolean hasRed = widgets.stream().filter(w -&gt; w.getColor() == RED).findFirst().isPresent(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 boolean hasRed = widgets.stream().anyMatch(w -&gt; w.getColor() == RED);
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4042.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4042.html
index d38bbe6af65..17bb758f546 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4042.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4042.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>When <code>java.io.File#delete</code> fails, this <code>boolean</code> method simply returns <code>false</code> with no indication of the cause. On
 the other hand, when <code>java.nio.file.Files#delete</code> fails, this <code>void</code> method returns one of a series of exception types to better
 indicate the cause of the failure. And since more information is generally better in a debugging situation, <code>java.nio.file.Files#delete</code> is
 the preferred option.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void cleanUp(Path path) {
   File file = new File(path);
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void cleanUp(Path path) throws NoSuchFileException, DirectoryNotEmptyException, IOException {
   Files.delete(path);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4065.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4065.html
index e3fa03271f6..1afcdbc410e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4065.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4065.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Java 8 introduced <code>ThreadLocal.withInitial</code> which is a simpler alternative to creating an anonymous inner class to initialise a
 <code>ThreadLocal</code> instance.</p>
 <p>This rule raises an issue when a <code>ThreadLocal</code> anonymous inner class can be replaced by a call to
 <code>ThreadLocal.withInitial</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ThreadLocal&lt;List&lt;String&gt;&gt; myThreadLocal =
     new ThreadLocal&lt;List&lt;String&gt;&gt;() { // Noncompliant
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
         }
     };
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ThreadLocal&lt;List&lt;String&gt;&gt; myThreadLocal = ThreadLocal.withInitial(ArrayList::new);
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4087.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4087.html
index 0ffb94d8d48..9cc9d81b4cd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4087.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4087.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Java 7’s try-with-resources structure automatically handles closing the resources that the <code>try</code> itself opens. Thus, adding an explicit
 <code>close()</code> call is redundant and potentially confusing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try (PrintWriter writer = new PrintWriter(process.getOutputStream())) {
   String contents = file.contents();
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   writer.close();  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 try (PrintWriter writer = new PrintWriter(process.getOutputStream())) {
   String contents = file.contents();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
index 8683b40c897..00cab76d930 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>It is highly suspicious when a value is saved for a key or index and then unconditionally overwritten. Such replacements are likely errors.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 letters.put("a", "Apple");
 letters.put("a", "Boy");  // Noncompliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
index 8ef1045e58e..44cf6cc0be3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When two methods have the same implementation, either it was a mistake - something else was intended - or the duplication was intentional, but may
 be confusing to maintainers. In the latter case, one implementation should invoke the other. Numerical and string literals are not taken into
 account.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 private final static String CODE = "bounteous";
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
   return CODE;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private final static String CODE = "bounteous";
 
@@ -28,6 +29,6 @@ <h2>Compliant Solution</h2>
   return getCode();
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Methods that are not accessors (getters and setters), with fewer than 2 statements are ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4165.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4165.html
index c48fbfa8a33..7457a45d766 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4165.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4165.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>The transitive property says that if <code>a == b</code> and <code>b == c</code>, then <code>a == c</code>. In such cases, there’s no point in
 assigning <code>a</code> to <code>c</code> or vice versa because they’re already equivalent.</p>
 <p>This rule raises an issue when an assignment is useless because the assigned-to variable already holds the value on all execution paths.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 a = b;
 c = a;
 b = c; // Noncompliant: c and b are already the same
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 a = b;
 c = a;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4174.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4174.html
index 74d3ccf0e06..bb53efdd06c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4174.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4174.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared coding conventions allow teams to collaborate efficiently. This rule checks that all local, <code>final</code>, initialized, primitive
 variables, have names that match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression <code>^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$</code>:</p>
 <pre>
 public void doSomething() {
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
   ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething() {
   final int LOCAL = 42;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4201.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4201.html
index 87b65425273..a60570f5fbb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4201.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4201.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>There’s no need to null test in conjunction with an <code>instanceof</code> test. <code>null</code> is not an <code>instanceof</code> anything, so
 a null check is redundant.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (x != null &amp;&amp; x instanceof MyClass) { ... }  // Noncompliant
 
 if (x == null || ! x instanceof MyClass) { ... } // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (x instanceof MyClass) { ... }
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4248.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4248.html
index 01e2ce1916b..ae29f7a5b04 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4248.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4248.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>java.util.regex.Pattern.compile()</code> methods have a significant performance cost, and therefore should be used sensibly.</p>
 <p>Moreover they are the only mechanism available to create instances of the Pattern class, which are necessary to do any pattern matching using
 regular expressions. Unfortunately that can be hidden behind convenience methods like <code>String.matches()</code> or
@@ -10,7 +11,7 @@
   <code>String</code> literal or constant. In which case the code should be refactored to use a <code>java.util.regex.Pattern</code> while respecting
   the previous rule. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doingSomething(String stringToMatch) {
   Pattern regex = Pattern.compile("myRegex");  // Noncompliant
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 private static final Pattern myRegex = Pattern.compile("myRegex");
 private static final Pattern myRegex2 = Pattern.compile("myRegex2");
@@ -34,7 +35,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p><code>String.split</code> doesn’t create a regex when the string passed as argument meets either of these 2 conditions:</p>
 <ul>
   <li> It is a one-char String and this character is not one of the RegEx’s meta characters ".$|()[{^?*+\" </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4266.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4266.html
index a9d8727ea89..2f21661a524 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4266.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4266.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When using the <code>Stream</code> API, call chains should be simplified as much as possible to improve readability and maintainability.</p>
 <p>This rule raises an issue when one of the following substitution can be made:</p>
 <table>
@@ -46,11 +47,11 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int count = stream.collect(counting());  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int count = stream.count();
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4274.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4274.html
index f6f2f0b9ba4..742bc7fd42d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4274.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4274.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>An <code>assert</code> is inappropriate for parameter validation because assertions can be disabled at runtime in the JVM, meaning that a bad
 operational setting would completely eliminate the intended checks. Further, <code>assert</code>s that fail throw <code>AssertionError</code>s, rather
 than throwing some type of <code>Exception</code>. Throwing <code>Error</code>s is completely outside of the normal realm of expected
 <code>catch</code>/<code>throw</code> behavior in normal programs.</p>
 <p>This rule raises an issue when a <code>public</code> method uses one or more of its parameters with <code>assert</code>s.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
  public void setPrice(int price) {
   assert price &gt;= 0 &amp;&amp; price &lt;= MAX_PRICE;
   // Set the price
  }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
  public void setPrice(int price) {
   if (price &lt; 0 || price &gt; MAX_PRICE) {
@@ -19,6 +20,6 @@ <h2>Compliant Solution</h2>
   // Set the price
  }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <p><a href="https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html">Programming With Assertions</a></p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
index 34603571edb..620e8b67618 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Getters and setters provide a way to enforce encapsulation by providing <code>public</code> methods that give controlled access to
 <code>private</code> fields. However in classes with multiple fields it is not unusual that copy and paste is used to quickly create the needed
 getters and setters, which can result in the wrong field being accessed by a getter or setter.</p>
@@ -6,7 +7,7 @@
   <li> A setter does not update the field with the corresponding name. </li>
   <li> A getter does not access the field with the corresponding name. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class A {
   private int x;
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class A {
   private int x;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4276.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4276.html
index e320e4f82f0..894974cb4d6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4276.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4276.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>java.util.function</code> package provides a large array of functional interface definitions for use in lambda expressions and method
 references. In general it is recommended to use the more specialised form to avoid auto-boxing. For instance <code>IntFunction&lt;Foo&gt;</code>
 should be preferred over <code>Function&lt;Integer, Foo&gt;</code>.</p>
@@ -148,7 +149,7 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo implements Supplier&lt;Integer&gt; {  // Noncompliant
     @Override
@@ -157,7 +158,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo implements IntSupplier {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4288.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4288.html
index 6c8a5239132..d00bb15943d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4288.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4288.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Spring <code>@Controller</code>, <code>@Service</code>, and <code>@Repository</code> classes are singletons by default, meaning only one instance
 of the class is ever instantiated in the application. Typically such a class might have a few <code>static</code> members, such as a logger, but all
 non-static members should be managed by Spring and supplied via constructor injection rather than by field injection.</p>
 <p>This rule raise an issue when any non-<code>static</code> member of a Spring component has an injection annotation.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Controller
 public class HelloWorld {
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>As of Spring 4.3</p>
 <pre>
 @Controller
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4347.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4347.html
index 18523b18ced..d2be224cd30 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4347.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4347.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>java.security.SecureRandom</code> class provides a strong random number generator (RNG) appropriate for cryptography. However, seeding it
 with a constant or another predictable value will weaken it significantly. In general, it is much safer to rely on the seed provided by the
 <code>SecureRandom</code> implementation.</p>
@@ -7,7 +8,7 @@
   <li> a constant </li>
   <li> the system time </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 SecureRandom sr = new SecureRandom();
 sr.setSeed(123456L); // Noncompliant
@@ -16,12 +17,12 @@ <h2>Noncompliant Code Example</h2>
 sr = new SecureRandom("abcdefghijklmnop".getBytes("us-ascii")); // Noncompliant
 v = sr.next(32);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 SecureRandom sr = new SecureRandom();
 int v = sr.next(32);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4348.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4348.html
index 444c8bb925b..c5741c5807d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4348.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4348.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There are two classes in the Java standard library that deal with iterations: <code>Iterable&lt;T&gt;</code> and <code>Iterator&lt;T&gt;</code>. An
 <code>Iterable&lt;T&gt;</code> represents a data structure that can be the target of the "for-each loop" statement, and an
 <code>Iterator&lt;T&gt;</code> represents the state of an ongoing traversal. An <code>Iterable&lt;T&gt;</code> is generally expected to support
@@ -6,7 +7,7 @@
 support multiple traversals since its state will be carried over.</p>
 <p>This rule raises an issue when the <code>iterator()</code> method of a class implementing both <code>Iterable&lt;T&gt;</code> and
 <code>Iterator&lt;t&gt;</code> returns <code>this</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class FooIterator implements Iterator&lt;Foo&gt;, Iterable&lt;Foo&gt; {
   private Foo[] seq;
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class FooSequence implements Iterable&lt;Foo&gt; {
   private Foo[] seq;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4349.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4349.html
index 3344c5c37eb..104a182e9a5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4349.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4349.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When directly subclassing <code>java.io.OutputStream</code> or <code>java.io.FilterOutputStream</code>, the only requirement is that you implement
 the method <code>write(int)</code>. However most uses for such streams don’t write a single byte at a time and the default implementation for
 <code>write(byte[],int,int)</code> will call <code>write(int)</code> for every single byte in the array which can create a lot of overhead and is
@@ -5,7 +6,7 @@
 <code>write(byte[],int,int)</code>.</p>
 <p>This rule raises an issue when a direct subclass of <code>java.io.OutputStream</code> or <code>java.io.FilterOutputStream</code> doesn’t provide an
 override of <code>write(byte[],int,int)</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyStream extends OutputStream { // Noncompliant
     private FileOutputStream fout;
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyStream extends OutputStream {
     private FileOutputStream fout;
@@ -54,6 +55,6 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise an issue when the class is declared <code>abstract</code>.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4351.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4351.html
index 6ee68b504c5..1ea14d35069 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4351.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4351.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>When implementing the <code>Comparable&lt;T&gt;.compareTo</code> method, the parameter’s type has to match the type used in the
 <code>Comparable</code> declaration. When a different type is used this creates an overload instead of an override, which is unlikely to be the
 intent.</p>
 <p>This rule raises an issue when the parameter of the <code>compareTo</code> method of a class implementing <code>Comparable&lt;T&gt;</code> is not
 same as the one used in the <code>Comparable</code> declaration.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo {
   static class Bar implements Comparable&lt;Bar&gt; {
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class Foo {
   static class Bar implements Comparable&lt;Bar&gt; {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4423.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4423.html
index 83dc8aa665a..ae765488b3e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4423.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4423.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>This rule raises an issue when an insecure TLS protocol version (i.e. a protocol different from "TLSv1.2", "TLSv1.3", "DTLSv1.2", or "DTLSv1.3") is
 used or allowed.</p>
 <p>It is recommended to enforce TLS 1.2 as the minimum protocol version and to disallow older versions like TLS 1.0. Failure to do so could open the
@@ -6,7 +7,7 @@
 <p>In most cases, using the default system configuration is not compliant. Indeed, an application might get deployed on a wide range of systems with
 different configurations. While using a system’s default value might be safe on modern up-to-date systems, this might not be the case on older
 systems. It is therefore recommended to explicitly set a safe configuration in every case.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p><code>javax.net.ssl.SSLContext</code> library:</p>
 <pre>
 context = SSLContext.getInstance("TLSv1.1"); // Noncompliant
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
       .tlsVersions(TlsVersion.TLS_1_1) // Noncompliant
       .build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p><code>javax.net.ssl.SSLContext</code> library:</p>
 <pre>
 context = SSLContext.getInstance("TLSv1.2"); // Compliant
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
       .tlsVersions(TlsVersion.TLS_1_2) // Compliant
       .build();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4425.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4425.html
index eb007b8d951..40f8e460636 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4425.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4425.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>Integer.toHexString</code> is a common mistake when converting sequences of bytes into hexadecimal string representations. The problem
 is that the method trims leading zeroes, which can lead to wrong conversions. For instance a two bytes value of <code>0x4508</code> would be converted
 into <code>45</code> and <code>8</code> which once concatenated would give <code>0x458</code>.</p>
 <p>This is particularly damaging when converting hash-codes and could lead to a security vulnerability.</p>
 <p>This rule raises an issue when <code>Integer.toHexString</code> is used in any kind of string concatenations.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 MessageDigest md = MessageDigest.getInstance("SHA-256");
 byte[] bytes = md.digest(password.getBytes("UTF-8"));
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
     sb.append(Integer.toHexString( b &amp; 0xFF )); // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 MessageDigest md = MessageDigest.getInstance("SHA-256");
 byte[] bytes = md.digest(password.getBytes("UTF-8"));
@@ -23,7 +24,7 @@ <h2>Compliant Solution</h2>
     sb.append(String.format("%02X", b));
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/704">MITRE, CWE-704</a> - Incorrect Type Conversion or Cast </li>
   <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#BAD_HEXA_CONVERSION">BAD_HEXA_CONVERSION</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4426.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4426.html
index 5db4e832bcc..4e0fc24357a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4426.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4426.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Most of cryptographic systems require a sufficient key size to be robust against brute-force attacks.</p>
 <p><a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf">NIST recommendations</a> will be checked for these
 use-cases:</p>
@@ -17,7 +18,7 @@
   <li> key length ≥ 128 bits </li>
 </ul>
 <p>This rule will not raise issues for ciphers that are considered weak (no matter the key size) like <code>DES</code>, <code>Blowfish</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 KeyPairGenerator keyPairGen1 = KeyPairGenerator.getInstance("RSA");
 keyPairGen1.initialize(1024); // Noncompliant
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
 KeyGenerator keyGen1 = KeyGenerator.getInstance("AES");
 keyGen1.init(64); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 KeyPairGenerator keyPairGen6 = KeyPairGenerator.getInstance("RSA");
 keyPairGen6.initialize(2048); // Compliant
@@ -41,7 +42,7 @@ <h2>Compliant Solution</h2>
 KeyGenerator keyGen2 = KeyGenerator.getInstance("AES");
 keyGen2.init(128); // Compliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4433.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4433.html
index e5255f71ceb..aee6056f18c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4433.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4433.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>An LDAP client authenticates to an LDAP server with a "bind request" which provides, among other, a <a
 href="https://web.archive.org/web/20220922153922/https://ldapwiki.com/wiki/Simple%20Authentication">simple authentication method</a>.</p>
 <p>Simple authentication in LDAP can be used with three different mechanisms:</p>
@@ -8,7 +9,7 @@
 </ul>
 <p>Anonymous binds and unauthenticated binds allow access to information in the LDAP directory without providing a password, their use is therefore
 strongly discouraged.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>This rule raises an issue when an LDAP connection is created with <code>Context.SECURITY_AUTHENTICATION</code> set to <code>"none"</code>.</p>
 <pre>
 // Set up the environment for creating the initial context
@@ -22,7 +23,7 @@ <h2>Noncompliant Code Example</h2>
 // Create the initial context
 DirContext ctx = new InitialDirContext(env);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // Set up the environment for creating the initial context
 Hashtable&lt;String, Object&gt; env = new Hashtable&lt;String, Object&gt;();
@@ -37,7 +38,7 @@ <h2>Compliant Solution</h2>
 // Create the initial context
 DirContext ctx = new InitialDirContext(env);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4449.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4449.html
index 13a3ab74307..ca7b9ff8671 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4449.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4449.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>When using null-related annotations at global scope level, for instance using <code>javax.annotation.ParametersAreNonnullByDefault</code> (from
 JSR-305) at package level, it means that all the parameters to all the methods included in the package will, or should, be considered
 Non-<code>null</code>. It is equivalent to annotating every parameter in every method with non-null annotations (such as <code>@Nonnull</code>).</p>
 <p>The rule raises an issue every time a parameter could be <code>null</code> for a method invocation, where the method is annotated as forbidding
 null parameters.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @javax.annotation.ParametersAreNonnullByDefault
 class A {
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   abstract Object getValue();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Two solutions are possible:</p>
 <ul>
   <li> The signature of the method is correct, and null check should be done prior to the call. </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4454.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4454.html
index ad952496404..31f7e48392d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4454.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4454.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>By contract, the <code>equals(Object)</code> method, from <code>java.lang.Object</code>, should accept a <code>null</code> argument. Among all the
 other cases, the <code>null</code> case is even explicitly detailed in the <code>Object.equals(...)</code> Javadoc, stating <em>"For any non-null
 reference value x, x.equals(null) should return false."</em></p>
@@ -5,13 +6,13 @@
 violation of the contract of <code>equals</code>, but it is also likely to cause problems in the future as the use of the class evolves over time.</p>
 <p>The rule raises an issue when the <code>equals</code> method is overridden and its parameter annotated with any kind of <code>@Nonnull</code>
 annotation.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public boolean equals(@javax.annotation.Nonnull Object obj) { // Noncompliant
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean equals(Object obj) {
   if (obj == null) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4488.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4488.html
index fd9cb7d750d..049ab47423f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4488.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4488.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Spring framework 4.3 introduced variants of the <code>@RequestMapping</code> annotation to better represent the semantics of the annotated methods.
 The use of <code>@GetMapping</code>, <code>@PostMapping</code>, <code>@PutMapping</code>, <code>@PatchMapping</code> and <code>@DeleteMapping</code>
 should be preferred to the use of the raw <code>@RequestMapping(method = RequestMethod.XYZ)</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @RequestMapping(path = "/greeting", method = RequestMethod.GET) // Noncompliant
 public Greeting greeting(@RequestParam(value = "name", defaultValue = "World") String name) {
 ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @GetMapping(path = "/greeting") // Compliant
 public Greeting greeting(@RequestParam(value = "name", defaultValue = "World") String name) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4517.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4517.html
index 3c42045fe8a..fe2c7b853c3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4517.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4517.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Java documentation, any implementation of the <code>InputSteam.read()</code> method is supposed to read the next byte of data from
 the input stream. The value byte must be an <code>int</code> in the range 0 to 255. If no byte is available because the end of the stream has been
 reached, the value -1 is returned.</p>
 <p>But in Java, the <code>byte</code> primitive data type is an 8-bit signed two’s complement integer. It has a minimum value of -128 and a maximum
 value of 127. So by contract, the implementation of an <code>InputSteam.read()</code> method should never directly return a <code>byte</code>
 primitive data type. A conversion into an unsigned byte must be done before by applying a bitmask.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Override
 public int read() throws IOException {
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   return buffer.getByte(pos++); // Noncompliant, a signed byte value is returned
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Override
 public int read() throws IOException {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
index ebe2357eef0..46258111fdd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p><code>switch</code> can contain a <code>default</code> clause for various reasons: to handle unexpected values, to show that all the cases were
 properly considered.</p>
 <p>For readability purpose, to help a developer to quickly find the default behavior of a <code>switch</code> statement, it is recommended to put the
 <code>default</code> clause at the end of the <code>switch</code> statement. This rule raises an issue if the <code>default</code> clause is not the
 last one of the <code>switch</code>'s cases.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 switch (param) {
   case 0:
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
     break;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 switch (param) {
   case 0:
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4551.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4551.html
index e365d90d261..82252eaa9f6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4551.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4551.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Testing equality of an enum value with <code>equals</code> is perfectly valid because an enum is an Object and every Java developer knows "=="
 should not be used to compare the content of an Object. At the same time, using "==" on enums:</p>
 <ul>
@@ -6,7 +7,7 @@
   <li> provides compile-time (static) checking rather than runtime checking </li>
 </ul>
 <p>For these reasons, use of "==" should be preferred to <code>equals</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public enum Fruit {
    APPLE, BANANA, GRAPE
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
   return candidateFruit.equals(Fruit.GRAPE); // Noncompliant; always returns false
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public boolean isFruitGrape(Fruit candidateFruit) {
   return candidateFruit == Fruit.GRAPE; // Compliant; there is only one instance of Fruit.GRAPE - if candidateFruit is a GRAPE it will have the same reference as Fruit.GRAPE
@@ -34,7 +35,7 @@ <h2>Compliant Solution</h2>
   return candidateFruit == Fruit.GRAPE; // Compliant; compilation time failure
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.javaworld.com/article/2074292/core-java/use-----or-----to-compare-java-enums.html">Use == (or !=) to Compare Java
   Enums</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4601.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4601.html
index 8caf953a7ae..278dccb29ef 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4601.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4601.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>URL patterns configured on a <code>HttpSecurity.authorizeRequests()</code> method are considered in the order they were declared. It’s easy to make
 a mistake and declare a less restrictive configuration before a more restrictive one. Therefore, it’s required to review the order of the
 "antMatchers" declarations. The <code>/**</code> one should be the last one if it is declared.</p>
@@ -8,7 +9,7 @@
   <li> A pattern without wildcard characters is preceded by another that matches. E.g.: <code>/page-index/db</code> is after <code>/page*/**</code>
   </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   protected void configure(HttpSecurity http) throws Exception {
     http.authorizeRequests()
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
       .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
   protected void configure(HttpSecurity http) throws Exception {
     http.authorizeRequests()
@@ -32,7 +33,7 @@ <h2>Compliant Solution</h2>
       .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
   }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4602.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4602.html
index 44023f35d4d..7d761d3316b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4602.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4602.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>@ComponentScan</code> is used to determine which Spring Beans are available in the application context. The packages to scan can be
 configured thanks to the <code>basePackageClasses</code> or <code>basePackages</code> (or its alias <code>value</code>) parameters. If neither
 parameter is configured, <code>@ComponentScan</code> will consider only the package of the class annotated with it. When <code>@ComponentScan</code>
@@ -10,7 +11,7 @@
   default package </li>
   <li> <code>@ComponentScan</code> is explicitly configured with the default package </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.springframework.boot.SpringApplication;
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
 ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package hello;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4604.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4604.html
index e60ea4d4cb6..94a5984344c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4604.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4604.html
@@ -1,9 +1,11 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
+<h2>Why is this an issue?</h2>
 <p>"@EnableAutoConfiguration" is a convenient feature to configure the Spring Application Context by attempting to guess the beans that you are likely
 to need. The drawback is that it may load and configure beans the application will never use and therefore consume more CPU and RAM than really
 required. <code>@EnableAutoConfiguration</code> should be configured to exclude all the beans not required by the application. Alternatively, use the
 <code>@Import</code> annotation instead of <code>@EnableAutoConfiguration</code>, to explicitly import the useful AutoConfiguration classes.</p>
 <p>This rule applies for <code>@SpringBootApplication</code> as well.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @SpringBootApplication
 public class MyApplication {
@@ -17,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
 ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @SpringBootApplication(exclude = {
   MultipartAutoConfiguration.class,
@@ -55,6 +57,4 @@ <h2>Compliant Solution</h2>
 ...
 }
 </pre>
-<h2>Deprecated</h2>
-<p>This rule is deprecated, and will eventually be removed.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4605.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4605.html
index 1485ebcd0cc..0d121b9b834 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4605.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4605.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Spring beans belonging to packages that are not included in a <code>@ComponentScan</code> configuration will not be accessible in the Spring
 Application Context. Therefore, it’s likely to be a configuration mistake that will be detected by this rule.</p>
 <p><strong>Note:</strong> the <code>@ComponentScan</code> is implicit in the <code>@SpringBootApplication</code> annotation, case in which Spring Boot
 will auto scan for components in the package containing the Spring Boot main class and its sub-packages.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 package com.mycompany.app;
 
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
 ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package com.mycompany.app;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4635.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4635.html
index 10935de7743..0e27625318c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4635.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4635.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Looking for a given substring starting from a specified offset can be achieved by such code: <code>str.substring(beginIndex).indexOf(char1)</code>.
 This works well, but it creates a new <code>String</code> for each call to the <code>substring</code> method. When this is done in a loop, a lot of
 <code>Strings</code> are created for nothing, which can lead to performance problems if <code>str</code> is large.</p>
@@ -12,11 +13,11 @@
 <p>For each of these methods, another method with an additional parameter is available to specify an offset.</p>
 <p>Using these methods will avoid the creation of additional <code>String</code> instances. For indexOf methods, adjust the returned value by
 subtracting the substring index parameter to obtain the same result.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 str.substring(beginIndex).indexOf(char1); // Noncompliant; a new String is going to be created by "substring"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 str.indexOf(char1, beginIndex) - beginIndex; // index for char1 not found is (-1-beginIndex)
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4682.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4682.html
index 76eb43a5eec..a002133bab9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4682.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4682.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>By definition, primitive types are not Objects and so they can’t be <code>null</code>. Adding <code>@CheckForNull</code> or <code>@Nullable</code>
 on primitive types adds confusion and is useless.</p>
 <p>This rule raises an issue when <code>@CheckForNull</code> or <code>@Nullable</code> is set on a method returning a primitive type: byte, short,
 int, long, float, double, boolean, char.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @CheckForNull
 boolean isFoo() {
  ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 boolean isFoo() {
  ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4684.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4684.html
index 127d204957a..bece99bc50b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4684.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4684.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>On one side, Spring MVC automatically bind request parameters to beans declared as arguments of methods annotated with
 <code>@RequestMapping</code>. Because of this automatic binding feature, it’s possible to feed some unexpected fields on the arguments of the
 <code>@RequestMapping</code> annotated methods.</p>
@@ -9,7 +10,7 @@
 should be avoided.</p>
 <p>In addition to <code>@RequestMapping</code>, this rule also considers the annotations introduced in Spring Framework 4.3: <code>@GetMapping</code>,
 <code>@PostMapping</code>, <code>@PutMapping</code>, <code>@DeleteMapping</code>, <code>@PatchMapping</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import javax.persistence.Entity;
 
@@ -44,7 +45,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class WishDTO {
   Long productId;
@@ -75,10 +76,10 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue is reported when the parameter is annotated with <code>@PathVariable</code> from Spring Framework, since the lookup will be done via id,
 the object cannot be forged on client side.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">OWASP Top 10 2021 Category A8</a> - Software and Data
   Integrity Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4719.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4719.html
index b1e5dee8291..8f0eeb5b6ee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4719.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4719.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>JDK7 introduced the class <code>java.nio.charset.StandardCharsets</code>. It provides constants for all charsets that are guaranteed to be
 available on every implementation of the Java platform.</p>
 <ul>
@@ -14,7 +15,7 @@
   <code>UnsupportedEncodingException</code> that will never actually happen </li>
   <li> the use of Guava’s <code>Charsets</code> class, which has been obsolete since JDK7 </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 try {
   byte[] bytes = string.getBytes("UTF-8"); // Noncompliant; use a String instead of StandardCharsets.UTF_8
@@ -24,7 +25,7 @@ <h2>Noncompliant Code Example</h2>
 // ...
 byte[] bytes = string.getBytes(Charsets.UTF_8); // Noncompliant; Guava way obsolete since JDK7
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 byte[] bytes = string.getBytes(StandardCharsets.UTF_8)
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4738.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4738.html
index 0ae386d6545..5bf0c26b039 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4738.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4738.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Some Guava features were really useful for Java 7 application because Guava was bringing APIs missing in the JDK. Java 8 fixed some of these
 limitations. When migrating an application to Java 8 or even when starting a new one, it’s recommended to prefer Java 8 APIs over Guava ones to ease
 its maintenance: developers don’t need to learn how to use two APIs and can stick to the standard one.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4830.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4830.html
index 350d82d1a5d..4347b44b998 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4830.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4830.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Validation of X.509 certificates is essential to create secure SSL/TLS sessions not vulnerable to man-in-the-middle attacks.</p>
 <p>The certificate chain validation includes these steps:</p>
 <ul>
@@ -8,7 +9,7 @@
 <p>This rule raises an issue when an implementation of X509TrustManager is not controlling the validity of the certificate (ie: no exception is
 raised). Empty implementations of the <code>X509TrustManager</code> interface are often created to disable certificate validation. The correct
 solution is to provide an appropriate trust store.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class TrustAllManager implements X509TrustManager {
 
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4838.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4838.html
index 8c88139d4af..107d48b90f3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4838.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4838.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>This rule raises an issue when an iteration over the items of a <code>Collection</code> is performed on a super-type of the type handled by the
 <code>Collection</code>.</p>
 <p>Relying on <code>Object</code> or any classes between <code>Object</code> and the real class handled by the <code>Collection</code> is not
 recommended. While it’s accepted by the language, this practice reduces readability of the code and forces to down-cast the item of the
 <code>Collection</code> to be able to call a method on it while simply using the correct type in the iteration makes things more clear and simple.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public Collection&lt;Person&gt; getPersons() { ... }
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   person.getAdress();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (Person person : getPersons()) { // Compliant
   person.getAddress() ;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4925.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4925.html
index 85757e78cf6..c2e3e10f1cd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4925.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4925.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In the past, it was required to load a JDBC driver before creating a <code>java.sql.Connection</code>. Nowadays, when using JDBC 4.0 drivers, this
 is no longer required and <code>Class.forName()</code> can be safely removed because JDBC 4.0 (JDK 6) drivers available in the classpath are
 automatically loaded.</p>
@@ -19,7 +20,7 @@
   <li> <code>net.sourceforge.jtds.jdbc.Driver</code> </li>
   <li> <code>com.ibm.db2.jcc.DB2Driver</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import java.sql.Connection;
 import java.sql.DriverManager;
@@ -35,7 +36,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import java.sql.Connection;
 import java.sql.DriverManager;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4926.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4926.html
index cdb4d5f1f86..13737677f58 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4926.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4926.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Providing a <code>serialVersionUID</code> field on <code>Serializable</code> classes is strongly recommended by the <code>Serializable</code>
 documentation but blindly following that recommendation can be harmful.</p>
 <p><code>serialVersionUID</code> value is stored with the serialized data and this field is verified when deserializing the data to ensure that the
@@ -9,7 +10,7 @@
 <p>Therefore, defining <code>serialVersionUID</code> should be done with care. This rule raises an issue on each <code>serialVersionUID</code> field
 declared on classes implementing <code>Serializable</code> to be sure the presence and the value of the <code>serialVersionUID</code> field is
 challenged and validated by the team.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class Foo implements Serializable {
   private static final long serialVersionUID = 1;
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   private static final long serialVersionUID = 8582433437601788991L;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> Vojtech Ruzicka’s Programming Blog: <a href="https://www.vojtechruzicka.com/explicitly-declare-serialversionuid/">Should I explicitly declare
   serialVersionUID?</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4929.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4929.html
index f95f9e3fedc..d4096dd3b05 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4929.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4929.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When directly subclassing <code>java.io.InputStream</code> or <code>java.io.FilterInputStream</code>, the only requirement is that you implement
 the method <code>read()</code>. However most uses for such streams don’t read a single byte at a time and the default implementation for
 <code>read(byte[],int,int)</code> will call <code>read(int)</code> for every single byte in the array which can create a lot of overhead and is
@@ -5,7 +6,7 @@
 <code>read(byte[],int,int)</code>.</p>
 <p>This rule raises an issue when a direct subclass of <code>java.io.InputStream</code> or <code>java.io.FilterInputStream</code> doesn’t provide an
 override of <code>read(byte[],int,int)</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class MyInputStream extends java.io.InputStream {
   private FileInputStream fin;
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class MyInputStream extends java.io.InputStream {
   private FileInputStream fin;
@@ -40,6 +41,6 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule doesn’t raise an issue when the class is declared <code>abstract</code>.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4968.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4968.html
index 7f9b40cca33..e66dc94a55f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4968.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4968.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>When a type variable or a wildcard declares an upper bound that is <code>final</code>, the parametrization is not generic at all because it accepts
 one and only one type at runtime: the one that is <code>final</code>. Instead of using <code>Generics</code>, it’s simpler to directly use the
 concrete <code>final</code> class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public static &lt;T extends String&gt; T getMyString() { // Noncompliant; String is a "final" class and so can't be extended
  [...]
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public static String getMyString() { // Compliant
   [...]
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4970.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4970.html
index 1564315ba53..420ccdf76ed 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4970.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4970.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>catch</code> block of a checked exception "E" may be hidden because the corresponding <code>try</code> block only throws exceptions
 derived from E.</p>
 <p>These derived exceptions are handled in dedicated <code>catch</code> blocks prior to the <code>catch</code> block of the base exception E.</p>
@@ -5,7 +6,7 @@
 be refactored.</p>
 <p>It is also possible that a single exception type in a multi-catch block may be hidden while the catch block itself is still reachable. In that case
 it is enough to only remove the hidden exception type or to replace it with another type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class HiddenCatchBlock {
 
@@ -30,7 +31,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class HiddenCatchBlock {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4973.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4973.html
index 62de185a9ef..85064c4f483 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4973.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4973.html
@@ -1,20 +1,21 @@
+<h2>Why is this an issue?</h2>
 <p>It’s almost always a mistake to compare two instances of <code>java.lang.String</code> or boxed types like <code>java.lang.Integer</code> using
 reference equality <code>==</code> or <code>!=</code>, because it is not comparing actual value but locations in memory.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String firstName = getFirstName(); // String overrides equals
 String lastName = getLastName();
 
 if (firstName == lastName) { ... }; // Non-compliant; false even if the strings have the same value
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String firstName = getFirstName();
 String lastName = getLastName();
 
 if (firstName != null &amp;&amp; firstName.equals(lastName)) { ... };
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/595">MITRE, CWE-595</a> - Comparison of Object References Instead of Object Contents </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/597">MITRE, CWE-597</a> - Use of Wrong Operator in String Comparison </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4977.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4977.html
index 5c6b7daa397..cea3c50d60a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4977.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4977.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Shadowing makes it impossible to use the type parameter from the outer scope. Also, it can be confusing to distinguish which type parameter is
 being used.</p>
 <p>This rule raises an issue when a type parameter from an inner scope uses the same name as one in an outer scope.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
  public class TypeParameterHidesAnotherType&lt;T&gt; {
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
 
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class NoTypeParameterHiding&lt;T&gt; {
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5128.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5128.html
index 72b883d4274..c215e0ff8ce 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5128.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5128.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>Bean Validation</code> as per defined by JSR 380 can be triggered programmatically or also executed by the <code>Bean Validation</code>
 providers. However something should tell the <code>Bean Validation</code> provider that a variable must be validated otherwise no validation will
 happen. This can be achieved by annotating a variable with <code>javax.validation.Valid</code> and unfortunally it’s easy to forget to add this
@@ -7,7 +8,7 @@
 <p>This rule will run by default on all <code>Class</code>'es and therefore can generate a lot of noise. This rule should be restricted to run only on
 certain layers. For this reason, the "Restrict Scope of Coding Rules" feature should be used to check for missing <code>@Valid</code> annotations only
 on some packages of the application.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import javax.validation.Valid;
 import javax.validation.constraints.NotNull;
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import javax.validation.Valid;
 import javax.validation.constraints.NotNull;
@@ -52,7 +53,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://beanvalidation.org/2.0/spec/">Bean Validation 2.0 (JSR 380)</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5164.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5164.html
index cebb4797328..58c611f0c6a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5164.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5164.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p><code>ThreadLocal</code> variables are supposed to be garbage collected once the holding thread is no longer alive. Memory leaks can occur when
 holding threads are re-used which is the case on application servers using pool of threads.</p>
 <p>To avoid such problems, it is recommended to always clean up <code>ThreadLocal</code> variables using the <code>remove()</code> method to remove
 the current thread’s value for the <code>ThreadLocal</code> variable.</p>
 <p>In addition, calling <code>set(null)</code> to remove the value might keep the reference to <code>this</code> pointer in the map, which can cause
 memory leak in some scenarios. Using <code>remove</code> is safer to avoid this issue.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class ThreadLocalUserSession implements UserSession {
 
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   // some other methods without a call to DELEGATE.remove()
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class ThreadLocalUserSession implements UserSession {
 
@@ -54,9 +55,9 @@ <h2>Compliant Solution</h2>
   // ...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Rule will not detect non-private <code>ThreadLocal</code> variables, because <code>remove()</code> can be called from another class.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.baeldung.com/java-memory-leaks">Understanding Memory Leaks in Java</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5194.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5194.html
index 5ec22ba3072..cb0be2ac369 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5194.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5194.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Many existing switch statements are essentially simulations of switch expressions, where each arm either assigns to a common target variable or
 returns a value. Expressing this as a statement is roundabout, repetitive, and error-prone.</p>
 <p>Java 12 added support for switch expressions, which provide more succinct and less error-prone version of switch.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void day_of_week(DoW day) {
     int numLetters;
@@ -37,7 +38,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int numLetters = switch (day) {
     case MONDAY, FRIDAY, SUNDAY -&gt; 6;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5261.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5261.html
index b1301be9968..a639572dd62 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5261.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5261.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The dangling <code>else</code> problem appears when nested <code>if</code>/<code>else</code>&nbsp;statements are written without curly braces. In
 this case, <code>else</code> is associated with the nearest&nbsp;<code>if</code> but that is not always obvious and sometimes the indentation can also
 be misleading.</p>
@@ -5,7 +6,7 @@
 curly braces.</p>
 <p>Adding curly braces can generally make the code clearer (see rule {rule:java:S121} ), and in this situation of dangling <code>else</code>, it
 really clarifies the intention of the code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
  if (a)
    if (b)
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
  else     // Noncompliant, is the "else" associated with "if(a)" or "if (b)"? (the answer is "if(b)")
    e++;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
  if (a) {
    if (b) {
@@ -23,7 +24,7 @@ <h2>Compliant Solution</h2>
    e++;
  }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://en.wikipedia.org/wiki/Dangling_else">https://en.wikipedia.org/wiki/Dangling_else</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5301.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5301.html
index 99fdb21cc08..8f02db393bb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5301.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5301.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>ActiveMQ can send/receive JMS Object messages (named ObjectMessage in ActiveMQ context) to comply with JMS specification. Internally, ActiveMQ
 relies on Java serialization mechanism for marshaling/unmarshalling of the message payload. Deserialization based on data supplied by the user could
 lead to remote code execution attacks, where the structure of the serialized data is changed to modify the behavior of the object being
 unserialized.</p>
 <p>To limit the risk to be victim of such attack, ActiveMQ 5.12.2+ enforces developers to explicitly whitelist packages that can be exchanged using
 ObjectMessages.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
 factory.setTrustAllPackages(true); // Noncompliant
@@ -12,12 +13,12 @@ <h2>Noncompliant Code Example</h2>
 ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
 // no call to factory.setTrustedPackages(...);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
 factory.setTrustedPackages(Arrays.asList("org.mypackage1", "org.mypackage2"));
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/">OWASP Top 10 2021 Category A8</a> - Software and Data
   Integrity Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5329.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5329.html
index 1c9d507ff28..f6d09511be2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5329.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5329.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>It is very common to pass a collection constructor reference as an argument, for example <code>Collectors.toCollection(ArrayList::new)</code> takes
 the <code>ArrayList::new</code> constructor. When the method expects a <code>java.util.function.Supplier</code> it is perfectly fine. However when the
 method argument type is <code>java.util.function.Function</code> it means that an argument will be passed to the constructor.</p>
 <p>The first argument of Collections constructors is usually an integer representing its "initial capacity". This is generally not what the developer
 expects, but the memory allocation is not visible at first glance.</p>
 <p>This rule raises an issue when a collection constructor is passed by reference as a <code>java.util.function.Function</code> argument.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Arrays.asList(1, 2, 54000).stream().collect(Collectors.toMap(Function.identity(), ArrayList::new)); // Noncompliant, "ArrayList::new" unintentionally refers to "ArrayList(int initialCapacity)" instead of "ArrayList()"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Arrays.asList(1, 2, 54000).stream().collect(Collectors.toMap(Function.identity(), id -&gt; new ArrayList&lt;&gt;())); // Compliant, explicitly show the usage of "id -&gt; new ArrayList&lt;&gt;()" or "id -&gt; new ArrayList&lt;&gt;(id)"
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5344.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5344.html
index 2dc51841ed2..1dc6a780465 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5344.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5344.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A user password should never be stored in clear-text, instead a hash should be produced from it using a secure algorithm:</p>
 <ul>
   <li> not vulnerable to <code>brute force attacks</code>. </li>
@@ -8,7 +9,7 @@
 algorithms, like <code>md5</code> or <code>SHA-family</code> functions are fast to compute the hash and therefore brute force attacks are possible
 (it’s easier to exhaust the entire space of all possible passwords) especially with hardware like GPU, FPGA or ASIC. Modern password hashing
 algorithms such as <code>bcrypt</code>, <code>PBKDF2</code> or <code>argon2</code> are recommended.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Autowired
 public void configureGlobal(AuthenticationManagerBuilder auth, DataSource dataSource) throws Exception {
@@ -28,7 +29,7 @@ <h2>Noncompliant Code Example</h2>
   auth.userDetailsService(...).passwordEncoder(new StandardPasswordEncoder()); // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Autowired
 public void configureGlobal(AuthenticationManagerBuilder auth, DataSource dataSource) throws Exception {
@@ -41,7 +42,7 @@ <h2>Compliant Solution</h2>
   auth.userDetailsService(null).passwordEncoder(new BCryptPasswordEncoder());
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5361.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5361.html
index fa4a2bed5b8..9fadb39c015 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5361.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5361.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>The underlying implementation of <code>String::replaceAll</code> calls the <code>java.util.regex.Pattern.compile()</code> method each time it is
 called even if the first argument is not a regular expression. This has a significant performance cost and therefore should be used with care.</p>
 <p>When <code>String::replaceAll</code> is used, the first argument should be a real regular expression. If it’s not the case,
 <code>String::replace</code> does exactly the same thing as <code>String::replaceAll</code> without the performance drawback of the regex.</p>
 <p>This rule raises an issue for each <code>String::replaceAll</code> used with a <code>String</code> as first parameter which doesn’t contains
 special regex character or pattern.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String init = "Bob is a Bird... Bob is a Plane... Bob is Superman!";
 String changed = init.replaceAll("Bob is", "It's"); // Noncompliant
 changed = changed.replaceAll("\\.\\.\\.", ";"); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String init = "Bob is a Bird... Bob is a Plane... Bob is Superman!";
 String changed = init.replace("Bob is", "It's");
@@ -22,7 +23,7 @@ <h2>Compliant Solution</h2>
 String changed = init.replaceAll("\\w*\\sis", "It's");
 changed = changed.replaceAll("\\.{3}", ";");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> {rule:java:S4248} - Regex patterns should not be created needlessly </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5411.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5411.html
index f7c7c1e0c7d..60b88f91231 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5411.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5411.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>When boxed type <code>java.lang.Boolean</code> is used as an expression to determine the control flow (as described in <a
 href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.5">Java Language Specification §4.2.5 The <code>boolean</code> Type and
 boolean Values</a>) it will throw a <code>NullPointerException</code> if the value is <code>null</code> (as defined in <a
 href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.8">Java Language Specification §5.1.8 Unboxing Conversion</a>).</p>
 <p>It is safer to avoid such conversion altogether and handle the <code>null</code> value explicitly.</p>
 <p>Note, however, that no issues will be raised for Booleans that have already been null-checked.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Boolean b = getBoolean();
 if (b) {  // Noncompliant, it will throw NPE when b == null
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
   bar();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Boolean b = getBoolean();
 if (Boolean.TRUE.equals(b)) {
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   String test = b ? "test" : "";
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.8">Java Language Specification §5.1.8 Unboxing Conversion</a>
   </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5413.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5413.html
index fc7f177ebf7..6c509c1c117 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5413.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5413.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>When <code>List.remove()</code> is called it will shrink the list. If this is done inside the ascending loop iterating through all elements it will
 skip the element after the removed index.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void removeFrom(List&lt;String&gt; list) {
   // expected: iterate over all the elements of the list
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>You can either adjust the loop index to account for the change in the size of the list</p>
 <pre>
 static void removeFrom(List&lt;String&gt; list) {
@@ -33,7 +34,7 @@ <h2>Compliant Solution</h2>
   }
 </pre>
 <p>&nbsp;</p>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The descending loop doesn’t have this issue, because the index will be correct when we loop in descending order</p>
 <pre>
 void removeFrom(List&lt;String&gt; list) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5445.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5445.html
index 2fe2d00ca41..686b069a5b4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5445.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5445.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Using <code>File.createTempFile</code> as the first step in creating a temporary directory causes a race condition and is inherently unreliable and
 insecure. Instead, <code>Files.createTempDirectory</code> (Java 7+) should be used.</p>
 <p>This rule raises an issue when the following steps are taken in immediate sequence:</p>
@@ -7,19 +8,19 @@
   <li> call <code>mkdir</code> on the File object </li>
 </ul>
 <p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>7</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 File tempDir;
 tempDir = File.createTempFile("", ".");
 tempDir.delete();
 tempDir.mkdir();  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Path tempPath = Files.createTempDirectory("");
 File tempDir = tempPath.toFile();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> -
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5527.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5527.html
index bb1d434aa97..42bfade6170 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5527.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5527.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>To establish a SSL/TLS connection not vulnerable to man-in-the-middle attacks, it’s essential to make sure the server presents the right
 certificate.</p>
 <p>The certificate’s hostname-specific data should match the server hostname.</p>
@@ -11,7 +12,7 @@
   <li> a Apache Common Emails’s <code>org.apache.commons.mail.SimpleEmail</code> is used with <code>setSSLOnConnect(true)</code> or
   <code>setStartTLSEnabled(true)</code> or <code>setStartTLSRequired(true)</code> without a call to <code>setSSLCheckServerIdentity(true)</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 URL url = new URL("https://example.org/");
 HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection();
@@ -45,7 +46,7 @@ <h2>Noncompliant Code Example</h2>
   }
 });
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 URL url = new URL("https://example.org/");
 HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection();
@@ -76,7 +77,7 @@ <h2>Compliant Solution</h2>
   }
 });
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5542.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5542.html
index 9e71bf8584b..f94498bd559 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5542.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5542.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Encryption algorithms should use secure modes and padding schemes where appropriate to guarantee data confidentiality and integrity.</p>
 <ul>
   <li> For block cipher encryption algorithms (like AES):
@@ -14,7 +15,7 @@
     </ul>  </li>
   <li> For RSA encryption algorithm, the recommended padding scheme is OAEP. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Cipher.getInstance("AES"); // Noncompliant: by default ECB mode is chosen
 Cipher.getInstance("AES/ECB/NoPadding"); // Noncompliant: ECB doesn't provide serious message confidentiality
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
 
 Cipher.getInstance("RSA/None/NoPadding"); // Noncompliant: RSA without OAEP padding scheme is not recommended
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Cipher.getInstance("AES/GCM/NoPadding");
 
@@ -31,7 +32,7 @@ <h2>Compliant Solution</h2>
 // or the ECB mode can be used for RSA when "None" is not available with the security provider used - in that case, ECB will be treated as "None" for RSA.
 Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
index 0b31d9144a9..6ea8c186971 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p><a href="https://en.wikipedia.org/wiki/Strong_cryptography">Strong cipher algorithms</a> are cryptographic systems resistant to cryptanalysis, they
 are not vulnerable to well-known attacks like brute force attacks for example.</p>
 <p>A general recommendation is to only use cipher algorithms intensively tested and promoted by the cryptographic community.</p>
 <p>More specifically for block cipher, it’s not recommended to use algorithm with a block size inferior than 128 bits.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import javax.crypto.Cipher;
 import java.security.NoSuchAlgorithmException;
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import javax.crypto.Cipher;
 import java.security.NoSuchAlgorithmException;
@@ -46,7 +47,7 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5612.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5612.html
index 78874aca145..c63c1e82418 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5612.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5612.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Lambdas (introduced with Java 8) are a very convenient and compact way to inject a behavior without having to create a dedicated class or method.
 But those lambdas should be used only if the behavior to be injected can be defined in a few lines of code, otherwise the source code can quickly
 become unreadable.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5659.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5659.html
index 7887df6d3e1..191e567d1fd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5659.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5659.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>If a JSON Web Token (JWT) is not signed with a strong cipher algorithm (or not signed at all) an attacker can forge it and impersonate user
 identities.</p>
 <ul>
   <li> Don’t use <code>none</code> algorithm to sign or verify the validity of a token. </li>
   <li> Don’t use a token without verifying its signature before. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>Using <a href="https://github.com/jwtk/jjwt">jwtk/Java JWT</a> library (to verify a signed token (containing a JWS) don’t use the
 <code>parse</code> method as it doesn’t throw an exception if an unsigned token is provided):</p>
 <pre>
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
   .withSubject(LOGIN)
   .build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Using <a href="https://github.com/jwtk/jjwt">Java JWT</a> library (to verify a signed token (containing a JWS) use the <code>parseClaimsJws</code>
 method that will throw an exception if an unsigned token is provided):</p>
 <pre>
@@ -49,7 +50,7 @@ <h2>Compliant Solution</h2>
   .withSubject(LOGIN)
   .build();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5663.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5663.html
index a15e66f7fc6..00800fc8aac 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5663.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5663.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>If a string fits on a single line, without concatenation and escaped newlines, you should probably continue to use a string literal.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String question = """
               What's the point, really?""";
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String question = "What's the point, really?";
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/378">JEP 378: Text Blocks</a> </li>
   <li> <a href="https://openjdk.org/projects/amber/guides/text-blocks-guide">Programmer’s Guide To Text Blocks</a>, by Jim Laskey and Stuart Marks
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5664.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5664.html
index ad1e4865db2..70ddeb773f8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5664.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5664.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Either use only spaces or only tabs for the indentation of a text block. Mixing white space will lead to a result with irregular indentation.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String textBlock = """
         this is
@@ -7,7 +8,7 @@ <h2>Noncompliant Code Example</h2>
         !!!!
       """;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String textBlock = """
         this is
@@ -15,7 +16,7 @@ <h2>Compliant Solution</h2>
         !!!!
       """;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/378">JEP 378: Text Blocks</a> </li>
   <li> <a href="https://openjdk.org/projects/amber/guides/text-blocks-guide">Programmer’s Guide To Text Blocks</a>, by Jim Laskey and Stuart Marks
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5665.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5665.html
index 8483cff1ea4..566a7e26457 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5665.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5665.html
@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>The use of escape sequences is mostly unnecessary in text blocks.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p><code>\n</code> can be replaced by simply introducing the newline, <code>\"\"\"</code> it is sufficient to escape only the first qoute.</p>
 <pre>
 String textBlock = """
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
         !!!!
       """;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String textBlock = """
         \""" this
@@ -17,7 +18,7 @@ <h2>Compliant Solution</h2>
         !!!!
       """;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/378">JEP 378: Text Blocks</a> </li>
   <li> <a href="https://openjdk.org/projects/amber/guides/text-blocks-guide">Programmer’s Guide To Text Blocks</a>, by Jim Laskey and Stuart Marks
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5669.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5669.html
index 81267f8e492..11477cea7a9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5669.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5669.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Passing single <code>null</code> or primitive array argument to the variable arity method may not work as expected. In the case of
 <code>null</code>, it is not passed as array with single element, but the argument itself is <code>null</code>. In the case of a primitive array, if
 the formal parameter is <code>Object...</code>, it is passed as a single element array. This may not be obvious to someone not familiar with such
 corner cases, and it is probably better to avoid such ambiguities by explicitly casting the argument to the desired type.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class A {
   public static void main(String[] args) {
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class A {
   public static void main(String[] args) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5679.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5679.html
index da750c06019..7aa0a2a6589 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5679.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5679.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In 2018, Duo Security found a new vulnerability class that affects SAML-based single sign-on (SSO) systems and this led to the following
 vulnerabilities being disclosed: <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11427">CVE-2017-11427</a>, <a
 href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11428">CVE-2017-11428</a>, <a
@@ -23,7 +24,7 @@
 <p>The attacker will manage to generate a valid &lt;SAMLResponse&gt; content with the account "admin@domain.com.evil.com". He will modify it with XML
 comments to finally be authenticated as "admin@domain.com". To prevent this vulnerability on application using Spring Security SAML relying on
 OpenSAML2, XML comments should be ignored thanks to the property <code>ignoreComments</code> set to <code>true</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.opensaml.xml.parse.BasicParserPool;
 import org.opensaml.xml.parse.ParserPool;
@@ -42,7 +43,7 @@ <h2>Noncompliant Code Example</h2>
   return basicParserPool;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public ParserPool parserPool() {
   return new StaticBasicParserPool(); // Compliant: "ignoreComments" is set to "true" in StaticBasicParserPool constructor
@@ -53,7 +54,7 @@ <h2>Compliant Solution</h2>
   return new BasicParserPool();  // Compliant: "ignoreComments" is set to "true" in BasicParserPool constructor
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/">OWASP Top 10 2021 Category A6</a> - Vulnerable and Outdated
   Components </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5738.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5738.html
index 94d07842261..c9bc5e8e9ba 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5738.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5738.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Java 9 introduced a flag for the <code>@Deprecated</code> annotation, which allows to explicitly say if the deprecated code is planned to be
 removed at some point or not. This is done using <code>forRemoval=true</code> as annotation parameter. The javadoc of the annotation explicitly
 mention the following:</p>
@@ -8,7 +9,7 @@
 <p>While usually deprecated classes, interfaces, and their deprecated members should be avoided rather than used, inherited or extended, those already
 marked for removal are much more sensitive to causing trouble in your code soon. Consequently, any usage of such deprecated code should be avoided or
 removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 /**
  * @deprecated As of release 1.3, replaced by {@link #Fee}. Will be dropped with release 1.4.
@@ -47,7 +48,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/477">MITRE, CWE-477</a> - Use of Obsolete Functions </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6TdGBQ">CERT, MET02-J.</a> - Do not use deprecated or obsolete classes or methods </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5776.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5776.html
index 70983293f61..99b3b835372 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5776.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5776.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When testing exception via <code>org.junit.rules.ExpectedException</code> any code after the raised exception will not be executed, so adding
 subsequent assertions is wrong and misleading. This rule raises an issue when an assertion is done after the "expect(…​)" invocation, only the code
 throwing the expected exception should be after "expect(…​)".</p>
@@ -6,7 +7,7 @@
 since JUnit 4.13 and it allows additional subsequent assertions.</p>
 <p>Alternatively, you could use <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#trycatch-idiom">try-catch idiom</a> for JUnit
 version &lt; 4.13 or if your project does not support lambdas.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Rule
 public ExpectedException thrown = ExpectedException.none();
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
   throw new IndexOutOfBoundsException();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <ul>
   <li> For JUnit &gt;= 4.13, use <a
   href="https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method">org.junit.Assert.assertThrows</a>: </li>
@@ -43,7 +44,7 @@ <h2>Compliant Solution</h2>
 } catch (IndexOutOfBoundsException e) {}
 Assert.assertEquals(0, 1); // Correctly fails.
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://github.com/junit-team/junit4/wiki/Exception-testing">JUnit exception testing documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5777.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5777.html
index b78fca0421f..eaae4a6bf3c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5777.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5777.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When testing exception via <code>@Test</code> annotation, having additional assertions inside that test method can be problematic because any code
 after the raised exception will not be executed. It will prevent you to test the state of the program after the raised exception and, at worst, make
 you&nbsp;misleadingly think that it is executed.</p>
@@ -5,7 +6,7 @@
 href="https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method">org.junit.Assert.assertThrows</a> instead.</p>
 <p>Alternatively, you could use <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#trycatch-idiom">try-catch idiom</a> for JUnit
 version &lt; 4.13 or if your project does not support lambdas.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test(expected = IndexOutOfBoundsException.class)
 public void testShouldFail() {
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   throw new IndexOutOfBoundsException();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <ul>
   <li> For JUnit &gt;= 4.13, use <a
   href="https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method">org.junit.Assert.assertThrows</a>: </li>
@@ -46,7 +47,7 @@ <h2>Compliant Solution</h2>
     Assert.assertEquals(0, 1); // Correctly fails.
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://github.com/junit-team/junit4/wiki/Exception-testing">JUnit exception testing documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5778.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5778.html
index 5169876c5eb..b51b486d549 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5778.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5778.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>When verifying that code raises a runtime exception, a good practice is to avoid having multiple method calls inside the tested code, to be
 explicit about which method call is expected to raise the exception.</p>
 <p>It increases the clarity of the test, and avoid incorrect testing when another method is actually raising the exception.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void testToString() {
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void testToString() {
@@ -39,7 +40,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://github.com/junit-team/junit4/wiki/Exception-testing">JUnit exception testing documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5779.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5779.html
index 7f5d2deed2c..fa6eef5daea 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5779.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5779.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Assertion methods&nbsp;are throwing a "<code>java.lang.AssertionError</code>". If this call is done within the try block of a try-catch cathing a
 similar error, you should make sure to test some properties of the exception. Otherwise, the assertion will never fail.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void should_throw_assertion_error() {
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   throw new AssertionError("My assertion error");
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThrows(AssertionError.class, () -&gt; throwAssertionError());
 </pre>
@@ -26,7 +27,7 @@ <h2>Compliant Solution</h2>
    Assert.assertThat(e.getMessage(), is("My assertion error"));
  }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://github.com/junit-team/junit4/wiki/Exception-testing">JUnit 4 exception testing documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5783.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5783.html
index 0b0360b9f3e..0df19f56a05 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5783.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5783.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>When verifying that code raises an exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about
 what is exactly tested.</p>
 <p>When two of the methods can raise the same <strong>checked</strong> exception, not respecting this good practice is a bug, since it is not possible
 to know what is really tested.</p>
 <p>You should make sure that only one method can raise the expected checked exception in the tested code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void testG() {
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void testG() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5785.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5785.html
index 747b04f1de3..d6020c5e655 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5785.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5785.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Testing equality or nullness with JUnit’s <code>assertTrue()</code> or <code>assertFalse()</code> should be simplified to the corresponding
 dedicated assertion.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Assert.assertTrue(a.equals(b));
 Assert.assertTrue(a == b);
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
 Assert.assertTrue(a != null);
 Assert.assertFalse(a.equals(b));
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Assert.assertEquals(a, b);
 Assert.assertSame(a, b);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5786.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5786.html
index 9f9cd9baeee..4e43326bb90 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5786.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5786.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>JUnit5 is more tolerant regarding the visibilities of Test classes than JUnit4, which required everything to be <code>public</code>.</p>
 <p>In this context, JUnit5 test classes can have any visibility but <code>private</code>, however, it is recommended to use the default package
 visibility, which improves readability of code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 
@@ -23,10 +24,10 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule does not raise an issue about <code>private</code> visibility, because <code>private</code> test methods and classes are systematically
 ignored by JUnit5, without a proper warning. It’s not a <code>Code Smell</code> but a <code>Bug</code> handled by the rule {rule:java:S5810} .</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods">JUnit 5 Test Classes and Methods</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5790.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5790.html
index da9a637f6d6..81c062a144c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5790.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5790.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>If not annotated with <code>@Nested</code>, an inner class containing some tests will never be executed during tests execution. While you could
 still be able to manually run its tests in an IDE, it won’t be the case during the build. By contrast, a static nested class containing some tests
 should not be annotated with <code>@Nested</code>, JUnit5 will not share setup and state with an instance of its enclosing class.</p>
@@ -5,7 +6,7 @@
 annotation.</p>
 <p>Note: This rule does not check if the context in which JUnit 5 is running (e.g. Maven Surefire Plugin) is properly configured to execute static
 nested classes, it could not be the case using the default configuration.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.Nested;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5793.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5793.html
index e6ebcb7e73b..ed074926788 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5793.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5793.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>As mentioned in JUnit5 documentation, it is possible to integrate JUnit4 with JUnit5:</p>
 <blockquote>
   <p>JUnit provides a gentle migration path via a JUnit Vintage test engine which allows existing tests based on JUnit 3 and JUnit 4 to be executed
@@ -77,7 +78,7 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 package org.foo;
 
@@ -133,7 +134,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 package org.foo;
 
@@ -187,7 +188,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4">JUnit 5: Migrating from JUnit4</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5803.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5803.html
index a484a6df01d..777eb8f693a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5803.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5803.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>@VisibleForTesting can be used to mark methods, fields and classes whose visibility restrictions have been relaxed more than necessary for the API
 to allow for easier unit testing.</p>
 <p>Access to such methods, fields and classes only possible thanks to this relaxed visibility is fine for test code, but it should be avoided in
@@ -10,7 +11,7 @@
   <li> Apache Flink: <code>org.apache.flink.annotation.VisibleForTesting</code> </li>
 </ul>
 <p>or any other annotation named <code>VisibleForTesting</code></p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 /** src/main/java/MyObject.java */
 
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
 
 new MyObject().foo; // Noncompliant, foo is accessed from production code
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 /** src/main/java/MyObject.java */
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5808.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5808.html
index cda9ab7ff2b..d30a5791598 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5808.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5808.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Authorizations granted or not to users to access resources of an application should be based on strong decisions. For instance, checking whether
 the user is authenticated or not, has the right roles/privileges. It may also depend on the user’s location, or the date, time when the user requests
 access.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>In a Spring-security web application:</p>
 <ul>
   <li> the <code>vote</code> method of an <a
@@ -44,7 +45,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>In a Spring-security web application:</p>
 <ul>
   <li> the <code>vote</code> method of an <a
@@ -87,9 +88,9 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue is reported when the method throws an exception as it might be used to indicate a strong decision.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5810.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5810.html
index bb027a642c7..156cc5c08cf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5810.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5810.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>JUnit5 is more tolerant regarding the visibilities of Test classes and methods than JUnit4, which required everything to be public. JUnit5 supports
 default package, public and protected visibility, even if it is recommended to use the default package visibility, which improves the readability of
 code.</p>
@@ -7,7 +8,7 @@
   <li> static methods </li>
   <li> methods returning a value without being a TestFactory </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 
@@ -33,7 +34,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import org.junit.jupiter.api.Test;
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5826.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5826.html
index d929a3129aa..f178a0a9790 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5826.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5826.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>setUp()</code> and <code>tearDown()</code> methods (initially introduced with JUnit3 to execute a block of code before and after each
 test) need to be correctly annotated with the equivalent annotation in order to preserve the same behavior when migrating from JUnit3 to JUnit4 or
 JUnit5.</p>
 <p>This rule consequently raise issues on <code>setUp()</code> and <code>tearDown()</code> methods which are not annotated in test classes.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <ul>
   <li> JUnit4: </li>
 </ul>
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
 public void setUp() { ... } // Noncompliant; should be annotated with @BeforeEach
 public void tearDown() { ... }  // Noncompliant; should be annotated with @AfterEach
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <ul>
   <li> JUnit4: </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5831.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5831.html
index 6768ac14bdd..dc5ed3c8701 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5831.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5831.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>A <code>org.assertj.core.configuration.Configuration</code> will be effective only once you call <code>Configuration.apply()</code> or
 <code>Configuration.applyAndDisplay()</code>.</p>
 <p>This rule raises an issue when configurations are set without the appropriate call to apply them.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Configuration configuration = new Configuration(); // Noncompliant, this configuration will not be applied.
 configuration.setComparingPrivateFields(true);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Configuration configuration = new Configuration();
 configuration.setComparingPrivateFields(true);
 configuration.applyAndDisplay();
 // Alternatively: configuration.apply();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://assertj.github.io/doc/#assertj-configuration">AssertJ configuration documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5833.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5833.html
index 7c1e26d080d..514961ff237 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5833.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5833.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Describing, setting error message or adding a comparator in <a href="https://assertj.github.io/doc/">AssertJ</a> must be done before calling the
 assertion, otherwise, settings will not be taken into account.</p>
 <p>This rule raises an issue when one of the method (with all similar methods):</p>
@@ -12,19 +13,19 @@
   <li> <code>filteredOn</code> </li>
 </ul>
 <p>is called without calling an AssertJ assertion afterward.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThat(actual).isEqualTo(expected).as("Description"); // Noncompliant
 assertThat(actual).isEqualTo(expected).withFailMessage("Fail message"); // Noncompliant
 assertThat(actual).isEqualTo(expected).usingComparator(new CustomComparator()); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThat(actual).as("Description").isEqualTo(expected);
 assertThat(actual).withFailMessage("Fail message").isEqualTo(expected);
 assertThat(actual).usingComparator(new CustomComparator()).isEqualTo(expected);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://assertj.github.io/doc/#calling-as-after-the-assertion">AssertJ incorrect usage documentation</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5838.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5838.html
index 8814ef9513a..fd262af83bf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5838.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5838.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>AssertJ contains many assertions methods specific to common types. Both versions will test the same things, but the dedicated one will provide a
 better error message, simplifying the debugging process.</p>
 <p>This rule reports an issue when an assertion can be simplified to a dedicated one.</p>
@@ -317,7 +318,7 @@
     </tr>
   </tbody>
 </table>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThat(getObject()).isEqualTo(null); // Noncompliant
 assertThat(getObject()).isNotEqualTo(null); // Noncompliant - not listed above but also supported
@@ -326,7 +327,7 @@ <h2>Noncompliant Code Example</h2>
 assertThat(getFile().canRead()).isTrue();
 assertThat(getPath().getParent()).isNull();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThat(getObject()).isNull();
 assertThat(getObject()).isNotNull();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5841.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5841.html
index 177e818cdc6..caa1b2d4b4e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5841.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5841.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>AssertJ assertions <code>allMatch</code> and <code>doesNotContains</code> on an empty list always&nbsp;returns true whatever the content of the
 predicate. Despite being correct, you should make explicit if you expect an empty list or not, by adding
 <code>isEmpty()</code>/<code>isNotEmpty()</code> in addition to calling the assertion, or by testing the list’s content further. It will justify the
@@ -13,14 +14,14 @@
   <li> <code>doesNotContainSubsequence</code> </li>
   <li> <code>doesNotContainAnyElementsOf</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;String&gt; logs = getLogs();
 
 assertThat(logs).allMatch(e -&gt; e.contains(“error”)); // Noncompliant, this test pass if logs are empty!
 assertThat(logs).doesNotContain("error"); // Noncompliant, do you expect any log?
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; logs = getLogs();
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5842.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5842.html
index 82d26f894f1..be2c9e5b6f2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5842.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5842.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>A regex should never include a repetitive pattern whose body would match the empty string. This is usually a sign that a part of the regex is
 redundant or does not do what the author intended.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "(?:)*"      // same as the empty regex, the '*' accomplishes nothing
 "(?:|x)*"    // same as the empty regex, the alternative has no effect
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
 "(?:x?)*"    // same as 'x*'
 "(?:x?)+"    // same as 'x*'
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "x*"
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5843.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5843.html
index 716f17cbbdc..030c164058e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5843.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5843.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Overly complicated regular expressions are hard to read and to maintain and can easily cause hard-to-find bugs. If a regex is too complicated, you
 should consider replacing it or parts of it with regular code or splitting it apart into multiple patterns at least.</p>
 <p>The complexity of a regular expression is determined as follows:</p>
@@ -19,13 +20,13 @@
 <p>If a regular expression is split among multiple variables, the complexity is calculated for each variable individually, not for the whole regular
 expression. If a regular expression is split over multiple lines, each line is treated individually if it is accompanied by a comment (either a Java
 comment or a comment within the regular expression), otherwise the regular expression is analyzed as a whole.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 if (dateString.matches("^(?:(?:31(\\/|-|\\.)(?:0?[13578]|1[02]))\\1|(?:(?:29|30)(\\/|-|\\.)(?:0?[13-9]|1[0-2])\\2))(?:(?:1[6-9]|[2-9]\\d)?\\d{2})$|^(?:29(\\/|-|\\.)0?2\\3(?:(?:(?:1[6-9]|[2-9]\\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\\d|2[0-8])(\\/|-|\\.)(?:(?:0?[1-9])|(?:1[0-2]))\\4(?:(?:1[6-9]|[2-9]\\d)?\\d{2})$")) {
     handleDate(dateString);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (dateString.matches("^\\d{1,2}([-/.])\\d{1,2}\\1\\d{1,4}$")) {
     String dateParts[] = dateString.split("[-/.]");
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
     // Put logic to validate and process the date based on its integer parts here
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Regular expressions are only analyzed if all parts of the regular expression are either string literals, effectively final local variables or
 <code>static final</code> fields, all of which can be combined using the '<code>+</code>' operator.</p>
 <p>When a regular expression is split among multiple variables or commented lines, each part is only analyzed if it is syntactically valid by
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5845.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5845.html
index 4e5fbe700ea..b312faabb0b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5845.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5845.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Assertions comparing incompatible types always fail, and negative assertions always pass. At best, negative assertions are useless. At worst, the
 developer loses time trying to fix his code logic before noticing wrong assertions.</p>
 <p>Dissimilar types are:</p>
@@ -17,7 +18,7 @@
   <li> JUnit5 </li>
   <li> AssertJ </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 interface KitchenTool {}
 interface Plant {}
@@ -43,7 +44,7 @@ <h2>Noncompliant Code Example</h2>
   assertThat(tool).isNotEqualTo(plant);    // Noncompliant; unrelated interfaces
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> {rule:java:S2159} - Silly equality checks should not be made </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5846.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5846.html
index aa74b017349..2ecab023162 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5846.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5846.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>One way to test for empty lines is to use the regex <code>"^$"</code>, which can be extremely handy when filtering out empty lines from collections
 of Strings, for instance. With regard to this, the Javadoc for <a
 href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html">Pattern (Line Terminators)</a> states the
@@ -13,7 +14,7 @@
 <p>Therefore, when searching for empty lines using a multi-line regular expression, you should also check whether the string is empty.</p>
 <p>This rule is raising an issue every time a pattern that can match the empty string is used with <code>MULTILINE</code> flag and without calling
 <code>isEmpty()</code> on the string.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 static final Pattern p = Pattern.compile("^$", Pattern.MULTILINE); // Noncompliant
 
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
 System.out.println(containsEmptyLines("a\n\nb")); // correctly prints 'true'
 System.out.println(containsEmptyLines("")); // incorrectly prints 'false'
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 static final Pattern p = Pattern.compile("^$", Pattern.MULTILINE);
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5850.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5850.html
index 117e9b1e9af..82178c717d3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5850.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5850.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In regular expressions, anchors (<code>^</code>, <code>$</code>, <code>\A</code>, <code>\Z</code> and <code>\z</code>) have higher precedence than
 the <code>|</code> operator. So in a regular expression like <code>^alt1|alt2|alt3$</code>, <code>alt1</code> would be anchored to the beginning,
 <code>alt3</code> to the end and <code>alt2</code> wouldn’t be anchored at all. Usually the intended behavior is that all alternatives are anchored at
@@ -5,11 +6,11 @@
 <p>In cases where it is intended that the anchors only apply to one alternative each, adding (non-capturing) groups around the anchors and the parts
 that they apply to will make it explicit which parts are anchored and avoid readers misunderstanding the precedence or changing it because they
 mistakenly assume the precedence was not intended.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ^a|b|c$
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ^(?:a|b|c)$
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5853.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5853.html
index 19ce3fa1365..5bcade633d2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5853.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5853.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>AssertJ assertions methods targeting the same object can be chained instead of using multiple <code>assertThat</code>. It avoids duplication and
 increases the clarity of the code.</p>
 <p>This rule raises an issue when multiples <code>assertThat</code> target the same tested value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThat(someList).hasSize(3);
 assertThat(someList).contains("something");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThat(someList)
   .hasSize(3)
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5854.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5854.html
index 89da1d3ddb7..7adfcbf64dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5854.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5854.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>Characters like <code>'é'</code> can be expressed either as a single code point or as a cluster of the letter <code>'e'</code> and a combining
 accent mark. Without the <code>CANON_EQ</code> flag, a regex will only match a string in which the characters are expressed in the same way.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String s = "e\u0300";
 Pattern p = Pattern.compile("é|ë|è"); // Noncompliant
 System.out.println(p.matcher(s).replaceAll("e")); // print 'è'
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String s = "e\u0300";
 Pattern p = Pattern.compile("é|ë|è", Pattern.CANON_EQ);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5855.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5855.html
index 28c51c94526..1057fe0800f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5855.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5855.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>If an alternative in a regular expression only matches things that are already matched by another alternative, that alternative is redundant and
 serves no purpose.</p>
 <p>In the best case this means that the offending subpattern is merely redundant and should be removed. In the worst case it’s a sign that this regex
 does not match what it was intended to match and should be reworked.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "[ab]|a"   // The "|a" is redundant because "[ab]" already matches "a"
 ".*|a"     // .* matches everything, so any other alternative is redundant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "[ab]"
 ".*"
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5856.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5856.html
index 2a9e971233f..948afac2b22 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5856.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5856.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Regular expressions have their own syntax that is understood by regular expression engines. Those engines will throw an exception at runtime if
 they are given a regular expression that does not conform to that syntax.</p>
 <p>To avoid syntax errors, special characters should be escaped with backslashes when they are intended to be matched literally and references to
 capturing groups should use the correctly spelled name or number of the group.</p>
 <p>To match a literal string instead of a regular expression, either all special characters should be escaped, the <code>Pattern.LITERAL</code> flag
 or methods that don’t use regular expressions should be used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("([");
 str.matches("([");
 str.replaceAll("([", "{");
 str.matches("(\\w+-(\\d+)");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("\\(\\[");
 Pattern.compile("([", Pattern.LITERAL);
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5857.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5857.html
index 88bceebf777..8b1d3db6f48 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5857.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5857.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Using reluctant quantifiers (also known as lazy or non-greedy quantifiers) in patterns can often lead to needless backtracking, making the regex
 needlessly inefficient and potentially vulnerable to <a href="https://www.regular-expressions.info/catastrophic.html">catastrophic backtracking</a>.
 Particularly when using <code>.*?</code> or <code>.+?</code> to match anything up to some terminating character, it is usually a better idea to
 instead use a greedily or possessively quantified negated character class containing the terminating character. For example <code>&lt;.+?&gt;</code>
 should be replaced with <code>&lt;[^&gt;]++&gt;</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;.+?&gt;
 ".*?"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;[^&gt;]++&gt;
 "[^"]*+"
@@ -18,7 +19,7 @@ <h2>Compliant Solution</h2>
 &lt;[^&gt;]+&gt;
 "[^"]*"
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule only applies in cases where the reluctant quantifier can easily be replaced with a negated character class. That means the repetition has
 to be terminated by a single character or character class. Patterns such as the following, where the alternatives without reluctant quantifiers are
 more complicated, are therefore not subject to this rule:</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5860.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5860.html
index e11ece9dc33..2f1d7ced914 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5860.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5860.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Why use named groups only to never use any of them later on in the code?</p>
 <p>This rule raises issues every time named groups are:</p>
 <ul>
@@ -5,7 +6,7 @@
   <li> defined but called elsewhere in the code by their number instead; </li>
   <li> referenced while not defined. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String date = "01/02";
 
@@ -28,7 +29,7 @@ <h2>Noncompliant Code Example</h2>
   checkScore(score);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String date = "01/02";
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5863.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5863.html
index 3eb6c293d91..b1442eccc05 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5863.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5863.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Assertions comparing an object to itself are more likely to be bugs due to developer’s carelessness.</p>
 <p>This rule raises an issue when the actual expression matches the expected expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThat(actual).isEqualTo(actual); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThat(actual).isEqualTo(expected);
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>In a unit test validating the <code>equals(...)</code> and <code>hashCode()</code> methods, it’s legitimate to compare an object to itself. This
 rule does not raise an issue for <code>isEqualTo</code>, <code>assertEquals</code> or <code>hasSameHashCodeAs</code> when the unit test name contains
 (case insensitive): <code>equal</code>, <code>hash_?code</code>, <code>object_?method</code>. For example, in tests with the following names:
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5866.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5866.html
index d27fcf5b941..696cfad77df 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5866.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5866.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>By default case insensitivity only affects letters in the ASCII range. This can be changed by either passing <code>Pattern.UNICODE_CASE</code> or
 <code>Pattern.UNICODE_CHARACTER_CLASS</code> as an argument to <code>Pattern.compile</code> or using <code>(?u)</code> or <code>(?U)</code> within the
 regex.</p>
 <p>If not done, regular expressions involving non-ASCII letters will still handle those letters as being case sensitive.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("söme pättern", Pattern.CASE_INSENSITIVE);
 str.matches("(?i)söme pättern");
 str.matches("(?i:söme) pättern");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("söme pättern", Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE);
 str.matches("(?iu)söme pättern");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5867.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5867.html
index b7dd1f42a38..4dfc2ff028f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5867.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5867.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>When using POSIX classes like <code>\p{Alpha}</code> without the <code>UNICODE_CHARACTER_CLASS</code> flag or when using hard-coded character
 classes like <code>"[a-zA-Z]"</code>, letters outside of the ASCII range, such as umlauts, accented letters or letter from non-Latin languages, won’t
 be matched. This may cause code to incorrectly handle input containing such letters.</p>
 <p>To correctly handle non-ASCII input, it is recommended to use Unicode classes like <code>\p{IsAlphabetic}</code>. When using POSIX classes, Unicode
 support should be enabled by either passing <code>Pattern.UNICODE_CHARACTER_CLASS</code> as a flag to <code>Pattern.compile</code> or by using
 <code>(?U)</code> inside the regex.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("[a-zA-Z]");
 Pattern.compile("\\p{Alpha}");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("\\p{IsAlphabetic}"); // matches all letters from all languages
 Pattern.compile("\\p{IsLatin}"); // matches latin letters, including umlauts and other non-ASCII variations
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5868.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5868.html
index 83ad1ec21b4..73151b443e1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5868.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5868.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When placing Unicode <a href="https://unicode.org/glossary/#grapheme_cluster">Grapheme Clusters</a> (characters which require to be encoded in
 multiple <a href="https://unicode.org/glossary/#code_point">Code Points</a>) inside a character class of a regular expression, this will likely lead
 to unintended behavior.</p>
@@ -6,11 +7,11 @@
 enumeration <code>[c\u{0308}]</code> instead. It will, therefore, match every <code>'c'</code> and every <em>umlaut</em> that isn’t expressed as a
 single codepoint, which is extremely unlikely to be the intended behavior.</p>
 <p>This rule raises an issue every time Unicode Grapheme Clusters are used within a character class of a regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "cc̈d̈d".replaceAll("[c̈d̈]", "X"); // Noncompliant, print "XXXXXX" instead of expected "cXXd".
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "cc̈d̈d".replaceAll("c̈|d̈", "X"); // print "cXXd"
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5869.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5869.html
index c2851c7379a..cb3480162c4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5869.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5869.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Character classes in regular expressions are a convenient way to match one of several possible characters by listing the allowed characters or
 ranges of characters. If the same character is listed twice in the same character class or if the character class contains overlapping ranges, this
 has no effect.</p>
@@ -6,12 +7,12 @@
 mistake is trying to use a range like <code>[0-99]</code> to match numbers of up to two digits, when in fact it is equivalent to <code>[0-9]</code>.
 Another common cause is forgetting to escape the <code>-</code> character, creating an unintended range that overlaps with other characters in the
 character class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 str.matches("[0-99]") // Noncompliant, this won't actually match strings with two digits
 str.matches("[0-9.-_]") // Noncompliant, .-_ is a range that already contains 0-9 (as well as various other characters such as capital letters)
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 str.matches("[0-9]{1,2}")
 str.matches("[0-9.\\-_]")
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5876.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5876.html
index 1b5bd3adfbe..7fe6737a1d1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5876.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5876.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Session fixation attacks occur when an attacker can force a legitimate user to use a session ID that he knows. To avoid fixation attacks, it’s a
 good practice to generate a new session each time a user authenticates and delete/invalidate the existing session (the one possibly known by the
 attacker).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>In a Spring Security’s context, session fixation protection is enabled by default but can be disabled with <code>sessionFixation().none()</code>
 method:</p>
 <pre>
@@ -11,7 +12,7 @@ <h2>Noncompliant Code Example</h2>
      .sessionFixation().none(); // Noncompliant: the existing session will continue
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>In a Spring Security’s context, session fixation protection can be enabled as follows:</p>
 <pre>
 @Override
@@ -25,7 +26,7 @@ <h2>Compliant Solution</h2>
      .sessionFixation().migrateSession(); // Compliant: a new session is created, the old one is invalidated and the attributes from the old session are copied over.
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5917.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5917.html
index 96e98ea1d31..a1c646c23ad 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5917.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5917.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When creating a <code>DateTimeFormatter</code> using the <code>WeekFields.weekBasedYear()</code> temporal field, the resulting year number may be
 off by 1 at the beginning of a new year (when the date to format is in a week that is shared by two consecutive years).</p>
 <p>Using this year number in combination with an incompatible week temporal field yields a result that may be confused with the first week of the
@@ -6,7 +7,7 @@
 <code>WeekFields.weekOfWeekBasedYear()</code>.</p>
 <p>Alternatively the temporal field <code>ChronoField.ALIGNED_WEEK_OF_YEAR</code> can be used together with a regular year (but not the week based
 year).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 new DateTimeFormatterBuilder()
       .appendValue(ChronoField.YEAR, 4) // Noncompliant: using week of week-based year with regular year
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
       .toFormatter();
 </pre>
 <p>Here the first two formatters would wrongly format the 1st of January 2016 as "2016-53" while the last one would format it as "2015-01"</p>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 new DateTimeFormatterBuilder()
       .appendValue(WeekFields.ISO.weekBasedYear(), 4)
@@ -49,7 +50,7 @@ <h2>Compliant Solution</h2>
 </pre>
 <p>Here the first formatter would format the 1st of January 2016 as "2015-53" while the last two would produce "2016-01", both of which are correct
 depending on how you count the weeks.</p>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>No issue is raised when week-based year is not used in combination with a week temporal field.</p>
 <p>Similarly, no issue is raised if week of week-based year is not used in combination with a year temporal field.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5958.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5958.html
index 58f658e0c8c..81901a2d425 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5958.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5958.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Unlike similar AssertJ methods testing exceptions (<code>assertThatCode()</code>, <code>assertThatExceptionOfType()</code>, …​), the
 <code>assertThatThrownBy()</code> method can be used alone, failing if the code did not raise any exception.</p>
 <p>Still, only testing that an exception was raised is not enough to guarantee that it was the expected one, and you should test the exception type or
 content further. In addition, it will make explicit what you are expecting, without relying on side-effects.</p>
 <p>This rule raises an issue when <code>assertThatThrownBy</code> is used, without testing the exception further.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThatThrownBy(() -&gt; shouldThrow()); // Noncompliant, is it really the exception you expected?
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThatThrownBy(() -&gt; shouldThrow()).isInstanceOf(IOException.class);
 //or
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5960.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5960.html
index f004e133d5a..017a27193c8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5960.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5960.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Assertions are intended to be used in <strong>test</strong> code, but not in <strong>production</strong> code. It is confusing, and might lead to
 <code>ClassNotFoundException</code> when the build tools only provide the required dependency in test scope.</p>
 <p>In addition, assertions will throw a sub-class of <code>Error</code>: <code>AssertionError</code>, which should be avoided in production code.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5961.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5961.html
index 2f765d7bd36..8de243fb904 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5961.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5961.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>A common good practice is to write test methods targeting only one logical concept, that can only fail for one reason.</p>
 <p>While it might make sense to have more than one assertion to test one concept, having too many is a sign that a test became too complex and should
 be refactored to multiples ones.</p>
 <p>This rule will report any test method containing more than a given number of assertion.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a parameter of 2.</p>
 <pre>
 @Test
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   assertEquals(3, g(1));
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 void test_f() {
   assertEquals(1, f(1));
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5967.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5967.html
index 697ace3a0e7..ec8e40dbdb6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5967.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5967.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Annotating unit tests with more than one test-related annotation is not only useless but could also result in unexpected behavior like failing
 tests or unwanted side-effects.</p>
 <p>This rule reports an issue when a test method is annotated with more than one of the following competing annotation:</p>
@@ -8,7 +9,7 @@
   <li> @TestFactory </li>
   <li> @TestTemplate </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 @RepeatedTest(2) // Noncompliant, this test will be repeated 3 times
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
 @MethodSource("methodSource")
 void test2(int argument) { } // Noncompliant, this test will fail with ParameterResolutionException
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @RepeatedTest(2)
 void test() { }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5969.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5969.html
index 8cf39a0e5ca..7c04c7bc666 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5969.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5969.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>If you end up mocking every non-private method of a class in order to write tests, it is a strong sign that your test became too complex, or that
 you misunderstood the way you are supposed to use the mocking mechanism.</p>
 <p>You should either refactor the test code into multiple units, or consider using the class itself, by either directly instantiating it, or creating
 a new one inheriting from it, with the expected behavior.</p>
 <p>This rule reports an issue when every member of a given class are mocked.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 void test_requiring_MyClass() {
@@ -18,7 +19,7 @@ <h2>Noncompliant Code Example</h2>
   abstract int g();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 void test_requiring_MyClass() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5970.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5970.html
index 2b71b7b45f0..da24428be2c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5970.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5970.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>The Spring framework comes with dedicated classes to help writing better and simpler unit tests. In particular, when testing applications built on
 top of Spring MVC, it is recommended to use Spring’s <code>ModelAndViewAssert</code> assertions class, instead of manually testing MVC’s
 properties.</p>
 <p>&nbsp;</p>
 <p>This rule raises an issue when&nbsp;Spring’s <code>ModelAndViewAssert</code> assertions should be used instead of manual testing.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 ModelAndView mav = getMyModelAndView();
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 Assert.assertFalse((Boolean) mav.getModelMap().get("myAttribute"));
 Assert.assertEquals(myObject, mav.getModelMap().get("myAttribute"));
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 ModelAndView mav = getMyModelAndView();
 
@@ -21,7 +22,7 @@ <h2>Compliant Solution</h2>
 ModelAndViewAssert.assertModelAttributeValue(mav, "myAttribute", Boolean.FALSE);
 ModelAndViewAssert.assertModelAttributeValue(mav, "myAttribute", myObject);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#unit-testing-spring-mvc">Unit Testing
   Spring MVC</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5973.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5973.html
index 2160eebf60a..0ad7bbd168b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5973.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5973.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Unstable / flaky tests are tests which sometimes pass and sometimes fail, without any code change. Obviously, they slow down developments when
 engineers have to rerun failed tests. However the real problem is that you can’t completely trust these tests, they might fail for many different
 reasons and you don’t know if any of them will happen in production.</p>
@@ -5,7 +6,7 @@
 definitely be fixed. The more flaky tests you add, the more chances there are for a bug to arrive in production.</p>
 <p>This rule raises an issue when the annotation <code>org.testng.annotations.Test</code> is given a <code>successPercentage</code> argument with a
 value lower than <code>100</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.testng.annotations.Test;
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://testng.org/doc/documentation-main.html#annotations">TestNG documentation - Annotations</a> </li>
   <li> <a href="https://engineering.atspotify.com/2019/11/18/test-flakiness-methods-for-identifying-and-dealing-with-flaky-tests/">Test Flakiness -
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5976.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5976.html
index c65e4332ec8..3b5f914a1d6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5976.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5976.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>When multiple tests differ only by a few hardcoded values they should be refactored as a single "parameterized" test. This reduces the chances of
 adding a bug and makes them more readable. Parameterized tests exist in most test frameworks (JUnit, TestNG, etc…​).</p>
 <p>The right balance needs of course to be found. There is no point in factorizing test methods when the parameterized version is a lot more complex
 than initial tests.</p>
 <p>This rule raises an issue when at least 3 tests could be refactored as one parameterized test with less than 4 parameters. Only test methods which
 have at least one duplicated statement are considered.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>with JUnit 5</p>
 <pre>
 import static org.junit.jupiter.api.Assertions.assertEquals;
@@ -53,7 +54,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 import static org.junit.jupiter.api.Assertions.assertEquals;
 
@@ -83,7 +84,7 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://phauer.com/2019/modern-best-practices-testing-java/#use-parameterized-tests">Modern Best Practices for Testing in Java -
   Philipp Hauer</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5977.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5977.html
index 195ba545b34..9dc0bf2aa48 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5977.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5977.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Tests should always:</p>
 <ul>
   <li> Make sure that production code behaves as expected, including edge cases. </li>
@@ -10,17 +11,17 @@
 Some libraries exist to make all this easier. You can for example use property-based testing libraries such as <a
 href="https://github.com/jlink/jqwik">jqwik</a>.</p>
 <p>This rule raises an issue when <code>new Random()</code> or <code>UUID.randomUUID()</code> are called in test code.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int userAge = new Random().nextInt(42);  // Noncompliant
 UUID userID = UUID.randomUUID(); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int userAge = 31;
 UUID userID = UUID.fromString("00000000-000-0000-0000-000000000001");
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://phauer.com/2019/modern-best-practices-testing-java/#use-fixed-data-instead-of-randomized-data">Modern Best Practices for
   Testing in Java - Philipp Hauer</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5979.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5979.html
index 8611af3da42..189fe5a4c3a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5979.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5979.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Objects annotated with Mockito annotations <code>@Mock</code>,&nbsp;<code>@Spy</code>,&nbsp;<code>@Captor</code>,&nbsp;or <code>@InjectMocks</code>
 need to be initialized explicitly.</p>
 <p>There are several ways to do this:</p>
@@ -11,7 +12,7 @@
 <p>Note that this only applies to annotated Mockito objects. It is not necessary to initialize objects instantiated via <code>Mockito.mock()</code> or
 <code>Mockito.spy()</code>.</p>
 <p>This rule raises an issue when a test class uses uninitialized mocks.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class FooTest { // Noncompliant: Mockito initialization missing
   @Mock private Bar bar;
@@ -31,7 +32,7 @@ <h2>Noncompliant Code Example</h2>
     private Bar bar;
   }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @RunWith(MockitoJUnitRunner.class)
 public class FooTest {
@@ -89,7 +90,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://site.mockito.org/javadoc/current/org/mockito/MockitoAnnotations.html">Mockito documentation - MockitoAnnotations</a> </li>
   <li> <a href="https://site.mockito.org/javadoc/current/org/mockito/junit/MockitoRule.html">Mockito documentation - MockitoRule </a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5993.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5993.html
index c061c7d48d8..cd424fba2fd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5993.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5993.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Abstract classes should not have public constructors. Constructors of abstract classes can only be called in constructors of their subclasses. So
 there is no point in making them public. The <code>protected</code> modifier should be enough.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public abstract class AbstractClass1 {
     public AbstractClass1 () { // Noncompliant, has public modifier
@@ -8,7 +9,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public abstract class AbstractClass2 {
     protected AbstractClass2 () {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5994.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5994.html
index f1b36d323e2..79b28188a4a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5994.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5994.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Possessive quantifiers in Regex patterns like below improve performance by eliminating needless backtracking:</p>
 <pre>
 ?+ , *+ , ++ , {n}+ , {n,}+ , {n,m}+
@@ -5,12 +6,12 @@
 <p>But because possessive quantifiers do not keep backtracking positions and never give back, the following sub-patterns should not match only similar
 characters. Otherwise, possessive quantifiers consume all characters that could have matched the following sub-patterns and nothing remains for the
 following sub-patterns.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern pattern1 = Pattern.compile("a++abc");       // Noncompliant, the second 'a' never matches
 Pattern pattern2 = Pattern.compile("\\d*+[02468]"); // Noncompliant, the sub-pattern "[02468]" never matches
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern pattern1 = Pattern.compile("aa++bc");            // Compliant, for example it can match "aaaabc"
 Pattern pattern2 = Pattern.compile("\\d*+(?&lt;=[02468])"); // Compliant, for example it can match an even number like "1234"
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5996.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5996.html
index 0de2b9fba8d..16f25f8e6a5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5996.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5996.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>In regular expressions the boundaries <code>^</code> and <code>\A</code> can only match at the beginning of the input (or, in case of
 <code>^</code> in combination with the <code>MULTILINE</code> flag, the beginning of the line) and <code>$</code>, <code>\Z</code> and <code>\z</code>
 only at the end.</p>
 <p>These patterns can be misused, by accidentally switching <code>^</code> and <code>$</code> for example, to create a pattern that can never
 match.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // This can never match because $ and ^ have been switched around
 Pattern.compile("$[a-z]+^"); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("^[a-z]+$");
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5998.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5998.html
index bf29decf2af..58451f9ba46 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5998.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5998.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The Java regex engine uses recursive method calls to implement backtracking. Therefore when a repetition inside a regular expression contains
 multiple paths (i.e. the body of the repetition contains an alternation (<code>|</code>), an optional element or another repetition), trying to match
 the regular expression can cause a stack overflow on large inputs. This does not happen when using a possessive quantifier (such as <code>*+</code>
@@ -10,13 +11,13 @@
 15000 characters.</p>
 <p>Since often times stack growth can’t easily be avoided, this rule will only report issues on regular expressions if they can cause a stack overflow
 on realistically sized inputs. You can adjust the <code>maxStackConsumptionFactor</code> parameter to adjust this.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("(a|b)*"); // Noncompliant
 Pattern.compile("(.|\n)*"); // Noncompliant
 Pattern.compile("(ab?)*"); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("[ab]*"); // Character classes don't cause recursion the way that '|' does
 Pattern.compile("(?s).*"); // Enabling the (?s) flag makes '.' match line breaks, so '|\n' isn't necessary
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6001.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6001.html
index 71d1227e918..d6d4604a40b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6001.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6001.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>When a back reference in a regex refers to a capturing group that hasn’t been defined yet (or at all), it can never be matched. Named back
 references throw a <code>PatternSyntaxException</code> in that case; numeric back references fail silently when they can’t match, simply making the
 match fail.</p>
 <p>When the group is defined before the back reference but on a different control path (like in <code>(.)|\1</code> for example), this also leads to a
 situation where the back reference can never match.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("\\1(.)"); // Noncompliant, group 1 is defined after the back reference
 Pattern.compile("(.)\\2"); // Noncompliant, group 2 isn't defined at all
 Pattern.compile("(.)|\\1"); // Noncompliant, group 1 and the back reference are in different branches
 Pattern.compile("(?&lt;x&gt;.)|\\k&lt;x&gt;"); // Noncompliant, group x and the back reference are in different branches
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("(.)\\1");
 Pattern.compile("(?&lt;x&gt;.)\\k&lt;x&gt;");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6002.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6002.html
index 27ffdff228c..e8dc2060d6e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6002.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6002.html
@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Lookahead assertions are a regex feature that makes it possible to look ahead in the input without consuming it. It is often used at the end of
 regular expressions to make sure that substrings only match when they are followed by a specific pattern.</p>
 <p>However, they can also be used in the middle (or at the beginning) of a regex. In that case there is the possibility that what comes after the
 lookahead does not match the pattern inside the lookahead. This makes the lookahead impossible to match and is a sign that there’s a mistake in the
 regular expression that should be fixed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("(?=a)b"); // Noncompliant, the same character can't be equal to 'a' and 'b' at the same time
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("(?&lt;=a)b");
 Pattern.compile("a(?=b)");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6019.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6019.html
index aade8583b5d..718edac19d9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6019.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6019.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>When a reluctant quantifier (such as <code>*?</code> or <code>+?</code>) is followed by a pattern that can match the empty string or directly by
 the end of the regex, it will always match the empty string when used with methods that find partial matches (such as <code>find</code>,
 <code>replaceAll</code>, <code>split</code> etc.).</p>
 <p>Similarly, when used with methods that find full matches, a reluctant quantifier that’s followed directly by the end of the regex (or a pattern
 that always matches the empty string, such as <code>()</code>) behaves indistinguishably from a greedy quantifier while being less efficient.</p>
 <p>This is likely a sign that the regex does not work as intended.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "start123endstart456".replaceAll("start\\w*?(end)?", "x"); // Noncompliant. In contrast to what one would expect, the result is not "xx".
 str.matches("\\d*?"); // Noncompliant. Matches the same as "\d*", but will backtrack in every position.
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "start123endstart456".replaceAll("start\\w*?(end|$)", "x"); // Result is "xx".
 str.matches("\\d*");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6035.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6035.html
index 2b160c7f746..d8e6e1a8ac6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6035.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6035.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>When an alternation contains multiple alternatives that consist of a single character, it can be rewritten as a character class. This should be
 preferred because it is more efficient and can even help prevent stack overflows when used inside a repetition (see rule {rule:java:S5998}).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("a|b|c"); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("[abc]");
 // or
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6068.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6068.html
index ba58846d5cf..793bad2bdcf 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6068.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6068.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Mockito provides <em>argument matchers</em> for flexibly stubbing or verifying method calls.</p>
 <p><code>Mockito.verify()</code>, <code>Mockito.when()</code>, <code>Stubber.when()</code> and <code>BDDMockito.given()</code> each have overloads
 with and without argument matchers.</p>
 <p>However, the default matching behavior (i.e. without argument matchers) uses <code>equals()</code>. If only the matcher
 <code>org.mockito.ArgumentMatchers.eq()</code> is used, the call is equivalent to the call without matchers, i.e. the <code>eq()</code> is not
 necessary and can be omitted. The resulting code is shorter and easier to read.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void myTest() {
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   verify(foo).bar(eq(v1), eq(v2), eq(v3));   // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void myTest() {
@@ -24,7 +25,7 @@ <h2>Compliant Solution</h2>
   verify(foo).bar(v1, v2, v3);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#argument_matchers">Mockito documentation</a> -
   argument matchers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6070.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6070.html
index f4fb3a2e680..266feaea12d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6070.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6070.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In regular expressions the escape sequence <code>\cX</code>, where the X stands for any character that’s either <code>@</code>, any capital ASCII
 letter, <code>[</code>, <code>\</code>, <code>]</code>, <code>^</code> or <code>_</code>, represents the control character that "corresponds" to the
 character following <code>\c</code>, meaning the control character that comes 64 bytes before the given character in the ASCII encoding.</p>
@@ -7,12 +8,12 @@
 in Java, where the value of the character is always XORed with 64 without checking that this operation makes sense. Since this won’t lead to a
 sensible result for characters that are outside of the <code>@</code> to <code>_</code> range, using <code>\c</code> with such characters is almost
 certainly a mistake.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("\\ca"); // Noncompliant, 'a' is not an upper case letter
 Pattern.compile("\\c!"); // Noncompliant, '!' is outside of the '@'-'_' range
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("\\cA"); // Compliant, this will match the "start of heading" control character
 Pattern.compile("\\c^"); // Compliant, this will match the "record separator" control character
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6073.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6073.html
index 62909f5fc4c..16f0c6118f2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6073.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6073.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Mockito provides <em>argument matchers</em> and <em>argument captors</em> for flexibly stubbing or verifying method calls.</p>
 <p><code>Mockito.verify()</code>, <code>Mockito.when()</code>, <code>Stubber.when()</code> and <code>BDDMockito.given()</code> each have overloads
 with and without argument matchers.</p>
 <p>However, if argument matchers or captors are used only on some of the parameters, all the parameters need to have matchers as well, otherwise an
 <code>InvalidUseOfMatchersException</code> will be thrown.</p>
 <p>This rule consequently raises an issue every time matchers are not used on all the parameters of a stubbed/verified method.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Test
 public void myTest() {
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
   verify(foo).bar(captor.capture(), i1, any()); // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Test
 public void myTest() {
@@ -28,7 +29,7 @@ <h2>Compliant Solution</h2>
   verify(foo).bar(captor.capture(), any(), any());
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#argument_matchers">Mockito documentation</a> -
   argument matchers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6103.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6103.html
index 6aa1b3429f3..4ed641a9898 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6103.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6103.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>AssertJ assertions taking <code>Consumer</code> objects as arguments are expected to contain "requirements", which should themselves be expressed
 as assertions. This concerns the following methods: <a
 href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#allSatisfy-java.util.function.Consumer-">allSatisfy</a>,
@@ -15,12 +16,12 @@
 <p>These methods are assuming the&nbsp;<code>Consumer</code>&nbsp;will do the assertions itself. If you do not do any assertion in the
 <code>Consumer</code>, it probably means that you are inadvertently only partially testing your object.</p>
 <p>This rule raises an issue when a <code>Consumer</code> argument of any of the above methods does not contain any assertion.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 assertThat(myObject).isInstanceOfSatisfying(String.class, s -&gt; "Hello".equals(s)); // Noncompliant - not testing the string value
 assertThat(myObject).satisfies("Hello"::equals); // Noncompliant - not testing the string value
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 assertThat(myObject).isInstanceOfSatisfying(String.class, s -&gt; assertThat(s).isEqualTo("Hello"));
 assertThat(myObject).satisfies(obj -&gt; assertThat(obj).isEqualTo("Hello"));
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6104.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6104.html
index cd37112c448..3018d28f9c6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6104.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6104.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Map <a
 href="https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-">computeIfAbsent</a>&nbsp;and <a
 href="https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfPresent-K-java.util.function.BiFunction-">computeIfPresent</a> methods are
@@ -6,12 +7,12 @@
 <code>computeIfPresent</code>, if the key is present the entry will be removed. These methods should therefore not be used to conditionally add an
 entry with a null value. The traditional way should be used instead.</p>
 <p>This rule raises an issue when <code>computeIfAbsent</code> or <code>computeIfPresent</code> is used with a lambda always returning null.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 map.computeIfAbsent(key, k -&gt; null); // Noncompliant, the map will not contain an entry key-&gt;null.
 map.computeIfPresent(key, (k, oldValue) -&gt; null); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 if (!map.containsKey(key)) {
     map.put(key, null);
@@ -20,7 +21,8 @@ <h2>Compliant Solution</h2>
     map.put(key, null);
 }
 </pre>
-<h2>See Also</h2>
+<h2>Resources</h2>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S3824} - "Map.get" and value test should be replaced with a single method call </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6126.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6126.html
index d42ca43dc32..5d7affe703f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6126.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6126.html
@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 15 Text Blocks are now official and can be used. The most common pattern for multiline strings in Java &lt; 15 was to write String
 concatenation. Now it’s possible to do it in a more natural way using Text Blocks.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 String textBlock =
                "&lt;html&gt;\n" +
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
                "    &lt;/body&gt;\n" +
                "&lt;/html&gt;";
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String textBlock = """
         &lt;html&gt;
@@ -20,7 +21,7 @@ <h2>Compliant Solution</h2>
             &lt;/body&gt;
         &lt;/html&gt;""";
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/378">JEP 378: Text Blocks</a> </li>
   <li> <a href="https://openjdk.org/projects/amber/guides/text-blocks-guide">Programmer’s Guide To Text Blocks</a>, by Jim Laskey and Stuart Marks
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6201.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6201.html
index 5031fb26c71..421e63ecdd1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6201.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6201.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 16, the feature "Pattern matching for instanceof" is finalized and can&nbsp;be used in production. Previously developers needed to do 3
 operations in order to do this: check the variable type, cast it and assign the casted value to the new variable. This approach is quite verbose and
 can be replaced with pattern matching for&nbsp;<code>instanceof</code>, doing these 3 actions (check, cast and assign) in one expression.</p>
 <p>This rule raises an issue when an <code>instanceof</code> check followed by a cast and an assignment could be replaced by pattern matching.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int f(Object o) {
   if (o instanceof String) {&nbsp; // Noncompliant
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
   return 0;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int f(Object o) {
 &nbsp; if (o instanceof String string) {&nbsp; // Compliant
@@ -21,7 +22,7 @@ <h2>Compliant Solution</h2>
 &nbsp; return 0;
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/394">JEP 394: Pattern Matching for instanceof</a> &nbsp; </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6202.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6202.html
index 7a7eb2bb5b3..fcc7739024e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6202.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6202.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The <code>instanceof</code> construction is a preferred way to check whether a variable can be cast to some type statically because a compile-time
 error will occur in case of incompatible types. The method <a
 href="https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#isInstance-java.lang.Object-">isInstance()</a> from <code>java.lang.Class</code>
@@ -5,7 +6,7 @@
 resulting in dead code. The <code>isInstance()</code> method should only be used in dynamic cases when the <code>instanceof</code> operator can’t be
 used.</p>
 <p>This rule raises an issue when <code>isInstance()</code> is used and could be replaced with an <code>instanceof</code> check.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int f(Object o) {
 &nbsp; if (String.class.isInstance(o)) {&nbsp; // Noncompliant
@@ -21,7 +22,7 @@ <h2>Noncompliant Code Example</h2>
 &nbsp; return 0;
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int f(Object o) {
 &nbsp; if (o instanceof String) {&nbsp; // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6203.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6203.html
index 7106f0f2b6f..358982fc77c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6203.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6203.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 15 Text Blocks are official and can be used just like an ordinary String. However, when they are used to represent a big chunk of text,
 they should not be used directly in complex expressions, as it decreases the readability. In this case, it is better to extract the text block into a
 variable or a field.</p>
 <p>This rule reports an issue when a text block longer than a number of lines given as a parameter is directly used within a lambda expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 listOfString.stream()
   .map(str -&gt; !"""
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
     &lt;/project&gt;
     """.equals(str));
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 String myTextBlock = """
     &lt;project&gt;
@@ -40,7 +41,7 @@ <h2>Compliant Solution</h2>
 listOfString.stream()
   .map(str -&gt; !myTextBlock.equals(str));
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/378">JEP 378: Text Blocks</a> </li>
   <li> <a href="https://openjdk.org/projects/amber/guides/text-blocks-guide">Programmer’s Guide To Text Blocks</a>, by Jim Laskey and Stuart Marks
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6204.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6204.html
index f6410f95afc..6286683ba08 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6204.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6204.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 8 <code>Streams</code> were introduced to support chaining of operations over collections in a functional style. The most common way to
 save a result of such chains is to save them to some collection (usually <code>List</code>). To do so there is a terminal method <code>collect</code>
 that can be used with a library of <code>Collectors</code>. The key problem is that <code>.collect(Collectors.toList())</code> actually returns a
@@ -5,7 +6,7 @@
 unmodifiable list: <code>toUnmodifiableList()</code>. This does the trick but results in verbose code. Since Java 16 there is now a better variant to
 produce an unmodifiable list directly from a stream: <code>Stream.toList()</code>.</p>
 <p>This rule raises an issue when "collect" is used to create a list from a stream.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 List&lt;String&gt; list1 = Stream.of("A", "B", "C")
                            .collect(Collectors.toList()); // Noncompliant
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 List&lt;String&gt; list2 = Stream.of("A", "B", "C")
                            .collect(Collectors.toUnmodifiableList()); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 List&lt;String&gt; list1 = Stream.of("A", "B", "C").toList(); // Compliant
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6205.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6205.html
index 4cb3b39ea5e..bde231d722a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6205.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6205.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>In Switch Expressions, an arrow label consisting of a block with a single <code>yield</code> can be simplified to directly return the value,
 resulting in cleaner code.</p>
 <p>Similarly, for Switch Statements and arrow labels, a <code>break</code> in a block is always redundant and should not be used. Furthermore, if the
 resulting block contains only one statement, the curly braces of that block can also be omitted.</p>
 <p>This rule reports an issue when a case of a Switch Expression contains a block with a single <code>yield</code> or when a Switch Statement contains
 a block with a <code>break</code>.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 int i = switch (mode) {
   case "a" -&gt; {        // Noncompliant: Remove the redundant block and yield.
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 int i = switch (mode) {
   case "a" -&gt; 1;
@@ -42,7 +43,7 @@ <h2>Compliant Solution</h2>
  }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/361">JEP 361: Switch Expressions</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6206.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6206.html
index 550013c43bd..bdeb9b36724 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6206.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6206.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 16 <code>records</code> are finalized and can be safely used in production code. <code>Records</code> represent immutable read-only data
 structure and should be used instead of creating immutable classes. Immutability of records is guaranteed by the Java language itself, while
 implementing immutable classes on your own might lead to some bugs.</p>
@@ -8,7 +9,7 @@
   <li> has only one constructor with a parameter for all fields </li>
   <li> has getters for all fields </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 final class Person { // Noncompliant
   private final String name;
@@ -33,11 +34,11 @@ <h2>Noncompliant Code Example</h2>
   public String toString() {...}
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Person(String name, int age) { }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6207.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6207.html
index 7aaf5db006c..8a5c2fa1ddc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6207.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6207.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 16 records represent a brief notation for immutable data structures. Records have autogenerated implementations for constructors with all
 parameters, <code>getters</code>, <code>equals</code>, <code>hashcode</code> and <code>toString</code>. Although these methods can still be overridden
 inside records, there is no use to do so if no special logic is required.</p>
 <p>This rule reports an issue on empty compact constructors, trivial canonical constructors and simple getter methods with no additional logic.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Person(String name, int age) {
   Person(String name, int age) { // Noncompliant, already autogenerated
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Person(String name, int age) { } // Compliant
 
@@ -41,7 +42,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6208.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6208.html
index 6f2c2cd5c07..cc6e9e759dc 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6208.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6208.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 14 there is a new way to write cases in Switch Statement and Expression when the same action should be performed for different cases.
 Instead of declaring multiples branches with the same action, you can combine all of them in a single case group, separated with commas. It will
 result in a more concise code and improved readability.</p>
 <p>This rule reports an issue when multiple cases in a Switch can be grouped into a single comma-separated case.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // Switch Expression
 int i = switch (mode) {
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
     doSomethingElse();
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // Switch Expression
 int i = switch (mode) {
@@ -48,7 +49,7 @@ <h2>Compliant Solution</h2>
   default -&gt; doSomethingElse();
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/361">JEP 361: Switch Expressions</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6209.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6209.html
index 0110ab8321a..eda74f2d4dd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6209.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6209.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In Records, serialization is not done the same way as for ordinary serializable or externalizable classes. The serialized representation of a
 record object will be a sequence of values (record components). During the deserialization of records, the stream of components is read and components
 are constructed. Then the record object is recreated by invoking the record’s canonical constructor with the component values serving as arguments (or
@@ -8,7 +9,7 @@
 <p>However, there is a way to substitute serialized/deserialized objects in <code>writeReplace</code> and <code>readResolve</code>.</p>
 <p>This rule raises an issue when any of <code>writeObject</code>, <code>readObject</code>, <code>readObjectNoData</code>, <code>writeExternal</code>,
 <code>readExternal</code> or <code>serialPersistentFields</code> are present as members in a Record class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Record() implements Serializable {
   @Serial
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
   }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Record() implements Serializable {}
 
@@ -42,7 +43,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
   <li> <a href="https://docs.oracle.com/en/java/javase/16/docs/specs/serialization/serial-arch.html#serialization-of-records">serialization of
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6211.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6211.html
index 8710910b07d..47e488df43a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6211.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6211.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Before records appeared in Java 16, there was a common way to represent getters for private fields of a class:&nbsp; a method named "get" with a
 capitalized field name. For example, for a&nbsp;<code>String</code> field named "myField" the signature of the getter method will be: <code>public
 String getMyField()</code></p>
@@ -8,7 +9,7 @@
 different from the default one.</p>
 <p>This rule raises an issue when a record contains a getter named "get" with a capitalized field name that is not behaving the same as the default
 one.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Person(String name, int age) {
     public String getName() { // Noncompliant
@@ -16,7 +17,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Person(String name, int age) {
     @Override
@@ -45,10 +46,10 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>If the implementations of <code>getMyField()</code> and <code>myField()</code> methods are equivalent, the issue should not be raised as this was
 probably done to support compatibility with the previous convention.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6212.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6212.html
index a37c2469861..7d92b105274 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6212.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6212.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>In Java 10 <a href="https://openjdk.java.net/jeps/286">Local-Variable Type Inference</a> was introduced. It allows you to omit the expected type of
 a variable by declaring it with the <code>var</code> keyword.</p>
 <p>While it is not always possible or cleaner to use this new way of declaring a variable, when the type on the left is the same as the one on the
@@ -5,7 +6,7 @@
 <p>This rule reports an issue when the expected type of the variable is the same as the returned type of assigned expression and the type can be
 easily inferred by the reader, either when the type is already mentioned in the name or the initializer, or when the expression is
 self-explanatory.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 MyClass myClass = new MyClass();
 
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
 
 MyClass myClass = get(); // Type is already mentioned in the name
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 var myClass = new MyClass();
 
@@ -25,7 +26,7 @@ <h2>Compliant Solution</h2>
 
 var myClass = get();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://openjdk.java.net/jeps/286">JEP 286: Local-Variable Type Inference</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6213.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6213.html
index 0b4c19588e1..9cd657b0fdb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6213.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6213.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Even if it is technically possible, <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-3.html#jls-3.8">Restricted Identifiers</a>
 should not be used as identifiers. This is only possible for compatibility reasons, using it in Java code is confusing and should be avoided.</p>
 <p>Note that this applies to any version of Java, including the one where these identifiers are not yet restricted, to avoid future confusion.</p>
@@ -8,7 +9,7 @@
   <li> record </li>
 </ul>
 <p>are used as identifiers.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 var var = "var"; // Noncompliant: compiles but this code is confusing
 var = "what is this?";
@@ -22,7 +23,7 @@ <h2>Noncompliant Code Example</h2>
 
 String record = "record"; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 var myVariable = "var";
 
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
 
 String myRecord = "record";
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-3.html#jls-3.8">JLS16, 3.8: Identifiers</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6216.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6216.html
index 30d614d02c5..ae724d6cc4b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6216.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6216.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>In general, altering or bypassing the accessibility of classes, methods, or fields violates the encapsulation principle and could lead to runtime
 errors. For records the case is even trickier: you cannot change the visibility of records’s fields and trying to update the existing value will lead
 to <code>IllegalAccessException</code> at runtime.</p>
 <p>This rule raises an issue when reflection is used to change the visibility of a record’s field, and when it is used to directly update a record’s
 field value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Person(String name, int age) {}
 
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
 field.setAccessible(true); // secondary
 field.set(person, "B"); // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6217.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6217.html
index 52281f76690..64393b2daac 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6217.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6217.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p><code>sealed</code> classes were introduced in Java 17. This feature is very useful if there is a need to define a strict hierarchy and restrict
 the possibility of extending classes. In order to mention all the allowed subclasses, there is a keyword <code>permits</code>, which should be
 followed by subclasses' names.</p>
@@ -5,7 +6,7 @@
 case when all subclasses are declared in the same file there is no need to mention the explicitly and <code>permits</code> part of a declaration can
 be omitted.</p>
 <p>This rule reports an issue if all subclasses of a <code>sealed</code> class are declared in the same file as their superclass.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 sealed class A permits B, C, D, E {} // Noncompliant
 final class B extends A {}
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 final class D extends A {}
 final class E extends A {}
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 sealed class A {} // Compliant
 final class B extends A {}
@@ -21,7 +22,7 @@ <h2>Compliant Solution</h2>
 final class D extends A {}
 final class E extends A {}
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se17/html/jls-8.html#jls-8.1.1.2">Sealed Classes specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6218.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6218.html
index 704bcb3c92a..3d6e768e319 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6218.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6218.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>In records, the default behavior of the <code>equals()</code> method is to check the equality by field values. This works well for primitive fields
 or fields, whose type overrides <code>equals()</code>, but this behavior doesn’t work as expected for array fields.</p>
 <p>By default, array fields are compared by their reference, and overriding <code>equals()</code> is highly appreciated to achieve the deep equality
 check. The same strategy applies to <code>hashcode()</code> and <code>toString()</code> methods.</p>
 <p>This rule reports an issue if a record class has an array field and is not overriding <code>equals()</code>, <code>hashcode()</code> or
 <code>toString()</code> methods.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Person(String[] names, int age) {} // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Person(String[] names, int age) {
     @Override
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6219.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6219.html
index 2d1912c977f..9f5dff07f76 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6219.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6219.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>In Records serialization is not done the same way as for ordinary serializable or externalizable classes. Records serialization does not rely on
 the <code>serialVersionUID</code> field, because the requirement to have this field equal is waived for record classes. By default, all records will
 have this field equal to <code>0L</code> and there is no need to specify this field with <code>0L</code> value and it is possible to specify it with
 some custom value to support serialization/deserialization involving ordinary classes.</p>
 <p>This rule raises an issue when there is a <code>private static final long serialVersionUID</code> field which is set to <code>0L</code> in a Record
 class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 record Person(String name, int age) implements Serializable {
 @Serial
   private static final long serialVersionUID = 0L; // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 record Person(String name, int age) implements Serializable {} // Compliant
 
@@ -20,7 +21,7 @@ <h2>Compliant Solution</h2>
   private static final long serialVersionUID = 42L; // Compliant
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10">Records specification</a> </li>
   <li> <a href="https://docs.oracle.com/en/java/javase/16/docs/specs/serialization/serial-arch.html#serialization-of-records">Serialization of
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6241.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6241.html
index 8d1447d906a..1af6f2d0721 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6241.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6241.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>If the region is not specified when creating a new AwsClient with an <a
 href="https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/awscore/client/builder/AwsClientBuilder.html">AwsClientBuilder</a>, the AWS SDK
 will execute some logic to identify the endpoint automatically.</p>
@@ -6,20 +7,20 @@
 AWS_REGION environment variable.</p>
 <p>This will make the code more explicit and spare initialization time.</p>
 <p>This rule reports an issue when the region is not set when creating an AwsClient.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 S3Client.builder()
     .credentialsProvider(EnvironmentVariableCredentialsProvider.create())
     .build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 S3Client.builder()
     .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))
     .credentialsProvider(EnvironmentVariableCredentialsProvider.create())
     .build();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://aws.amazon.com/fr/blogs/developer/tuning-the-aws-java-sdk-2-x-to-reduce-startup-time/">Tuning the AWS Java SDK 2.x to reduce
   startup time</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6242.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6242.html
index e2eb08c7ddd..ae62cc9ce6b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6242.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6242.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>If the credentials provider is not specified when creating a new AwsClient with an <a
 href="https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/awscore/client/builder/AwsClientBuilder.html">AwsClientBuilder</a>, the AWS SDK
 will execute some logic to identify it automatically.</p>
@@ -6,20 +7,20 @@
 provided environment variable.</p>
 <p>This will make the code more explicit and spare initialization time.</p>
 <p>This rule reports an issue when the credentials provider is not set when creating an AwsClient.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 S3Client.builder()
     .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable())))
     .build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 S3Client.builder()
     .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))
     .credentialsProvider(EnvironmentVariableCredentialsProvider.create())
     .build();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://aws.amazon.com/fr/blogs/developer/tuning-the-aws-java-sdk-2-x-to-reduce-startup-time/">Tuning the AWS Java SDK 2.x to reduce
   startup time</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6243.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6243.html
index 26b883577a1..bd2fa81692b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6243.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6243.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Resources that can be reused across multiple invocations of the Lambda function should be initialized at construction time. For example in the
 constructor of the class, or in field initializers. This way, when the same container is reused for multiple function invocations, the existing
 instance can be reused, along with all resources stored in its fields. It is a good practice to reuse SDK clients and database connections by
 initializing them at class construction time, to avoid recreating them on every lambda invocation. Failing to do so can lead to performance
 degradation, and when not closed properly, even out of memory errors.</p>
 <p>This rule reports an issue when the SDK client or the database connection is initialized locally inside a Lambda function.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public class App implements RequestHandler&lt;Object, Object&gt; {
     @Override
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public class App implements RequestHandler&lt;Object, Object&gt; {
     private final S3Client s3Client;
@@ -31,7 +32,7 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://aws.amazon.com/fr/blogs/developer/tuning-the-aws-java-sdk-2-x-to-reduce-startup-time/">Tuning the AWS Java SDK 2.x to reduce
   startup time</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6244.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6244.html
index 8b997d7d929..f885ca0db5f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6244.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6244.html
@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>Some API, like the AWS SDK, heavily rely on the builder pattern to create different data structures. Despite all the benefits, this pattern can
 become really verbose, especially when dealing with nested structures. In order to reach a more concise code, "Consumer Builders", also called
 "Consumer Interface" are often introduced.</p>
 <p>The idea is to overload the methods taking others structures in a Builder with a Consumer of Builder instead. This enables to use a lambda instead
 of nesting another Builder, resulting in more concise and readable code.</p>
 <p>This rule reports an issue when the Consumer Builder methods could be used instead of the classical ones.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 SendEmailRequest.builder()
   .destination(Destination.builder()
@@ -13,13 +14,13 @@ <h2>Noncompliant Code Example</h2>
     .build())
 .build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 SendEmailRequest.builder()
   .destination(d -&gt; d.toAddresses("to-email@domain.com").bccAddresses("bcc-email@domain.com"))
   .build();
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://aws.amazon.com/fr/blogs/developer/consumer-builders-in-the-aws-sdk-for-java-v2/">Consumer Builders in the AWS SDK for Java
   v2</a> </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6246.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6246.html
index d48132a4946..e76b5575b88 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6246.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6246.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>Invoking other Lambdas synchronously from a Lambda is a scalability anti-pattern. Lambdas have a maximum execution time before they timeout (15
 minutes as of May 2021). Having to wait for another Lambda to finish its execution could lead to a timeout.</p>
 <p>A better solution is to generate&nbsp;events that can be consumed asynchronously by other Lambdas.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With AWS SDKv1</p>
 <pre>
 InvokeRequest invokeRequest = new InvokeRequest()
@@ -13,7 +14,7 @@ <h2>Noncompliant Code Example</h2>
 
 awsLambda.invoke(invokeRequest); // Noncompliant
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html">Best practices for working with AWS Lambda functions</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6262.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6262.html
index 6181308d747..299010490b3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6262.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6262.html
@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p>When explicitly setting the region on an AWS Client, you should always prefer providing the value from the Enum <a
 href="https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html?com/amazonaws/regions/Regions.html">Regions</a> instead of a hardcoded String.
 This will allow you to transparently support any change in the API and avoid mistakes.</p>
 <p>This rule reports an issue when a hardcoded string is used instead of an available enum value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 AmazonS3ClientBuilder.standard().withRegion("eu_west_1").build();
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 AmazonS3ClientBuilder.standard().withRegion(Regions.EU_WEST_1).build();
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6288.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6288.html
index 2fa4eff02f8..c661c86a8c3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6288.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6288.html
@@ -12,7 +12,7 @@ <h2>Recommended Secure Coding Practices</h2>
 <p>It’s recommended to enable user authentication (by setting <code>setUserAuthenticationRequired</code> to <code>true</code> during key generation)
 to use keys for a limited duration of time (by setting appropriate values to <code>setUserAuthenticationValidityDurationSeconds</code>), after which
 the user must re-authenticate.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>Any user can use the key:</p>
 <pre>
 KeyGenerator keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6293.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6293.html
index 30e1ab52766..8e49a94323b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6293.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6293.html
@@ -13,7 +13,7 @@ <h2>Ask Yourself Whether</h2>
 <p>There is a risk if you answered yes to this question.</p>
 <h2>Recommended Secure Coding Practices</h2>
 <p>It’s recommended to tie the biometric authentication to a cryptographic operation by using a <code>CryptoObject</code> during authentication.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>A <code>CryptoObject</code> is not used during authentication:</p>
 <pre>
 // ...
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6301.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6301.html
index ee86647b431..b4b6d2799ae 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6301.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6301.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Storing data locally is a common task for mobile applications. There are many convenient solutions that allow storing data persistently, for
 example SQLiteDatabase and Realm. These systems can be initialized with a secret key in order to store the data encrypted.</p>
 <p>The encryption key is meant to stay secret and should not be hard-coded in the application as it would mean that:</p>
@@ -9,7 +10,7 @@
 <p>There are different approaches how the key can be provided to encrypt and decrypt the database. One of the most convinient way to is to rely on
 <code>EncryptedSharedPreferences</code> to store encryption keys. It can also be provided dynamically by the user of the application or fetched from a
 remote server.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p><a href="https://www.zetetic.net/sqlcipher/sqlcipher-for-android/">SQLCipher</a></p>
 <pre>
 String key = "gb09ym9ydoolp3w886d0tciczj6ve9kszqd65u7d126040gwy86xqimjpuuc788g";
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
     .build();
 Realm realm = Realm.getInstance(config);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p><a href="https://www.zetetic.net/sqlcipher/sqlcipher-for-android/">SQLCipher</a></p>
 <pre>
 SQLiteDatabase db = SQLiteDatabase.openOrCreateDatabase("test.db", getKey(), null);
@@ -35,7 +36,7 @@ <h2>Compliant Solution</h2>
     .build();
 Realm realm = Realm.getInstance(config);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6326.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6326.html
index 170fb68c3f2..9013e572854 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6326.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6326.html
@@ -1,14 +1,15 @@
+<h2>Why is this an issue?</h2>
 <p>Multiple spaces in a regular expression can make it hard to tell how many spaces should be matched. It’s more readable to use only one space and
 then indicate with a quantifier how many spaces are expected.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 Pattern.compile("hello   world");
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 Pattern.compile("hello {3}world");
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>In <a href="https://www.regular-expressions.info/freespacing.html">free-spacing mode</a> (<code>Pattern.COMMENTS</code> flag, or with embedded flag
 expression <code>(?x)</code>), whitespaces are ignored. In this case no issue should be triggered, because the whitespaces may be intended to improve
 readability.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6331.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6331.html
index 139b84bb272..ea0ec987cf7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6331.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6331.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>There are several reasons to use a group in a regular expression:</p>
 <ul>
   <li> to change the precedence (e.g. <code>do(g|or)</code> will match 'dog' and 'door') </li>
@@ -6,11 +7,11 @@
 </ul>
 <p>In any case, having an empty group is most probably a mistake. Either it is a leftover after refactoring and should be removed, or the actual
 parentheses were intended and were not escaped.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "foo()"  // Noncompliant, will match only 'foo'
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "foo\\(\\)"  // Matches 'foo()'
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6353.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6353.html
index 35ced2405de..20a56359a8e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6353.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6353.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>With regular expressions syntax, it’s possible to express the same thing in many ways. For example, to match a two-digit number, one could write
 <code>[0-9]{2,2}</code> or <code>\d{2}</code>. Latter is not only shorter in terms of expression length, but also easier to read and thus to maintain.
 This rule recommends to replace some bulky quantifiers and character classes with more concise equivalents:</p>
@@ -9,7 +10,7 @@
   <li> <code>x?</code> for <code>x{0,1}</code>, <code>x*</code> for <code>x{0,}</code>, <code>x+</code> for <code>x{1,}</code>, <code>x{N}</code> for
   <code>x{N,N}</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "[0-9]" // Noncompliant - same as "\\d"
 "[^0-9]" // Noncompliant - same as "\\D"
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
 "[\\w\\W]" // Noncompliant - same as "."
 "a{0,}" // Noncompliant - same as "a*"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "\\d"
 "\\D"
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6355.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6355.html
index 08c6685e3e6..93a06638b29 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6355.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6355.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Since Java 9, <code>@Deprecated</code> has two additional arguments to the annotation:</p>
 <ul>
   <li> <code>since</code> allows you to describe when the deprecation took place </li>
@@ -5,18 +6,19 @@
 </ul>
 <p>In order to ease the maintainers work, it is recommended to always add one or both of these arguments.</p>
 <p>This rule reports an issue when <code>@Deprecated</code> is used without any argument.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 @Deprecated
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @Deprecated(since="4.2", forRemoval=true)
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The members and methods of a deprecated class or interface are ignored by this rule. The classes and interfaces themselves are still subject to
 it.</p>
-<h3>See Also</h3>
+<h2>Resources</h2>
+<h3>Related rules</h3>
 <ul>
   <li> {rule:java:S1123} </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6373.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6373.html
index 7a176301552..1c622a18587 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6373.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6373.html
@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>XML standard allows the inclusion of xml files with the <a href="https://www.w3.org/TR/xinclude-11/">xinclude</a> element.</p>
 <p>XML processors will replace an xinclude element with the content of the file located at the URI defined in the href attribute, potentially from an
 external storage such as file system or network, which may lead, if no restrictions are put in place, to arbitrary file disclosures or <a
 href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery">server-side request forgery (SSRF)</a> vulnerabilities.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/stream/XMLInputFactory.html">XMLInput</a>, <a
@@ -23,7 +24,7 @@ <h2>Noncompliant Code Example</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature("http://apache.org/xml/features/xinclude", true); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Xinclude is disabled by default and can be explicitely disabled like below.</p>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a>, <a
@@ -45,7 +46,7 @@ <h2>Compliant Solution</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature("http://apache.org/xml/features/xinclude", false);
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule does not raise issues when Xinclude is enabled with a custom <code>EntityResolver</code>:</p>
 <p>For DocumentBuilderFactory:</p>
 <pre>
@@ -73,7 +74,7 @@ <h2>Exceptions</h2>
 factory.setProperty("http://apache.org/xml/features/xinclude", true);
 factory.setXMLResolver(new MySafeEntityResolver());
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a
   href="https://docs.oracle.com/en/java/javase/13/security/java-api-xml-processing-jaxp-security-guide.html#GUID-8CD65EF5-D113-4D5C-A564-B875C8625FAC">Oracle Java Documentation</a> - XML External Entity Injection Attack </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6374.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6374.html
index c3e1491acf1..8059ca2b94c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6374.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6374.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>By default XML processors attempt to load all XML schemas and DTD (their locations are defined with <code>xsi:schemaLocation</code> attributes and
 <code>DOCTYPE</code> declarations), potentially from an external storage such as file system or network, which may lead, if no restrictions are put in
 place, to <a href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery">server-side request forgery (SSRF)</a> vulnerabilities.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a> and <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/validation/SchemaFactory.html">Schema</a> JAPX factories:</p>
@@ -27,7 +28,7 @@ <h2>Noncompliant Code Example</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", true); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a> and <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/validation/SchemaFactory.html">Schema</a> JAPX factories:</p>
@@ -51,7 +52,7 @@ <h2>Compliant Solution</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rules does not raise an issue when an <code>EntityResolver</code> is set.</p>
 <pre>
 DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
@@ -63,7 +64,7 @@ <h2>Exceptions</h2>
 builder.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", true);
 builder.setEntityResolver(new EntityResolver());
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a
   href="https://docs.oracle.com/en/java/javase/13/security/java-api-xml-processing-jaxp-security-guide.html#GUID-8CD65EF5-D113-4D5C-A564-B875C8625FAC">Oracle Java Documentation</a> - XML External Entity Injection Attack </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6376.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6376.html
index bf903609b39..4f6d4acc6f0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6376.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6376.html
@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p>An XML bomb / <a href="https://en.wikipedia.org/wiki/Billion_laughs_attack">billion laughs</a> attack is a malicious XML document containing the
 same large entity repeated over and over again. If no restrictions is in place, such a limit on the number of entity expansions, the XML processor can
 consume a lot memory and time during the parsing of such documents leading to Denial of Service.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a> and <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/validation/SchemaFactory.html">Schema</a> and <a
@@ -29,7 +30,7 @@ <h2>Noncompliant Code Example</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>For <a href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/DocumentBuilderFactory.html">DocumentBuilder</a>, <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/parsers/SAXParserFactory.html">SAXParser</a> and <a
 href="https://docs.oracle.com/javase/9/docs/api/javax/xml/validation/SchemaFactory.html">Schema</a> and <a
@@ -57,7 +58,7 @@ <h2>Compliant Solution</h2>
 SAXBuilder builder = new SAXBuilder();
 builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a
   href="https://docs.oracle.com/en/java/javase/13/security/java-api-xml-processing-jaxp-security-guide.html#GUID-8CD65EF5-D113-4D5C-A564-B875C8625FAC">Oracle Java Documentation</a> - XML External Entity Injection Attack </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6377.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6377.html
index 6260737915b..31dd6fb2f13 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6377.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6377.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>XML signature validations work by parsing third-party data that cannot be trusted until it is actually validated.</p>
 <p>As with any other parsing process, unrestricted validation of third-party XML signatures can lead to security vulnerabilities. In this case,
 threats range from denial of service to confidentiality breaches.</p>
@@ -15,7 +16,7 @@
   <li> Does not allow a <code>RetrievalMethod</code> element to reference another <code>RetrievalMethod</code> element </li>
   <li> Forbids RSA or DSA keys less than 1024 bits </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 NodeList signatureElement = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
 
@@ -25,7 +26,7 @@ <h2>Noncompliant Code Example</h2>
 
 boolean signatureValidity = signature.validate(valContext);
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>In order to benefit from this secure validation mode, set the DOMValidateContext’s <code>org.jcp.xml.dsig.secureValidation</code> property to
 <code>TRUE</code>.</p>
 <pre>
@@ -38,7 +39,7 @@ <h2>Compliant Solution</h2>
 
 boolean signatureValidity = signature.validate(valContext);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a
   href="https://docs.oracle.com/en/java/javase/14/security/java-xml-digital-signature-api-overview-and-tutorial.html#GUID-DB46A001-6DBD-4571-BDBC-1BBC394BF61E">Oracle Java Documentation</a> - XML Digital Signature API Overview and Tutorial </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6395.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6395.html
index 39d0a98a67c..487e9907f6a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6395.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6395.html
@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>Sub-patterns can be wrapped by parentheses to build a group. This enables to restrict alternations, back reference the group or apply quantifier to
 the sub-pattern.</p>
 <p>If this group should not be part of the match result or if no reference to this group is required, a non-capturing group can be created by adding
 <code>?:</code> behind the opening parenthesis.</p>
 <p>However, if this non-capturing group does not have a quantifier, or does not wrap an alternation, then imaging this group is redundant.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "(?:number)\\d{2}"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "number\\d{2}"      	// it is anyway required
 "(?:number)?\\d{2}"  	// it is in fact optional
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule does not report an issue if the non-capturing group is an alternation.</p>
 <pre>
 "(?:number|string)"
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6396.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6396.html
index dd0d80875c6..1751620fffb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6396.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6396.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Curly brace quantifiers in regular expressions can be used to have a more fine-grained control over how many times the character or the
 sub-expression preceeding them should occur. They can be used to match an expression exactly n times with <code>{n}</code>, between n and m times with
 <code>{n,m}</code>, or at least n times with <code>{n,}</code>. In some cases, using such a quantifier is superfluous for the semantic of the regular
@@ -7,14 +8,14 @@
   <li> <code>{0,0}</code> or <code>{0}</code>: they match the expression zero times. The same behavior can be achieved by removing the expression.
   </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "ab{1,1}c"
 "ab{1}c"
 "ab{0,0}c"
 "ab{0}c"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "abc"
 "ac"
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6397.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6397.html
index 3f92cdd5e31..723f8e1339f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6397.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6397.html
@@ -1,19 +1,20 @@
+<h2>Why is this an issue?</h2>
 <p>Character classes in regular expressions are a convenient way to match one of several possible characters by listing the allowed characters or
 ranges of characters. If a character class contains only one character, the effect is the same as just writing the character without a character
 class.</p>
 <p>Thus, having only one character in a character class is usually a simple oversight that remained after removing other characters of the class.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 "a[b]c"
 "[\\^]"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 "abc"
 "\\^"
 "a[*]c" // Compliant, see Exceptions
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>This rule does not raise when the character inside the class is a metacharacter. This notation is sometimes used to avoid escaping (e.g.,
 <code>[.]{3}</code> to match three dots).</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6411.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6411.html
index bcd58a4ccd6..bdeb0399c86 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6411.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6411.html
@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Maps use hashes of the keys to select a bucket to store data in. Objects that hash to the same value will be added to the same bucket.</p>
 <p>When the hashing function has a poor distribution, buckets can grow to very large sizes. This may negatively affect lookup performance, as, by
 default, matching a key within a bucket has linear complexity.</p>
 <p>In addition, as the default hashCode function can be selected at runtime, performance expectations cannot be maintained.</p>
 <p>Implementing Comparable mitigates the performance issue for objects that hash to the same value.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 class MyKeyType {
     // ...
@@ -17,7 +18,7 @@ <h2>Noncompliant Code Example</h2>
     }
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 class MyKeyType implements Comparable&lt;MyKeyType&gt; {
     // ...
@@ -36,7 +37,7 @@ <h2>Compliant Solution</h2>
     }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://www.kb.cert.org/vuls/id/903934">https://www.kb.cert.org/vuls/id/903934</a> </li>
   <li> <a
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6432.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6432.html
index 5efe3a3697a..9fa12faa9aa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6432.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6432.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When encrypting data with Counter (CTR) derived block cipher modes of operation, it is essential not to reuse the same initialization vector (IV)
 with a given key, such IV is called a "nonce" (number used only once). Galois/Counter (GCM) and Counter with Cipher Block Chaining-Message
 Authentication Code (CCM) are both CTR-based modes of operation.</p>
@@ -8,7 +9,7 @@
 The 'Deterministic' construction involves a counter, which increments per encryption process. The 'RBG' construction, as the name suggests, generates
 the nonce using a random bit generator. Collision probabilities (nonce-key pair reuse) using the 'RBG-based' approach require a shorter key rotation
 period, 2^32 maximum invocations per key.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void encrypt(byte[] key, byte[] ptxt) {
     byte[] bytesIV = "7cVgr5cbdCZV".getBytes("UTF-8"); // The initialization vector is a static value
@@ -20,7 +21,7 @@ <h2>Noncompliant Code Example</h2>
     cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv);  // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void encrypt(byte[] key, byte[] ptxt) {
     SecureRandom random = new SecureRandom();
@@ -34,7 +35,7 @@ <h2>Compliant Solution</h2>
     cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6437.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6437.html
index eb654d36cb8..1d322202931 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6437.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6437.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>A hard-coded secret has been found in your code. You should quickly list where this secret is used, revoke it, and then change it in every system
 that uses it.</p>
 <p>Passwords, secrets, and any type of credentials should only be used to authenticate a single entity (a person or a system).</p>
@@ -19,7 +20,7 @@
       <li> For example, in a file whose permissions are restricted and protected with chmod and chown. </li>
     </ul>  </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 import org.h2.security.SHA256;
 
@@ -28,7 +29,7 @@ <h2>Noncompliant Code Example</h2>
 
 SHA256.getHMAC(key, message);  // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Using <a href="https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/secretsmanager">AWS Secrets Manager</a>:</p>
 <pre>
 import software.amazon.awssdk.services.secretsmanager.SecretsManagerClient;
@@ -64,7 +65,7 @@ <h2>Compliant Solution</h2>
   SHA256.getHMAC(key, message);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://aws.amazon.com/fr/secrets-manager/">AWS</a> - Secret Manager </li>
   <li> <a href="https://azure.microsoft.com/fr-fr/services/key-vault/">Azure</a> - Key Vault </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S818.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S818.html
index c178fd48646..c03679449a5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S818.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S818.html
@@ -1,17 +1,18 @@
+<h2>Why is this an issue?</h2>
 <p>Using upper case literal suffixes removes the potential ambiguity between "1" (digit 1) and "l" (letter el) for declaring literals.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 long long1 = 1l; // Noncompliant
 float float1 = 1.0f; // Noncompliant
 double double1 = 1.0d; // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 long long1 = 1L;
 float float1 = 1.0F;
 double double1 = 1.0D;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/cdYxBQ">CERT DCL16-C.</a> - Use "L," not "l," to indicate a long value </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/7DZGBQ">CERT, DCL50-J.</a> - Use visually distinct identifiers </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S864.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S864.html
index b539fd9df60..108fd4d2b0a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S864.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S864.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The rules of operator precedence are complicated and can lead to errors. For this reason, parentheses should be used for clarification in complex
 statements. However, this does not mean that parentheses should be gratuitously added around every operation.</p>
 <p>This rule raises issues when <code>&amp;&amp;</code> and <code>||</code> are used in combination, when assignment and equality or relational
@@ -65,7 +66,7 @@
   </tbody>
 </table>
 <p>This rule also raises an issue when the "true" or "false" expression of a ternary operator is not trivial and not wrapped inside parentheses.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 x = a + b - c;
 x = a + 1 &lt;&lt; b;  // Noncompliant
@@ -75,7 +76,7 @@ <h2>Noncompliant Code Example</h2>
 if ( a &gt; b &amp;&amp; c &lt; d || a == b) {...}  // Noncompliant
 if (a = f(b,c) == 1) { ... } // Noncompliant; == evaluated first
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 x = a + b - c;
 x = (a + 1) &lt;&lt; b;
@@ -85,7 +86,7 @@ <h2>Compliant Solution</h2>
 if ( (a &gt; b &amp;&amp; c &lt; d) || a == b) {...}
 if ( (a = f(b,c)) == 1) { ... }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/YdYxBQ">CERT, EXP00-C.</a> - Use parentheses for precedence of operation </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/ZzZGBQ">CERT, EXP53-J.</a> - Use parentheses for precedence of operation </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S881.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S881.html
index 14a87e23d5a..8a846e81c20 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S881.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S881.html
@@ -1,15 +1,16 @@
+<h2>Why is this an issue?</h2>
 <p>The use of increment and decrement operators in method calls or in combination with other arithmetic operators is not recommended, because:</p>
 <ul>
   <li> It can significantly impair the readability of the code. </li>
   <li> It introduces additional side effects into a statement, with the potential for undefined behavior. </li>
   <li> It is safer to use these operators in isolation from any other arithmetic operators. </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 u8a = ++u8b + u8c--;
 foo = bar++ / 4;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>The following sequence is clearer and therefore safer:</p>
 <pre>
 ++u8b;
@@ -18,7 +19,7 @@ <h2>Compliant Solution</h2>
 foo = bar / 4;
 bar++;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/StYxBQ">CERT, EXP30-C.</a> - Do not depend on the order of evaluation for side effects </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/IXw-BQ">CERT, EXP50-CPP.</a> - Do not depend on the order of evaluation for side effects </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S888.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S888.html
index c8a29ea40b0..5f8dbb24544 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S888.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S888.html
@@ -1,21 +1,22 @@
+<h2>Why is this an issue?</h2>
 <p>Testing <code>for</code> loop termination using an equality operator (<code>==</code> and <code>!=</code>) is dangerous, because it could set up an
 infinite loop. Using a broader relational operator instead casts a wider net, and makes it harder (but not impossible) to accidentally write an
 infinite loop.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 for (int i = 1; i != 10; i += 2)  // Noncompliant. Infinite; i goes from 9 straight to 11.
 {
   //...
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 for (int i = 1; i &lt;= 10; i += 2)  // Compliant
 {
   //...
 }
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>Equality operators are ignored if the loop counter is not modified within the body of the loop and either:</p>
 <ul>
   <li> starts below the ending value and is incremented by 1 on each iteration. </li>
@@ -31,7 +32,7 @@ <h2>Exceptions</h2>
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/835">MITRE, CWE-835</a> - Loop with Unreachable Exit Condition ('Infinite Loop') </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/x9YxBQ">CERT, MSC21-C.</a> - Use robust loop termination conditions </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S899.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S899.html
index 68a9b759963..d15b885d5ce 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S899.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S899.html
@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the return value of a function call contains the operation status code, this value should be tested to make sure the operation completed
 successfully.</p>
 <p>This rule raises an issue when the return values of the following are ignored:</p>
@@ -11,7 +12,7 @@
   <li> <code>Semaphore.tryAcquire</code> </li>
   <li> <code>BlockingQueue</code>: <code>offer</code>, <code>remove</code> </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 public void doSomething(File file, Lock lock) {
   file.delete();  // Noncompliant
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
   lock.tryLock(); // Noncompliant
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 public void doSomething(File file, Lock lock) {
   if (!lock.tryLock()) {
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
   }
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/xzdGBQ">CERT, EXP00-J.</a> - Do not ignore values returned by methods </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/TTZGBQ">CERT, FIO02-J.</a> - Detect and handle file-related errors </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S923.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S923.html
index 09892e5650b..54ee3d6e7e8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S923.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S923.html
@@ -1,16 +1,17 @@
+<h2>Why is this an issue?</h2>
 <p>As stated per effective java :</p>
 <blockquote>
   <p>Varargs methods are a convenient way to define methods that require a variable number of arguments, but they should not be overused. They can
   produce confusing results if used inappropriately.</p>
 </blockquote>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 void fun ( String... strings )	// Noncompliant
 {
   // ...
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL57-J.+Avoid+ambiguous+overloading+of+variable+arity+methods">CERT, DCL57J</a> -
   Avoid ambiguous overloading of variable arity methods </li>
diff --git a/sonarpedia.json b/sonarpedia.json
index 52a2e12ea3d..fd1d7f229bf 100644
--- a/sonarpedia.json
+++ b/sonarpedia.json
@@ -3,7 +3,7 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2023-05-01T09:54:08.085850Z",
+  "latest-update": "2023-05-30T12:09:42.962798Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false