[gimp-web-devel/pat/bootstrap] content: some fixes to coding style page.

[Jehan <jehanp src gnome org>]

commit daa3379a4c090487dacc8d3727bee7e635f292e3
Author: Jehan <jehan girinstud io>
Date:   Wed Sep 21 13:02:15 2022 +0200

    content: some fixes to coding style page.
    
    - Let's use 80 (not 72 or 80) everywhere as for our max line width, as
      per discussion with patdavid.
    - Add some code fence highlighting code for commit message samples. See:
      https://gohugo.io/content-management/syntax-highlighting/#highlighting-in-code-fences
    - Add some small fixes or improvements here and there.
    - Fix links to editors' config files.

 content/core/coding_style.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
---
diff --git a/content/core/coding_style.md b/content/core/coding_style.md
index c321c38..97ce02a 100644
--- a/content/core/coding_style.md
+++ b/content/core/coding_style.md
@@ -63,7 +63,7 @@ Commit messages should follow the following rules:
   may change or disappear). If the link is to our own bug tracker,
   usually giving the ID is enough.
 - Same [as for code](#line-width), wrap your commit message to
-  reasonable line widths, such as 72 or 80 maximum so that other
+  reasonable line widths, i.e. 80 characters maximum so that other
   contributors don't have to scroll horizontally on narrow
   vizualisation. There may be exceptions, for instance when pasting some
   error messages which may end up confusing when wrapped. But other than
@@ -75,7 +75,7 @@ Commit messages should follow the following rules:
 
 Here is an example of a well formatted fix in the `plug-ins/` section:
 
-```
+```txt {hl_lines=[1]}
 plug-ins: fix file-gih.
 
 We currently cannot call gimp_pdb_run_procedure() for procedures
@@ -88,7 +88,7 @@ See issue #7369.
 
 Here is another as a response to a bug report and a long title:
 
-```
+```txt {hl_lines=[1]}
 Issue #6695: Wrong tab after JPG export because of "Show preview"…
 
 … feature.
@@ -806,8 +806,8 @@ label = gtk_label_new_with_mnemonic (_("_Width:"));
 Note that it is a good idea to not change well-known mnemonics, such as
 `_("_OK")`, `_("_Cancel")` or `_("_Reset")`. Also you should avoid using
 the same mnemonics in 2 widgets on the same interface (even though GTK
-has some way to handle mnemonic duplicate, but it's not really
-practical).
+has some way to handle mnemonic duplicate, but it's not a really good
+implementation accessibility-wise).
 
 Translators may (and often will) change mnemonics. It is therefore up to
 them to take care of not having the same mnemonics on a same interface
@@ -878,8 +878,8 @@ mentions the Polish language has different grammatical agreements for
 2,3,4 and 5-21 or again 22-24 and so on. If we were to use solely
 `_("Indexed color (%d colors)")`, Polish translators would not be able
 to list all these cases (therefore GIMP would have a crappy Polish
-localization), so we have to use `ngettext()` even if it feels useless
-in English.
+localization), so we have to use `ngettext()` even when sometimes, it
+feels useless in English.
 
 Finally when you add translated strings in a file which had none until
 now, for it to be processed by `gettext`, you need to add its path in
@@ -924,9 +924,9 @@ configure your favorite software to follow our coding style.
 You are very welcome to use them (or improve them and contribute the
 change when they are not perfect):
 
-- [.dir-locals.el](.dir-locals.el) for Emacs;
-- [.kateconfig](.kateconfig) for Kate;
-- [c.vim](devel-docs/c.vim) for Vim (check the top comments to see how
+- [.dir-locals.el](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/.dir-locals.el) for Emacs;
+- [.kateconfig](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/.kateconfig) for Kate;
+- [c.vim](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/c.vim) for Vim (check the top 
comments to see how
   to enable it automatically when opening a file in the GIMP tree).
 
 *Note: the Kate and Emacs config file should work out-of-the-box, but
@@ -934,7 +934,7 @@ the Vim one needs to be enabled explicitly because it is too powerful,
 hence is basically [unsafe](https://github.com/vim/vim/issues/1015).*
 
 If you use another software to write code, you are welcome to contribute
-coding style files following our rules.
+coding style files implementing our coding style.
 
 ### Code Formatter