Google newspeak. inclusive writing guide (2019)

developers.google.com/style/inclusive-documentation

Home > Products > Style

Writing inclusive documentation

Key Point: Write using inclusive language, word choice, and examples.

We write our developer documentation with inclusivity and diversity in mind. This page is not an exhaustive reference, but describes some general guidelines and examples that illustrate some best practices to follow.

Avoid ableist language

When trying to achieve a friendly and conversational tone, problematic ableist language may slip in. This can come in the form of figures of speech and other turns of phrase. Be sensitive to your word choice, especially when aiming for an informal tone. Ableist language includes words or phrases such as crazy, insane, blind to or blind eye to, cripple, dumb, and others. Choose alternative words depending on the context. For example:

I Not recommended: Before launch, give everything a final sanity-check.

Recommended: Before launch, give everything a final check for completeness and clarity.

I Not recommended: There are some crazy outliers in the data.

Recommended: There are some baffling outliers in the data.

Not recommended: It cripples the service, causing a poor user experience until the queue clears.

Recommended: It slows down the service, causing a poor user experience until the queue clears.

Not recommended: Replace the dummy variable in this example with the appropriate variable.

Recommended: Replace the placeholder variable in this example with the appropriate variable.

Avoid unnecessarily gendered language

In addition to being mindful of the pronouns used in narrative examples, be sensitive to other possible sources of gendered language.