[gimp-web] 2.99.2: text cleanup

[Alexandre Prokoudine <aprokoudine src gnome org>]

commit 7656a3d6fe5331b04efbccb46058c4dde227086f
Author: Alexandre Prokoudine <alexandre prokoudine gmail com>
Date:   Fri Nov 6 04:57:13 2020 +0300

    2.99.2: text cleanup

 .../2020/2020-11_GIMP-2.99.2_Released/index.md     | 391 ++++++++++-----------
 1 file changed, 178 insertions(+), 213 deletions(-)
---
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
index 909c9a51..50022732 100644
--- a/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
+++ b/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
@@ -54,7 +54,7 @@ was not really appropriate for intense use of the software.
 GTK3 brings proper support to GIMP so it will follow your system-set scale
 settings.
 
-*Status*: basically done (except if we forgot any custom widgets).
+*Status*: basically done, some custom widgets could still need an update.
 
 ### Improved input devices support
 
@@ -62,60 +62,57 @@ By "input device", we are mostly talking about drawing tablets or
 pen displays. In GIMP 2, their support had many shortcomings: you had to
 plug the tablet before starting GIMP, enable each new device explicitly
 in the settings and, worse, unplugging the tablet could lead to
-unstability of the software (though this issue got mostly worked around
-on GTK2 by GIMP developers within the 2.8 branch release period).
+instability of the software (though this issue got mostly worked around
+on GTK2 by GIMP developers in the v2.8 release series).
 
-GIMP 3 (hence this first development release) brings hotplug support,
+GIMP 3 (hence this first development release) is bringing hotplug support,
 which basically means: start GIMP, plug your tablet, done. You are ready
-to draw, with pressure, tilt and everything.
-
-We are also trying to improve general support by making our input device
-advanced configuration easier to use.
-
-It is to be noted that some touch support work had been experimented a
-while ago but has not been finished because we realized this was not a
-priority compared to some other features (we are talking about specific
-touch features, like zooming, panning, rotating or other gestures made
-with fingers; *touch* as an input device already works and was already
-working with GIMP 2 versions). Touch gestures are very nice and awesome
-but also sometimes becomes a burden. Actually many professional
-graphists even disable touch-sensitivity to prevent unwanted inputs
-while working with a stylus (high-end tablets often come with a physical
-switch for this nowadays, and this can also be disabled in tablet
-settings). With this in mind, we have decided to not make it a priority
-compared to some other work-in-progress so it is therefore not sure if
-GIMP 3 will come with specific gesture support. This is not to say that
-we don't want it, and we welcome any patches from anyone willing to make
-it one's priority.
+to draw, with pressure, tilt, and everything.
+
+We are also trying to improve general support by making the advanced configuration of input devices easier 
to do.
+
+A while ago, we also experimented with support for touch gestures like
+zooming, panning, rotating etc. We did not finish this work because we
+realized this was not a priority compared to some other features.
+
+Touch gestures are very nice and awesome but also sometimes become a burden.
+Actually, many professional artists even disable touch sensitivity to
+prevent unwanted input while working with a stylus (high-end tablets often
+come with a physical switch for this nowadays, and this can also be disabled
+in tablet settings). With this in mind, we have decided to not make it
+a priority compared to some other work-in-progress. So we are not sure
+whether  specific gesture support will make it to GIMP v3.0. We do
+welcome patches from anyone willing to make it one's priority though.
 
 *Status*: some work needs to be done to simplify configuration dialog as
-support of legacy features are either not needed anymore nowadays or can
-be better presented. Some Wayland-specific handling may be in order as
-well, since Wayland brings news abilities to input devices.
+the support for legacy features is either not needed anymore nowadays or
+can be done better. We might also need to add support for Wayland-specific
+features related to input devices.
 
 ### Theming
 
 With GTK3, we also inherit its CSS-based theme format. Unfortunately
 this means that all custom-made themes from past versions will be
-incompatible in GIMP 3 and over. On the bright side, this new theme
-format using a very well known theming standard should make it much
-easier to tweak GIMP interface to your needs and preferences.
-
-Moreover symbolic icon theme are much better supported. They will follow
-the theme-set foreground and background colors. For anyone who changed
-one's theme in GIMP 2.10 from dark to a light theme, you probably
+incompatible with GIMP 3.0 and future releases. On the bright side,
+this new theme format uses a very well known theming standard. This
+should make it much easier to tweak GIMP's interface to your needs and
+preferences.
+
+Moreover, the symbolic icon themes are much better supported. They will
+follow the theme-set foreground and background colors. If you ever had to
+switch from a dark theme to a light one in GIMP 2.10, you probably
 remember you also had to switch the symbolic icon themes manually. This
 won't be necessary anymore as symbolic icons will be recolored according
 to your theme.
 
-Finally "dark theme" is a core concept of GTK3, which means for instance
-that even window decorations get recolored as can be seen in the
-screenshot above.
-Also a same theme may propose both a dark and light variant so the Theme
-preferences shows a "*Use dark theme variant if available*" checkbox.
-Similarly icon themes may propose symbolic and color icons.  Once again
-our Icon Theme preferences provides a "*Use symbolic icons if
-available*" checkbox allowing you to indicate your prefered style.
+Finally, the "dark theme" is a core concept of GTK3, which means,
+for instance, that even window decorations get recolored as you can see
+in the screenshot above.
+
+Also, the same theme could propose both a dark and a light variant, so
+the *Theme* preferences shows the *"Use dark theme variant if available"*
+checkbox. Similarly, icon themes may propose both symbolic and color icons. Which is why the *"Icon Theme"* 
preferences page has a *"Use symbolic icons if
+available"* switch so that you could choose your preferred style.
 
 <figure>
 <img src="{attach}gimp-2.99.2-themes.jpg" alt="Theme switching"/>
@@ -126,47 +123,46 @@ available*" checkbox allowing you to indicate your prefered style.
 
 *Status*: waiting for theme contributors.
 
-On core side, there is not much more to do. Yet you will
-notice that GIMP 2.99.2 only proposes you the "System" theme, which
-basically means no theme (or rather, that GIMP follows your system
-theme as the name implies). Something we want before releasing GIMP 3.0
-is a default custom theme with a neutral dark/light variant as well as a
-neutral middle-gray custom theme.
-The main issue with system themes is that they are solely meant to be
-pretty. Yet advanced graphics work requires a neutral gray theme in
-order not to pollute your color perception. This is the main reason why
-GIMP needs to default to a neutral color theme with symbolic icons (of
-course, people are free to install pretty-colored themes and icons,
-and I'm sure that the community will quickly create awesome ones).
-Unfortunately we currently have no contributions in this regard. This is
-a very good way to contribute to GIMP as a non-developer. **We welcome
-theme designers very warmly!**
+We've already done most if not all changes in source code related to
+theming. For now, GIMP 2.99.2 only lists the "System" theme, which
+basically GIMP will follow your system-wide GTK theme. This is a regression
+from 2.10 that we intend to fix in time for GIMP 3.0 by reintroducing
+a default custom theme with a neutral dark/light variant as well as
+a neutral middle-gray custom theme.
+
+The main issue with system themes is that they cover very basic desktop
+use cases. Meanwhile, advanced graphics work requires a neutral gray theme
+to avoid polluting your color perception. This is the main reason why
+GIMP needs to default to a neutral color theme with symbolic icons.
+
+Colored icon themes can still be an option, and, in fact, we are pretty
+sure that the community will soon come up with good-looking custom themes.
+This is a great way to contribute to GIMP as a non-developer!
 
 ### Wayland support
 
-The port to GTK3 should normally give us Wayland support without having
-anything to do. And it basically does so. GIMP 2.99.2 runs natively on
-Wayland.
-
-Unfortunately a few bugs were already reported with GIMP on Wayland,
-some of them quite blocking (such as various weird GUI bugs or [huge
-memory leaks](https://gitlab.gnome.org/GNOME/gimp/-/issues/4092)), other
-less serious but still a bit embarassing (broken splash image with high
-density scaling because Wayland doesn't report scaling properly).
-So we probably can't say we have an appropriate Wayland support unless
-these issues get fixed. We welcome very warmly patches on this matter
-(on GIMP, GTK or other part of the stack depending on what we find out):
-[list of Wayland-related
-bugs](https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Environment%3AWayland).
-
-With Wayland comes also the need to reimplement a few features through
-"portals". This was done for the screenshot plug-in (using Freedesktop,
-GNOME and KDE portals) and there is some work-in-progress for on-display
-color picking (working on KDE, not yet on GNOME and Freedesktop
-portals).
-As for the file portal, this is probably something which won't happen
+The port to GTK3 should normally give us Wayland support on Linux for free.
+And it mostly does. Unfortunately, a few bugs have already been reported
+for GIMP running on Wayland. Some of them are clearly blockers for releasing
+GIMP 3 (such as various weird GUI bugs or [huge memory 
leaks](https://gitlab.gnome.org/GNOME/gimp/-/issues/4092)). Others are less serious
+but still are a bit embarrassing, like the one where the splash screen is
+broken on HiDPI displays because Wayland doesn't report scaling properly.
+
+Until these issues are fixed, we don't think we can safely claim that we
+provide appropriate Wayland support. We will be grateful for all patches to
+address that, whether they arrive to GIMP, GTK, or another relevant part
+of the technology stack. If you are interesting in helping out, here is the
+[list of Wayland-related 
bugs](https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Environment%3AWayland).
+
+Appropriate Wayland support also means we need need to reimplement a few
+features through so called portals. We have already done this for the
+screenshot plug-in (using Freedesktop, GNOME, and KDE portals), and there
+is some ongoing work to fix on-display color picking (already works in KDE,
+doesn't yet work with GNOME and Freedesktop portals).
+
+As for the file portal, this is probably something that won't happen
 for GIMP 3.0, because we still require some features of the GTK file
-dialog, but it may happen later with a planned redesign for improved
+dialog, but it might happen later with a planned redesign for improved
 export process.
 
 *Status*: a few blocking bugs in particular require attention. We
@@ -174,19 +170,12 @@ welcome contributions.
 
 ## Multi-layer selection
 
-One of the major annoyances of layer management in GIMP until now was
-the inability to select more than one layer. Before even being a pixel
-processing feature, this is an organizational bother for professional
-and advanced users who often use several dozens of layers in their most
-complicated images. Imagine having to move 20 layers into a layer group,
-or reordering them, one by one, tediously…
-
-[Aryeom](https://film.zemarmot.net/en/), the animation film director
-working with the core team, has been asking for this ever since 2015, so
-*ZeMarmot* project finally worked to make this happen. This was another
-example of close artist-developer collaboration project as every feature
-was carefully designed by discussions and have actually been tested in
-production ever since March 2020.
+Managing a complex project with tens and hundreds of layers is now much
+easier thanks to newly added multi-layer selection. [Aryeom](https://film.zemarmot.net/en/), the animation 
film director
+working with the core team, has been asking for this since 2015, so
+*ZeMarmot* project finally made this happen. This is another
+example of a successful close artist-developer collaboration: every feature
+was carefully designed following discussions and was tested in production.
 
 <figure>
 <img src="{attach}gimp-2.99.2-multi-layer-selection.png" alt="Selecting multiple layers in Layers dockable"/>
@@ -196,8 +185,8 @@ production ever since March 2020.
 </figure>
 
 The Layers dockable is now fully multi-selection aware, using the usual
-interaction for multi items selection (`Shift+click` for selecting a
-range of layers and `Ctrl+click` for selecting or unselecting
+interaction for multi-items selection (`Shift+click` for selecting a
+range of layers and `Ctrl+click` for selecting or deselecting
 non-contiguous layers). Organizational operations now work on all
 selected layers, i.e. that you can move, reorder, delete, duplicate,
 merge (and more…) all selected layers at once.
@@ -205,49 +194,42 @@ merge (and more…) all selected layers at once.
 Several tools now also work on multiple selected layers. For instance
 all transform tools (move, rotation, scale, perspective, unified
 transform…) will transform all selected layers (in addition to the existing
-layer links with the "chain" icon). You may also crop several layers at
-once or copy-paste merged layers' projection. Even the Color Picker tool
+layer links with the "chain" icon). You can also crop several layers at
+once or copy-paste merged layers' projection. Even the *Color Picker* tool
 can now pick merged color from several layers (some kind of partial
 "Sample merged" without having to hide unwanted layers).
 
-These are only a few examples because this change really spreads through
-the whole codebase, since the concept of "active layer" is prominent
-in every action. You are welcome to read through this [development
-report](https://www.patreon.com/posts/report-on-for-in-37266151),
-containing many images and descriptions. There is of course even more
-which you can discover yourself!
+These are just a few examples because this change affects a large part
+of the code base: the concept of an active layer is prominent in every
+action. You can read more about this in a [detailed development
+report](https://www.patreon.com/posts/report-on-for-in-37266151).
 
-*Status*: the multi-layer selection work is still ongoing. Some parts
-are still expecting a single layer and need to be ported before
-release, and it is not impossible that some features may even be
-broken (that's why we have development releases, to discover bugs!).
+*Status*: this is a work in the progress.
 
-Moreover we may extend the multi-item selection ability to paths and
-channels soon.
+Some features in GIMP still expect a single layer and need to be fixed
+before the final release. It's possible that we will inadvertently break
+something while working on that, which is why it's important that we do
+more development releases. Moreover, we might extend the multi-item
+selection to paths and channels soon.
 
-Finally painting and GEGL operations (filters) are still limited to
+Finally, painting and GEGL operations (filters) are still limited to
 single layers. Adding ability to paint or run pixel operations on
 several pixels at once will probably require some additional interface
-specification and designing to prevent undesired consequences (extremely
-slow operation, ability to cancel long-running process and early
-discovery of mistake editing are the main design issues to solve).
+specification and designing to prevent undesired consequences like
+extremely slow operation or the ability to cancel a long-running process.
 
 ## Plug-in API
 
-The plug-in API got many improvements, though we also took care not to
-break too widely the existing API when not necessary. It is estimated
-that a single-file plug-in working for the GIMP 2.10 series can be
-ported to GIMP 3 in between 5 and 30 minutes. We will provide a porting
-documentation when releasing GIMP 3.
-
-One of the first step you can work on if you already have working
-plug-ins on GIMP 2.10.x is to make sure you don't use any deprecated
-functions. All deprecated functions have been removed from GIMP 3 API
-(since we bump the major version, this is the time to make a clean
-slate). We compiled a [list of functions removed and their
-replacement](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-plug-in-porting-guide/removed_functions.md).
-You can already do this part of the port while still targetting GIMP
-2.10.x versions.
+We had to break the plug-in APi to introduce many improvements, although we
+took a special care not to break things where it wasn't necessary to do so. 
+
+Porting a single-file plug-in from GIMP 2.10 to GIMP 3 usually takes between
+5 and 30 minutes. We are working on a porting documentation to be released
+along with GIMP 3.
+
+If you are a plug-in developer, one of the first steps you can take is
+making sure you don't use any deprecated functions. We compiled a [list of functions removed and their
+replacement](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-plug-in-porting-guide/removed_functions.md).
 You can already do this part of the port while still targeting GIMP 2.10.x versions.
 
 ### Object API
 
@@ -464,17 +446,15 @@ updated before release.
 We have started to write down some documentation regarding plug-in
 development in GIMP 3, and will progressively start to publish some
 tutorials. Hopefully we will even be able to relaunch our developer
-website who have been abandonned for too many years.
-
-We really hope that GIMP 3 will breath some new life into the GIMP
-plug-in ecosystem!
+website that has been slowly decaying for too many years. We hope that
+GIMP 3 will revitalize the GIMP plug-in ecosystem!
 
-*Status*: still early idea stage of this project and we welcome more
-contributors on this side to make it possible.
+*Status*: still at an early stage, we welcome more contributors to make
+it possible.
 
 ## Extensions
 
-Extensions are a new file format which is basically only a wrapper of
+Extensions are a new file format that is basically only a wrapper of
 data (brushes, splash screens, patterns, dynamics…) or plug-ins,
 associated with some metadata (name, description, screenshots, version,
 requirements…). The goal will be to allow plug-in developers to publish
@@ -497,21 +477,20 @@ Goat Exercises`.
 </figcaption>
 </figure>
 
-We will explain further this feature when we will have developed more,
-and in particular we will provide appropriate documentation for
-extension creation.
-It is definitely something plug-in and resource creators should look
-forward to, as it will help share your creations with others.
+We'll get back to talking about this feature after we've done more work
+on it. In particular, we will provide documentation how to create
+extensions. It is definitely something plug-in and resource creators
+should be look forward to, as it will help share their creations with
+others.
 
-*Status*: still more work to do on GIMP side, especially for
+*Status*: still more work to do on the GIMP side, especially for
 communicating with repositories, and much more work for the official
 repository and website for extensions to be done.
 
 ## Space invasion
 
 "*Space invasion*" is the internal code name for the work originally
-started in
-[2018](https://www.gimp.org/news/2018/08/19/gimp-2-10-6-released/#prepare-for-the-space-invasion)
+started in [2018](https://www.gimp.org/news/2018/08/19/gimp-2-10-6-released/#prepare-for-the-space-invasion)
 whose goal was proper support of color space during core pixel
 processing. In the GIMP 2.10 series, despite core color management
 support, the profiles were sometimes lost during an operation processing
@@ -526,24 +505,25 @@ explains this really well.
 
 Some of the improvements of this work have already been progressively
 backported to various GIMP 2.10.x releases, but GIMP 3.0 should be the
-culminating release where we hope to get this fully right.
+culminating release where we hope to get this 100% right.
 
 *Status*: the development branch is much more advanced on this topic
-than the 2.10 series, but some more work need to be done. Various
-aspects of GIMP still mostly expect or display sRGB only values.
+than the 2.10 series, but some more work needs to be done. Various
+aspects of GIMP still mostly expect or display sRGB-only values.
 
 ## Render caching
 
 GIMP 3 now has a render cache that keeps the result of scaling, color
 management, display filters and shell mask (for tools like _Fuzzy Select_).
-This results in much snappier user experience in comparison to the GTK2 version
-of GIMP.
+This results in much snappier user experience in comparison to the GTK2
+version of GIMP.
 
-There is now also a _Zoom Quality_ setting in _Preferences -> Display_. When set
-to _Fast_, GIMP will do a nearest neighbor interpolation from the next bigger
-mipmap level instead of linear or box filtering. This gives a slight and
-permanent boost to painting and all updates. We have a few ideas to improve this
-further (like reblitting in high quality after a timeout).
+There is now also a _Zoom Quality_ setting in _Preferences -> Display_.
+When set to _Fast_, GIMP will do a nearest neighbor interpolation from
+the next bigger mipmap level instead of linear or box filtering. This
+gives a slight and permanent boost to painting and all updates. We have
+a few ideas to improve this further like reblitting in high quality
+after a timeout.
 
 *Status*: done.
 
@@ -553,15 +533,14 @@ further (like reblitting in high quality after a timeout).
 Profile*" and the import dialog default "Convert" action will convert
 the image to the preferred profile (if any was set, otherwise it falls
 back to the built-in profile). Converting to the built-in profile will
-be still available as secondary action.
-This allows people who want to always work with a given profile to be
-able to set up their prefered workflow as soon as import is done.
+still be available as a secondary action. If you want to always work with
+a given profile, you can set up your preferred workflow as soon as importing
+is done.
 
-Moreover a new **Metadata Rotation Policy** is exposed in the
-Preferences dialog, next to the *Color Profile Policy* (in page
-`Preferences > Image Import & Export`) with 3 options: "Ask what to do",
-"Discard metadata without rotating" and "Rotate the image then discard
-metadata".
+Moreover, a new **Metadata Rotation Policy** is exposed in the *Preferences*
+dialog, next to the *Color Profile Policy* (in page `Preferences >
+Image Import & Export`) with 3 options: "Ask what to do", "Discard metadata
+without rotating", and "Rotate the image then discard metadata".
 
 <figure>
 <img src="{attach}gimp-2.99.2-import-policies-prefs.jpg" alt="Import Policies"/>
@@ -570,24 +549,21 @@ metadata".
 </figcaption>
 </figure>
 
-The metadata rotation policy used to be handled API-side, with a dialog
-generated by `libgimpui` and saved in a global parasite. The whole
-logics and GUI has been moved as core logics, similar to the "Color
-Profile Policy". This implies that plug-ins don't even need to handle
-this as this will happen as specified by the user automatically on every
-new import.
+The metadata rotation policy used to be handled on the API side, with
+a dialog generated by `libgimpui` and saved in a global parasite.
+The whole logics and GUI has been moved as core logics, similar to the
+"Color Profile Policy". This implies that plug-ins don't even need to
+handle this as it will happen as specified by the user automatically
+on every new import.
 
 *Status*: done.
 
 ## Compact sliders
 
 The compact spin scale was introduced in [GIMP
-2.10.18](https://www.gimp.org/news/2020/02/24/gimp-2-10-18-released/#compact-sliders).
-In the 2.10 series, it was left as an optional feature which could be
-deactivated in the Preferences.
-
-In GIMP 3, these have been made the only variant (no preference
-anymore).
+2.10.18](https://www.gimp.org/news/2020/02/24/gimp-2-10-18-released/#compact-sliders). In the 2.10 series, 
it was left as an optional feature which could
+be deactivated in the *Preferences* dialog. In GIMP 3, this is now the
+only possible behavior, with no options.
 
 <figure>
 <img src="{attach}gimp-2.99.2-compact-spin-scale.png" alt="Compact slider"/>
@@ -596,32 +572,30 @@ anymore).
 </figcaption>
 </figure>
 
-Note that it has been noted that the bright blue color may not be the
-best idea but the color in this screenshot does not reflect a color
-choice, only the underlying system theme during screenshot.
-This widget actually uses `GtkProgressBar` colors by default. Therefore
-this can be updated in a custom theme by changing `GtkProgressBar`
-colors or only the colors in this specific widget (cf. our need for
-theme contributors).
+Please note that the bright blue color on the screenshot is not our
+preference, it's what the system theme dictates. This widget actually
+uses `GtkProgressBar` colors by default. Therefore this can be adjusted
+in a custom theme by changing `GtkProgressBar` colors or only the colors
+in this specific widget (again, we welcome theme contributors!).
 
 *Status*: done.
 
 ## Refactoring
 
 While porting old features and implementing new features, a lot of side
-work has been done on the code structure obviously. So many parts of the
-code base got refactored for better maintenance.
+work has been done on the code structure. So many parts of the code base
+got refactored for better maintenance.
 
 Even when some port is not done yet, ground work may have been prepared,
 such as the `GimpAction` interface to add a layer of abstraction to
 `GtkAction` (preparing us to actually move away from it at a later
 point which is one of the main remaining big ports for the move to GTK3).
 
-Many other parts are constantly remodeled and improved as a constant
-background work.
+Many other parts are constantly remodeled and improved as part of
+a never-ending background work.
 
-*Status*: refactoring is always in progress, always was, always will.
-This is a developer's continuous task!
+*Status*: refactoring is always work in the progress, always was, always
+will be. It never really stops.
 
 ## Packaging
 ### Beta Flatpak available
@@ -662,50 +636,41 @@ As usual, we provide a Windows installer for GIMP, you will find it on the
 [Development Downloads page](https://www.gimp.org/downloads/devel/).
 
 Some features may be missing. In particular, you won't find the
-Javascript binding on the Windows build because of the complexity of
-some dependencies.
+JavaScript binding on the Windows build because of the complexity of
+some dependencies. We will fix this in future releases leading up
+to GIMP 3.
 
 ### macOS
 
 Our macOS packager has still not fully returned, so unfortunately there
-is no official macOS package. As always, we remind that GIMP is a Free
-Software developed as a community. It means that any of you can become
-an official package maintainer (or hopefully even several of you for
-redundancy).
+is no official macOS package. As always, we remind that GIMP is free/libre
+software developed by community. Any of you can become an official package maintainer (and having several 
contributors would keep everyone safe).
 
 If you are interested, we suggest to get in touch with us on our
 [IRC](https://www.gimp.org/irc.html) channel for developers, `#gimp`.
 
 ## What's next
 
-As you can see, a lot has been done (the
-[`NEWS`](https://gitlab.gnome.org/GNOME/gimp/-/blob/4f201556967d9e7c868601698e9e3d957c1c27ea/NEWS#L46)
-file will also give a bit more details). Actually the main part of most
-task has been mostly done. Now what remains is the final stroll. This is
+As you can see, a lot has been done (the 
[`NEWS`](https://gitlab.gnome.org/GNOME/gimp/-/blob/4f201556967d9e7c868601698e9e3d957c1c27ea/NEWS#L46)
+file will also give a bit more details). The vast majority of the work
+has already been done. What remains now is the final stroll. This is
 however not such an idle walk in the park, as the last decisions and
 attention to details is always the most difficult part. We want to
-release a rock-solid GIMP 3 and needs to take a lot of care to all the
-small little things. This is where we are now and why we are releasing
-this first development version.
+release a rock-solid GIMP v3 and need to pay a lot of attention to
+details. This is where we are now and why we are releasing this first
+development version.
 
-This [development
-report](https://www.patreon.com/posts/what-remains-to-40087754) lists
-pretty accurately all the remaining steps, and you'll notice how it
+This [development report](https://www.patreon.com/posts/what-remains-to-40087754) lists pretty accurately 
all the remaining steps, and you'll notice how it
 actually follows quite well the changes in GIMP 2.99.2. The API part,
 though going unnoticed to many users, is probably the major part which
-we must absolutely get right before release since our API is meant to be
-stable. Once we have it done, we will want to keep existing interfaces of
-`libgimp` 3.0.0 functions unchanged unless absolutely necessary (i.e.
-unless we discover bugs which made a function useless). This will likely
-take a lot of our time.
-
-There are definitely other parts as well where any help would be
-appreciated. As said, we are at a step with a lot of little details and
-cleanups to take care of, be it on plug-ins, core code, user interface,
-application interface… everwhere! This also means that it is the step
-where it's the easiest to miss some of the details. This is why the more
-eyes are looking, the better we can find all the little issues before
-making a finale release.
+we must absolutely get right before the release since our API is meant
+to stay stable withing the 3.x series. Once we have it done, we will want
+to keep existing interfaces of `libgimp` 3.0.0 functions unchanged unless absolutely necessary (i.e. unless 
we discover bugs that made a function
+useless). This is likely to take a lot of our time.
+
+There are definitely other parts where help will be crucial, whether it's
+plug-ins, core code, user interface, or application interface. So we do
+need more eyes on this to resolve as many little issues as we can.
 
 To conclude, we remind that you can [donate to the project and
 personally fund several GIMP