[gimp-web] 2.10.28 text fixes and improvements

[Alexandre Prokoudine <aprokoudine src gnome org>]

commit 2ac4e680a982384e11c98211295bd291eb4d4189
Author: Alexandre Prokoudine <alexandre prokoudine gmail com>
Date:   Wed Sep 15 01:11:39 2021 +0300

    2.10.28 text fixes and improvements

 content/news/2021/2021-09-07/index.md | 88 +++++++++++++++++------------------
 1 file changed, 44 insertions(+), 44 deletions(-)
---
diff --git a/content/news/2021/2021-09-07/index.md b/content/news/2021/2021-09-07/index.md
index b1a2e291..6e62af0e 100644
--- a/content/news/2021/2021-09-07/index.md
+++ b/content/news/2021/2021-09-07/index.md
@@ -5,14 +5,14 @@ Authors: Wilber
 Slug: gimp-2-10-28-released
 Summary: "More bug fixes"
 
-GIMP 2.10.28 is now released. This is a bug-fix release, because most of
-our work is now concentrated on the development version.
+GIMP 2.10.28 is now released. This is a bugfix release, because we are
+giving most of our time and efforts to the development version (2.99.x).
 
 *Note: you may have noticed we skipped GIMP 2.10.26. A build bug has
 been discovered just after tagging the release. GIMP 2.10.28 is the same
 without the bug. We recommend against building and using GIMP 2.10.26.*
 
-# In brief
+# Highlights
 
 - Bug fixes for GIMP on Windows; see [below for
   details](#windows-is-getting-some-love).
@@ -44,15 +44,15 @@ McVittie and Stanislav Grinkov.
 
 # Team news
 
-Jacob Boerema got appointed as new co-maintainer of the manual
+Jacob Boerema got appointed a new co-maintainer of the manual
 repository (`gimp-help`) after porting its scripts to Python 3 and
 improving them.
 
-A new core developer was welcomed to the team: Stanislav Grinkov.
+Stanislav Grinkov is now a new core developer.
 
 Des McGuinness and Lloyd Konneker were given "*reporter*" access which
-allows them to help with triaging on the bugtracker: labelling, closing,
-reopening and moving reports…
+allows them to help triaging on the bugtracker: labelling, closing,
+reopening, and moving reports…
 
 nmat was given "*reporter*" access on the website project (`gimp-web`),
 for his tremendous help with website maintenance.
@@ -61,7 +61,7 @@ for his tremendous help with website maintenance.
 
 Among the 82 languages for which GIMP is available, 14 translations were
 updated: Catalan, Chinese (China), Croatian, Dutch, German, Italian,
-Lithuanian, Polish, Russian, Slovenian, Spanish, Swedish, Ukrainian and
+Lithuanian, Polish, Russian, Slovenian, Spanish, Swedish, Ukrainian, and
 Vietnamese.
 
 The Windows installer now contains Vietnamese and Lithuanian
@@ -75,20 +75,20 @@ Chornoivan.
 
 # Windows is getting some love 💕
 
-More work than ever is happening around Windows lately. This includes
-within GIMP of course, but also in dependency libraries, so that several
-longstanding issues of GIMP in Windows finally got fixed:
+More work than ever is happening around Windows lately, both within GIMP
+and the libraries it depends on. Which is how several long-standing issues
+with GIMP on Windows finally got fixed:
 
 - *Very slow file dialogs*: it used to happen when network devices were
   slow or unavailable, or pluggable devices disconnected, or even
-  because of fake floppy drives configured in the bios. `GLib` was using
+  because of fake floppy drives configured in the BIOS. `GLib` was using
   an inappropriate Windows API to get some information about drives.
   This has been fixed!
   ([#913](https://gitlab.gnome.org/GNOME/gimp/-/issues/913),
   [glib!2020](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2020))
-- *Opening files in specific third-party software was crashing GIMP*: it
-  was determined to be because these software were editing file-handling
-  registry field while `GLib` had a buggy watcher on the registry.
+- *Opening files in specific third-party software was crashing GIMP*:
+  apparently, these applications were editing the file-handling registry
+  field while `GLib` had a buggy watcher on the registry.
   ([#6780](https://gitlab.gnome.org/GNOME/gimp/-/issues/6780),
   [glib!2205](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2205),
   [glib!2210](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2210))
@@ -99,62 +99,62 @@ longstanding issues of GIMP in Windows finally got fixed:
   [gtk!3741](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3741))
 - *TIFF exporting used to lock the TIFF files because of a bug in the
   Windows thumbnailer* (`Explorer.exe` would acquire a lock on the file
-  and never release it). Since Microsoft doesn't seem to fix this
-  longstanding bug, we decided to switch to another way of creating
-  thumbnails by adding a "*reduced-resolution image*" as second page of
-  the TIFF, as proposed in TIFF specification, instead of adding a
+  and never release it). Since Microsoft doesn't seem to want to fix this
+  long-standing bug, we decided to switch to another way of creating
+  thumbnails by adding a "*reduced-resolution image*" as the second page
+  of the TIFF, as proposed in the TIFF specification, instead of adding a
   `subifd` thumbnail. This takes care of the lock issue in a nice way,
-  bypassing `Explorer`'s bug. Of course, it means that other image
-  software which don't read properly tags might open this thumbnail as
-  an additional page, even though it is explicitly annotated as
-  "*reduced-resolution image*". If you experience such disagreement,
-  please report to these other software so that they check the SubFile
-  type of the pages they open (as per [TIFF
+  bypassing _Explorer_'s bug. Of course, it means that programs that can't
+  reads tags properly might try opening thumbnails as additional pages,
+  even though it is explicitly annotated as "*reduced-resolution image*".
+  If you ever run into this very issue, please report it to developers
+  of such programs. What they need to check is the SubFile type of the pages
+  their software opens (as per [TIFF
   specification](https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf)).
   ([#3740](https://gitlab.gnome.org/GNOME/gimp/-/issues/3740))
-- *GIMP used to prevent some software to open, when these software needed
+- *GIMP used to prevent some applications to open, when these programs needed
   to watch some specific directory*, because `GLib` was reading directory
-  with inappropriate access rights. This got actually fixed since GIMP
-  2.10.24.
+  with inappropriate access rights. Actually, this fix has been available
+  since GIMP 2.10.24.
   ([#4594](https://gitlab.gnome.org/GNOME/gimp/-/issues/4594),
   [glib!1976](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1976))
 - Windows software with invisible windows (e.g. gesture shortcuts,
   screen capture and the like) used to interfere with `GTK` software and
   break some mouse interactions. We have had a patch for this, by Ell,
   since 2017, which we used for all GIMP 2.10.x
-  releases. Unfortunately with GTK2 maintenance stopped, our patch
-  stalled in our bugtracker and our binaries only (while it was
-  beneficial to other GTK software, even in GTK3 or over). It has only
+  releases. Unfortunately, with GTK2 maintenance stopped, our patch
+  was only available in the bugtracker and in our binaries, while it was
+  beneficial to other GTK software, even in GTK3 or newer. It has only
   recently been reworked and improved by Luca Bacci so that this problem
   is now officially fixed in GTK3 too!
   ([#1082](https://gitlab.gnome.org/GNOME/gimp/-/issues/1082),
   [gtk!2767](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2767))
 
-We would like to thank in particular Luca Bacci, Jacob Boerema, LRN, Ell
-and all the contributors who stayed on top of Windows issues for these
-progresses to happen, sometimes taking years of patience.
+In particular, we would like to thank Luca Bacci, Jacob Boerema, LRN, Ell,
+and all the contributors who stayed on top of Windows issues for this
+progress to happen, sometimes taking years of patience.
 
 # What about macOS?
 
 On macOS side, the activity is still slow, if not non-existent.
 
-We remind that GIMP is made by you. Yes, you 👆 reading right now.
+We remind that GIMP is made by you. Yes, you 👆 reading this right now.
 Windows developers used to be very few too. As you can see, this is
-clearly changing.
-Therefore if anyone cares about GIMP for macOS, please step forward.
+clearly changing. Therefore, if anyone cares about GIMP for macOS, please
+step forward.
 
 You may have noticed that GIMP 2.10.24's macOS DMG was released months
 late. Even this only happened because Jehan spent days to fix the
 build on the remote build server, bit by bit, without any local access
 to a macOS machine, nor any ways to run and test himself. If the
 packagers are still unavailable, we may try to do the same for this
-release, though we can't promise any deadline.
+release, though we can't set a deadline.
 
 It is obviously not a sustainable release model. It is even worse for
 the development versions: we haven't had a single build for GIMP 2.99.x
 on macOS yet.
 
-So if you want this to change, join us, we don't bite! 🤗
+So if you want this to change, please join us! 🤗
 
 # GEGL and babl
 
@@ -164,15 +164,15 @@ As usual, this release is supplemented with the releases of
 
 In GEGL in particular, the following operations were improved:
 
- - distance-transform: new `edge_handling` parameter, allowing users to
+ - distance-transform: new `edge_handling` parameter allows users to
    choose whether areas outside the input are to be treated as above
    threshold or below threshold (i.e. infinitely white or black
    respectively) for calculating distance. *(by woob)*
  - negative-darkroom: contrast boost and illuminant adjustment
-   parameter, reworked emulsion dye model, UI improvements, more black
-   and white paper presets and some operation speed-up. *(by JonnyRobbie
-   for features and Richard Kreckel for speed-up)*
- - fill-path: 32bit float RGB and CMYK color processing, using ctx as
+   parameter, reworked emulsion dye model, UI improvements, more
+   black-and-white paper presets and some operation speed-up.
+   *(by JonnyRobbie for features and Richard Kreckel for speed-up)*
+ - fill-path: 32-bit float RGB and CMYK color processing, using ctx as
    renderer. *(by Øyvind Kolås)*
 
 The test system got also some nice improvements by John Marshall.