Replace oppressive terms with inclusive terms.
Daniel Golle
daniel at makrotopia.org
Wed Jun 23 00:04:36 PDT 2021
Hi Fernando,
On Tue, Jun 22, 2021 at 10:57:24PM -0300, Fernando Frediani wrote:
> A note I made is that it is important to find out what exactly are the
> "oppressive words" and "inclusive terms" in order to fall into a annoying
> and unnecessary scenario of political correctness that may end up distancing
> people and under privileging technical knowledge in favor of pure ideology.
Yes, I can see that can be an issue in some cases, and this shouldn't
be about establishing another l33t-speak, used yet again as a tool for
oppression and not actually helping anyone.
Please take a look at the patch series posted for hostap:
https://lists.infradead.org/pipermail/hostap/2021-June/039653.html
I think most of these are very good examples of linguistical
**improvements** even without wearing any ideological glasses (if that's
something even possible at all, I guess everyone is wearing some at all
time; denying that is also just yet another ideology which is not aware
of itself being one).
Chances for confusions or misunderstandings are even reduced as using
'valid' or 'validity' instead of 'sane' or 'sanity' is actually really
what is meant there to begin with.
Of course, replacing 'native' with 'built-in' in every case is the
counter example here, as many things which we consider 'native' aren't
necessarily 'built-in' at all. Sometimes they are just 'originally made
or designed for something' or 'commonly used in the context of something'.
However, this patch series shows that every single case can be an
improvement, none of the replacement terms are uncommon or hard to
understand, all of them have dictionary definition which are closer to
what we actually want to express than the terms replaced.
Best regards
Daniel
>
> Regards
>
> On 22/06/2021 19:49, Daniel Golle wrote:
> > Hi Arowa,
> >
> > thank you very much for your work on this issue!
> >
> > I am aware that this is an uphill battle as it disrupts routine without
> > being technically necessary.
> > Many of us will go through episodes where we get annoyed with our own
> > habits and constantly want to apologize when we accidentally use terms
> > with oppressive heritage (and I must admit this still happens to me quite
> > often, it takes more than 'sed' to make these changes in our brains as
> > well).
> >
> > To make the computing world a better place, at least for future
> > generations, I sincerely hope efforts like this succeed.
> >
> > If you have scripts to easily detect suppressive language in a code
> > repository and suggest meaningful replacements, like the ones in this
> > patch series, I would be happy if you could share them with me so that I
> > can suggest similar changes for openwrt.git. Pre-built 'sed' scripts (and
> > perhaps 'coccinelle'[1] patches when we work on code) would of course be
> > great for this purpose, as it would reduce the risk of breaking something
> > (and also make it easier and guarantee consistency)
> >
> > With kind regards
> >
> >
> > Daniel
> >
> > [1]: https://coccinelle.gitlabpages.inria.fr/
> >
> > On Tue, Jun 22, 2021 at 02:29:01PM -0700, Arowa Suliman wrote:
> > > As part of using inclusive language in code, submitting the following
> > > patches to replace some of the instances of oppressive words with
> > > inclusive terms.
> > > In-Reply-To:
> > >
> > >
> > >
> > > _______________________________________________
> > > Hostap mailing list
> > > Hostap at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/hostap
> > _______________________________________________
> > openwrt-adm mailing list
> > openwrt-adm at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-adm
>
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm
More information about the openwrt-adm
mailing list