From 305e5c0fe9aae2772c7877fd9610351b7e1ab6b6 Mon Sep 17 00:00:00 2001
From: cathariv <cathariv@mskcc.org>
Date: Thu, 15 Aug 2024 14:03:29 -0400
Subject: [PATCH 1/2] Proofread vignetttes, fixes #2707

---
 vignettes/customise.Rmd                   | 74 +++++++++++------------
 vignettes/how-to-update-released-site.Rmd | 40 ++++++------
 vignettes/linking.Rmd                     |  4 +-
 vignettes/metadata.Rmd                    | 12 ++--
 vignettes/pkgdown.Rmd                     | 14 ++---
 vignettes/translations.Rmd                |  6 +-
 6 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/vignettes/customise.Rmd b/vignettes/customise.Rmd
index 44e5691ad..585f29515 100644
--- a/vignettes/customise.Rmd
+++ b/vignettes/customise.Rmd
@@ -21,7 +21,7 @@ We'll start by discussing two techniques that only require tweaks to your `_pkgd
 We'll then discuss how to add additional HTML and other files.
 Next, we'll discuss how to give multiple sites the same style using a package, then finish up with some workflow advice.
 
-In terms of your `_pkgdown.yml`, this vignette focusses on the most important fields nested under `template` and `navbar`. To learn more about customising other aspect of the site, see the documentation for the indiviudal functions like `build_reference()`, `build_articles()`,  `build_home()`, `build_redirects()`, and `init_site()`. To learn about less important fields nested under `template`, see `build_site()`.
+In terms of your `_pkgdown.yml`, this vignette focusses on the most important fields nested under `template` and `navbar`. To learn more about customising other aspects of the site, see the documentation for the indiviudal functions like `build_reference()`, `build_articles()`,  `build_home()`, `build_redirects()`, and `init_site()`. To learn about less important fields nested under `template`, see `build_site()`.
 
 ```{r setup}
 library(pkgdown)
@@ -45,18 +45,18 @@ Upgrading to Bootstrap 5 has a low chance of breaking your site unless you were
 There are two ways to change the visual style of your site from `_pkgdown.yml`: using a pre-packaged bootswatch theme or customising theme variables with [bslib](https://rstudio.github.io/bslib/).
 The following sections show you how.
 
-Please note that pkgdown's default theme has been carefully optimised to be accessible, so if you make changes, make sure that to also read `vignette("accessibility")` to learn about potential accessibility pitfalls.
+Please note that pkgdown's default theme has been carefully optimised to be accessible, so if you make changes, make sure to also read `vignette("accessibility")` to learn about potential accessibility pitfalls.
 
 ### Light switch {#light-switch}
 
-You can provide a "light switch" to allow your uses to switch between dark and light themes by setting the `light-switch` template option to true:
+You can provide a "light switch" to allow your users to switch between dark and light themes by setting the `light-switch` template option to true:
 
 ```yaml
 template:
   light-switch: true
 ```
 
-This will add a `lightswitch` component to the navbar, which defaults to appearing at the far right. This allows the user to select light mode, dark mode, or auto mode (which follows the system setting). The modes are applied using Bootstrap 5.3's [colours modes](https://getbootstrap.com/docs/5.3/customize/color-modes/) so are not separate themes, but a thin layer of colour customisation applied via CSS.
+This will add a `lightswitch` component to the navbar, which by default appears at the far right. This allows the user to select light mode, dark mode, or auto mode (which follows the system setting). The modes are applied using Bootstrap 5.3's [colours modes](https://getbootstrap.com/docs/5.3/customize/color-modes/) so are not separate themes, but a thin layer of colour customisation applied via CSS.
 
 ### Bootswatch themes
 
@@ -89,8 +89,8 @@ You can find the correct height by running `$(".navbar").outerHeight()` in the [
 ### bslib variables
 
 Instead of picking a complete theme, you can tweak fonts and colours individually using bslib variables.
-[bslib](https://rstudio.github.io/bslib/) is an R package that wraps sass, the tool that Boostrap uses to produce CSS from a special language called [scss](https://sass-lang.com).
-The primary advantage of scss over CSS is that it's more programmable, so you can have a few key bslib variables that affect appearance of many HTML elements.
+[bslib](https://rstudio.github.io/bslib/) is an R package that wraps scss, the tool that Boostrap uses to produce CSS from a special language called [scss](https://sass-lang.com).
+The primary advantage of scss over CSS is that it is more programmable, so you can have a few key bslib variables that affect appearance of many HTML elements.
 
 There are three key variables that affect the colour:
 
@@ -109,10 +109,10 @@ template:
 
 You can customise other components by setting more specific bslib variables, taking advantage of inheritance where possible.
 For example, `table-border-color` defaults to `border-color` which defaults to `gray-300`.
-If you want to change the colour of all borders, you can set `border-color`; if you just want to change the colour of table borders, you can set `table-border-color`.
+If you want to change the colour of all borders, you can set `border-color` and if you just want to change the colour of table borders, you can set `table-border-color`.
 You can find a full list of variables in the [bslib docs](https://rstudio.github.io/bslib/articles/bs5-variables/index.html).
 
-If you're using the light switch, [many colours](https://getbootstrap.com/docs/5.3/customize/color-modes/#sass-variables) are available for customisation specifically for the dark theme.
+If you are using the light switch, [many colours](https://getbootstrap.com/docs/5.3/customize/color-modes/#sass-variables) are available for customisation specifically for the dark theme.
 
 Theming with bslib is powered by `bslib::bs_theme()` and the `bslib` field is a direct translation of the arguments to that function.
 As a result, you can fully specify a bslib theme using the `template.bslib` field, making it easy to share YAML with the `output.html_document.theme` field [of an R Markdown document](https://rstudio.github.io/bslib/articles/theming/index.html).
@@ -142,7 +142,7 @@ template:
     code_font: {google: "JetBrains Mono"}
 ```
 
-If you want to use a non-Google font, you'll need to do a bit more work. There are two steps: you need to first configure the font with CSS and then use it in your `_pkgdown.yml`. There are two ways you might get the CSS:
+If you want to use a non-Google font, you will need to do a bit more work. There are two steps: you need to first configure the font with CSS and then use it in your `_pkgdown.yml`. There are two ways you might get the CSS:
 
 * As a block of CSS which you should put in `pkgdown/extra.scss` or `pkgdown/extra.css`. The CSS will look something like this:
 
@@ -178,9 +178,9 @@ template:
     base_font: proxima-nova
 ```
 
-Depending on where the font is from (and if you paid money for it), you may need to take additional steps to ensure that it can only be used from your site, and/or make sure that it can still be used when you're previewing locally. If you're having problems getting a custom font to work, looking for errors in the [browser developer console](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools) is a good place to start.
+Depending on where the font is from (and if you purchased it), you may need to take additional steps to ensure that it can only be used from your site, and/or make sure that it can still be used when you're previewing locally. If you are having problems getting a custom font to work, looking for errors in the [browser developer console](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools) is a good place to start.
 
-When iterating on fonts, you'll need to run `build_home_index(); init_site()` then refresh you browser to see the update.
+When iterating on fonts, you will need to run `build_home_index(); init_site()` then refresh your browser to see the update.
 
 
 ### Syntax highlighting
@@ -243,12 +243,12 @@ navbar:
   bg: primary
 ```
 
-You generally don't need to set `bg` if you use a bootswatch theme, as pkgdown will pick the `bg` used on the [Bootstwatch preview](https://bootswatch.com/).
-Similarly, you don't usually need to set `type` because bootstrap will guess it for you.
-If it guesses wrong, override with `type: light` or `type: dark` depending on whether the background colour is light (so you need dark text) or `type: dark` if the background is dark (so you need light text).
-Unfortunately, these are defined relative to the page background, so if you have a dark site you'll need to flip `light` and `dark` (a little experimentation should quickly determine what looks best).
+You generally don not need to set `bg` if you use a bootswatch theme, as pkgdown will pick the `bg` used on the [Bootstwatch preview](https://bootswatch.com/).
+Similarly, you do not usually need to set `type` because bootstrap will guess it for you.
+If the guess is wrong, you can override with `type: light` or `type: dark` depending on whether the background colour is light (so you need dark text) or `type: dark` if the background is dark (so you need light text).
+Unfortunately, these are defined relative to the page background, so if you have a dark site you will need to flip `light` and `dark` (a little experimentation should quickly determine what looks best).
 
-Because the navbar is styled with HTML, you'll need to `build_home_index(); init_site()` to see the effect of changing this parameter.
+Because the navbar is styled with HTML, you will need to `build_home_index(); init_site()` to see the effect of changing this parameter.
 
 ## Layout {#layout}
 
@@ -259,7 +259,7 @@ They all use a similar structure that separately defines the overall `structure`
 ### Navbar {#navbar-heading}
 
 You can customise the navigation bar that appears at the top of the page with the `navbar` field.
-It's made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
+It is made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
 This organisation makes it easy to mix and match pkgdown defaults with your own customisations.
 
 This is the default structure:
@@ -274,15 +274,15 @@ navbar:
 It makes use of the the following built-in components:
 
 -   `intro`: "Get Started", which links to a vignette or article with the same name as the package[^dots].
--   `reference`, if there are any `.Rd` files.
--   `articles`, if there are any vignettes or articles.
--   `tutorials`, if there any tutorials.
--   `news`, if `NEWS.md` exists.
--   `search`, the search box (see `?build_search` for more details).
--   `github`, a link to the source repository (with an icon), if it can be automatically determined from the `DESCRIPTION`.
--   `lightswitch`, a ["light switch"](#light-switch) to select light mode, dark mode, or auto mode.
+-   `reference`: if there are any `.Rd` files.
+-   `articles`: if there are any vignettes or articles.
+-   `tutorials`: if there any tutorials.
+-   `news`: if `NEWS.md` exists.
+-   `search`: the search box (see `?build_search` for more details).
+-   `github`: a link to the source repository (with an icon), if it can be automatically determined from the `DESCRIPTION`.
+-   `lightswitch`; a ["light switch"](#light-switch) to select light mode, dark mode, or auto mode.
 
-Note that customising `navbar` like this comes with a downside: if pkgdown later changes the defaults, you'll have to update your `_pkgdown.yml`.
+Note that customising `navbar` like this comes with a downside: if pkgdown later changes the defaults, you will have to update your `_pkgdown.yml`.
 
 [^dots]: Note that dots (`.`) in the package name need to be replaced by hyphens (`-`) in the vignette filename to be recognized as the intro. That means for a
     package `foo.bar` the intro needs to be named `foo-bar.Rmd`.
@@ -353,14 +353,14 @@ template:
     after_navbar: <!-- inserted after the navbar links -->
 ```
 
-These includes will appear on all screen sizes, and will not be collapsed into the the navbar drop down.
+These inclusions will appear on all screen sizes, and will not be collapsed into the the navbar drop down.
 
 You can also customise the colour scheme of the navbar by using the `type` and `bg` parameters. See above for details.
 
 ### Footer
 
 You can customise the footer with the `footer` field.
-It's made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
+It is made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
 This organisation makes it easy to mix and match the pkgdown defaults with your own customisations.
 
 This is the default structure:
@@ -374,12 +374,12 @@ footer:
 
 Which uses two of the three built-in components:
 
--   `developed_by`, a sentence describing the main authors of the package. (See `?build_home` if you want to tweak *which* authors appear in the footer.)
--   `built_with`, a sentence advertising pkgdown.
--   `package`, the name of the package.
+-   `developed_by`: a sentence describing the main authors of the package. (See `?build_home` if you want to tweak *which* authors appear in the footer.)
+-   `built_with`: a sentence advertising pkgdown.
+-   `package`: the name of the package.
 
 You can override these defaults with the `footer` field.
-The example below puts the authors' information on the right along with a legal disclaimer, and puts the pkgdown link on the left.
+The example below puts the author's information on the right along with a legal disclaimer, and puts the pkgdown link on the left.
 
 ``` yaml
 footer:
@@ -409,7 +409,7 @@ template:
 
 You can include additional files by putting them in the right place:
 
--   `pkgdown/extra.css` and `pkgdown/extra.js` will be copied in to rendered site and linked from `<head>` (after the pkgdown defaults).
+-   `pkgdown/extra.css` and `pkgdown/extra.js` will be copied to the rendered site and linked from `<head>` (after the pkgdown defaults).
 
 -   `pkgdown/extra.scss` will be added to the scss ruleset used to generate the site CSS.
 
@@ -427,7 +427,7 @@ It can contain any of the following:
 -   A configuration file in `inst/pkgdown/_pkgdown.yml`. This can be used to set (e.g.) author definitions, Bootstrap version and variables, the sidebar, footer, navbar, etc.
 -   Templates in `inst/pkgdown/templates/` will override the default templates.
 -   Assets in `inst/pkgdown/assets/` will be copied in to the destination directory.
-    (Note these files are only copied; you'll need to reference them in your stylesheet or elsewhere in order for them to be actually used.)
+    (Note these files are only copied; you will need to reference them in your stylesheet or elsewhere in order for them to be actually used.)
 -   `inst/pkgdown/extra.scss` will be added to the bslib ruleset.
     (Note that `extra.css` is not supported in templates.)
 
@@ -440,7 +440,7 @@ template:
   package: theverybest
 ```
 
-You then also need to make sure it's available when your site is build. Typically, you won't want to publish this package to CRAN, but you will want to publish to GitHub. Once you've done that, and assuming you're using the [usethis workflow](https://usethis.r-lib.org/reference/use_pkgdown.html), add the following line to your `DESCRIPTION`:
+You then also need to make sure it is available when your site is built. Typically, you will not want to publish this package to CRAN, but you will want to publish to GitHub. Once you have done that, and assuming you are using the [usethis workflow](https://usethis.r-lib.org/reference/use_pkgdown.html), add the following line to your `DESCRIPTION`:
 
 ```yaml
 Config/Needs/website: myorg/theverybest
@@ -454,14 +454,14 @@ To get some sense of how a theming package works, you can look at:
 -   [quillt](https://pkgs.rstudio.com/quillt) used for R Markdown packages;
 -   [rotemplate](https://github.com/ropensci-org/rotemplate) used for rOpenSci packages.
 
-But please note that these templates aren't suitable for use with your own package as they're all designed to give a common visual identity to a specific family of packages.
+But please note that these templates are not suitable for use with your own package as they are all designed to give a common visual identity to a specific family of packages.
 
 ### Porting a template package
 
-If you are updating a template package that works with pkgdown 1.0.0, create directories `inst/pkgdown/BS5/templates` and `inst/pkgdown/BS5/assets` (if you don't have any templates/assets make sure to a add dummy file to ensure that git tracks them).
+If you are updating a template package that works with pkgdown 1.0.0, create directories `inst/pkgdown/BS5/templates` and `inst/pkgdown/BS5/assets` (if you do not have any templates/assets make sure to a add dummy file to ensure that git tracks them).
 The `templates` and `assets` directories directly under `inst/pkgdown` will be used by pkgdown 1.0.0 and by pkgdown 2.0.0 if `boostrap: 3`.
 The directories under `inst/pkgdown/BS5/` will be used for pkgdown 2.0.0 with `boostrap: 5`.
-This lets your package support both versions of bootstrap and pkgdown.
+This lets your package support both versions of Bootstrap and pkgdown.
 
 ## PR previews
 
diff --git a/vignettes/how-to-update-released-site.Rmd b/vignettes/how-to-update-released-site.Rmd
index ed5513a98..410c1fd3e 100644
--- a/vignettes/how-to-update-released-site.Rmd
+++ b/vignettes/how-to-update-released-site.Rmd
@@ -20,29 +20,29 @@ knitr::opts_chunk$set(
 
 This vignette shows you how to update the released version of your site to match the dev version of the site, so the first step is to ensure that the dev site looks the way that you want it.
 
-This site assumes that you're a using recent version of our recommend [pkgdown action](https://github.com/r-lib/actions/blob/HEAD/examples/pkgdown.yaml). If your workflow does not contain `workflow_dispatch`, you will need to update `.github/actions/pkgdown.yaml` by running `use_github_action("pkgdown")`.
+This site assumes that you are using a recent version of our recommended [pkgdown action](https://github.com/r-lib/actions/blob/HEAD/examples/pkgdown.yaml). If your workflow does not contain `workflow_dispatch`, you will need to update `.github/actions/pkgdown.yaml` by running `use_github_action("pkgdown")`.
 
 ## Process
 
-If you're up to speed with the basic idea and just want some code to follow, here it is.
+If you are up to speed with the basic idea and just want some code to follow, here it is.
 Otherwise, read more below.
 
 ### Setup
 
-First, make sure you're in the `main` branch, and you have the latest version:
+First, make sure you are in the `main` branch, and you have the latest version:
 
 ```{r}
 gert::git_branch_checkout("main")
 gert::git_pull()
 ```
 
-Next figure out the released version that we're updating:
+Next figure out the released version that you are updating:
 
 ```{r}
 ver <- desc::desc_get_version()[1, 1:3]
 ```
 
-We'll use this to create and checkout the branch that you'll work in:
+You will use this to create and checkout the branch that you will work in:
 
 ```{r}
 gert::git_branch_create(paste0("pkgdown-v", ver), paste0("v", ver))
@@ -70,13 +70,13 @@ files <- c(
 glue::glue("git checkout v{ver} -- {files}")
 ```
 
-If you backport `DESCRIPTION`, you'll also need undo the change to the `Version`:
+If you backport `DESCRIPTION`, you will also need undo the change to the `Version`:
 
 ```{r}
 desc::desc_set_version(ver)
 ```
 
-Now build the site locally and check that it looks as you expect:
+Now build the site locally and check that it looks as expected:
 
 ```{r}
 pkgdown::build_site()
@@ -97,7 +97,7 @@ Then trigger the pkgdown workflow:
 2.  Select the pkgdown workflow.
 3.  Click *Run workflow* and select the branch you just pushed.
 
-If there's no dropdown menu for this, that means your pkgdown workflow config is not current.
+If there is no dropdown menu for this, that means your pkgdown workflow config is not current.
 
 ## Context
 
@@ -123,19 +123,19 @@ This directs pkgdown to "generate different sites for the development and releas
 
 The readr package demonstrates what happens in automatic development mode:
 
-[readr.tidyverse.org](https://readr.tidyverse.org) documents the released version, i.e. what `install.packages()` would deliver.\
-[readr.tidyverse.org/dev/](https://readr.tidyverse.org/dev/) documents the dev version, i.e. what you'd get by installing from GitHub.
+[readr.tidyverse.org](https://readr.tidyverse.org) documents the released version, i.e. what `install.packages()` will deliver.\
+[readr.tidyverse.org/dev/](https://readr.tidyverse.org/dev/) documents the dev version, i.e. what you would get by installing from GitHub.
 
 In this mode, `pkgdown::build_site()`, consults DESCRIPTION to learn the package's version number.
 For a development version number, the rendered site is written to `docs/dev/`.
 For a released version number, the site is written to `docs/`.
 (There are also other signals to alert users that they are reading documentation for a dev version vs. a released version.)
 
-Automatic development mode is recommended for packages with a broad user base, because it maximizes the chance that a user will read web-based documentation that reflects the package version that is locally installed.
+Automatic development mode is recommended for packages with a broad user base because it maximizes the chance that a user will read web-based documentation which reflects the package version that is locally installed.
 
 ### Publishing
 
-Now that we've established the meaning of a released (vs dev) site, we have to consider how the site is built (i.e. how the HTML is generated) and deployed (i.e. how the HTML is published to a website so people can see it.).
+Now that we have established the meaning of a released (vs dev) site, we have to consider how the site is built (i.e. how the HTML is generated) and deployed (i.e. how the HTML is published to a website so people can see it.).
 
 We recommend `usethis::use_pkgdown_github_pages()` to do basic pkgdown setup and configure a GitHub Actions (GHA) workflow to automatically render and publish the site to GitHub Pages. This function is bascially a shortcut for calling the following functions individually: 
 
@@ -176,8 +176,8 @@ Altogether this means that we:
 
 * Build and deploy for pushes to `main`.
 
-* Build, but don't deploy, for pull requests against `main`.
-  This reveals any pkgdown errors, but ensures the live site isn't
+* Build, but do not deploy, for pull requests against `main`.
+  This reveals any pkgdown errors, but ensures the live site is not
   updated until the pull request is merged (because the code is 
   pushed to `main`).
 
@@ -185,7 +185,7 @@ Altogether this means that we:
   By convention, we assume that a GitHub release coincides with a CRAN release.
   So this is the **primary mechanism for building the released pkgdown site**.
 
-`pkgdown::build_site_github_pages()` consults the version in DESCRIPTION to detect whether it's building from a released version or a dev version.
+`pkgdown::build_site_github_pages()` consults the version in DESCRIPTION to detect whether it is building from a released version or a dev version.
 That determines the `dest_dir`, e.g. `docs/` for released and `docs/dev/` for dev.
 For a package in automatic development mode, this means that almost all of your pushes trigger an update to the dev site.
 The released site is only updated when you push a state with a non-development version number or when you publish a GitHub release.
@@ -223,8 +223,8 @@ Files you must update:
 
 Other likely candidates:
 
--   `README.Rmd` + `README.md`, e.g., if you've updated badges.
--   Any documentation fixes that **apply to the released version**. This is the only reason to touch anything below `R/` and even then it should only affect roxygen comments. Don't forget to `document()` if you do this!
+-   `README.Rmd` + `README.md`, e.g., if you have updated badges.
+-   Any documentation fixes that **apply to the released version**. This is the only reason to touch anything below `R/` and even then it should only affect roxygen comments. Do not forget to `document()` if you do this!
 -   Any new vignettes or articles that apply to the released version.
 
 Here are some tips on backporting specific changes into this branch.
@@ -235,7 +235,7 @@ In that case, we can cherry pick such a commit by its SHA:
 git cherry-pick SHA
 ```
 
-If that doesn't cover everything, for each file you want to update, identify a Git reference (meaning: a SHA, tag, or branch) where the file is in the desired state.
+If that does not cover everything for each file you want to update, identify a Git reference (meaning: a SHA, tag, or branch) where the file is in the desired state.
 Checkout that specific file path from that specific ref:
 
 ```         
@@ -251,7 +251,7 @@ git checkout main -- vignettes/column-types.Rmd
 
 Commit and push this new branch to GitHub.
 `usethis::pr_push()` can be handy for this.
-Just don't bother opening a pull request (the branch will still be pushed).
+Just do not bother opening a pull request (the branch will still be pushed).
 
 Now we will use the `workflow_dispatch` GHA trigger:
 
@@ -262,7 +262,7 @@ Now we will use the `workflow_dispatch` GHA trigger:
 
 This should kick off a pkgdown build-and-deploy and, specifically, it should cause updates to the **released** site.
 
-You can keep this branch around for a while, in case you didn't get everything right the first time or if more things crop up that you'd like backport to the released site, before your next CRAN release.
+You can keep this branch around for a while, in case you did not get everything right the first time or if more things crop up that you'd like backport to the released site, before your next CRAN release.
 
 ## Problem-solving
 
diff --git a/vignettes/linking.Rmd b/vignettes/linking.Rmd
index 75bda28e7..3e559b1db 100644
--- a/vignettes/linking.Rmd
+++ b/vignettes/linking.Rmd
@@ -19,7 +19,7 @@ knitr::opts_chunk$set(
 
 ## Within a package
 
-pkgdown will automatically link to documentation and articles wherever it's possible to do unambiguously. This includes:
+pkgdown will automatically link to documentation and articles wherever it is possible to do unambiguously. This includes:
 
 * Bare function calls, like `build_site()`.
 * Calls to `?`, like `?build_site` or `package?pkgdown`.
@@ -51,7 +51,7 @@ If pkgdown can find a pkgdown site for the remote package, it will link to it; o
     url: https://dplyr.tidyverse.org
     ```
     
-    When this field is defined, pkgdown generate a public facing
+    When this field is defined, pkgdown generates a public facing
     [`pkgdown.yml` file](https://dplyr.tidyverse.org/pkgdown.yml) that provides
     metadata about the site:
     
diff --git a/vignettes/metadata.Rmd b/vignettes/metadata.Rmd
index 79c74ad15..edd8219e3 100644
--- a/vignettes/metadata.Rmd
+++ b/vignettes/metadata.Rmd
@@ -16,13 +16,13 @@ knitr::opts_chunk$set(
 )
 ```
 
-Package authors can customize the metadata used by Twitter and the [Open Graph protocol][ogp] for rich social media cards. In addition to specifying an alternate description for the package and any individual articles, you may also choose the preview image shown and the style of the card used on Twitter.
+Package authors can customize the metadata used by Twitter and the [Open Graph protocol][ogp] for rich social media cards. In addition to specifying an alternate description for the package and any individual articles, you may also choose the preview the image(s) shown and the style of the card used on Twitter.
 
 You can preview and validate the appearance of the social media cards with online tools:
 
-* [Google Rich Results Test][ogp-validator];
-* Drafting a tweet to yourself;
-* Sending yourself a Slack message.
+* [Google Rich Results Test][ogp-validator]
+* Drafting a tweet to yourself
+* Sending yourself a Slack message
 
 ## Necessary configuration
 
@@ -52,7 +52,7 @@ template:
       card: summary_large_image
 ```
 
-The `home: title` and `home: description` fields override the `Title` and `Description` fields in the package `DESCRIPTION`. It's good practice to set these fields to make your package documentation easier to find via search, rather than sticking with the title and description needed by CRAN.
+The `home: title` and `home: description` fields override the `Title` and `Description` fields in the package `DESCRIPTION`. It is good practice to set these fields to make your package documentation easier to find via search, rather than sticking with the title and description needed by CRAN.
 
 The `template: opengraph` section allows you to further customize the social media card.
 
@@ -78,7 +78,7 @@ The `template: opengraph` section allows you to further customize the social med
     * `site`: The Twitter handle of the organization affiliated with the
       package author or sponsoring the package development. 
       
-    * If only one of `creator` or `site` is included, the provided value will 
+    * If only one of either `creator` or `site` is included, the provided value will 
       be used for both fields.
     
     * `card`: The [style of social media card][twitter-card] that Twitter will 
diff --git a/vignettes/pkgdown.Rmd b/vignettes/pkgdown.Rmd
index 643dda46f..79e8d38d1 100644
--- a/vignettes/pkgdown.Rmd
+++ b/vignettes/pkgdown.Rmd
@@ -10,7 +10,7 @@ vignette: >
 ---
 
 The goal of pkgdown is to make it easy to make an elegant and useful package website with a minimum of work.
-You can get a basic website up and running in just a couple of minutes. If you're using GitHub, we recommend setting up pkgdown and GitHub actions to automatically build and publish your site:
+You can get a basic website up and running in just a couple of minutes. If you are using GitHub, we recommend setting up pkgdown and GitHub actions to automatically build and publish your site:
 
 ```{r, eval = FALSE}
 # Run this once to publish your site regularly
@@ -28,9 +28,9 @@ pkgdown::build_site()
 ```
 
 
-While you'll get a decent website without any additional work, if you want a website that really pops, you'll need to read the rest of this vignette.
+While you will get a decent website without any additional work, if you want a website that really pops, you will need to read the rest of this vignette.
 It starts by showing you how to configure pkgdown with a `_pkgdown.yml`.
-You'll learn about the main components of the site (the home page, reference, articles, and news), and then how to publish and promote your site.
+You will learn about the main components of the site (the home page, reference, articles, and news), and then how to publish and promote your site.
 
 ## Metadata
 
@@ -64,8 +64,8 @@ pkgdown's defaults work to ensure that your site is accessible to as many people
 ## Home page
 
 The contents of the home page are automatically generated from `index.md` or `README.md`.
-pkgdown tries them in order, so it's possible to have a different display on GitHub and pkgdown by providing both files.
-The homepage also includes a sidebar full of useful links; see `?build_home` for how these are generated and how you can customise them.
+pkgdown tries to put them in order, so it is possible to have a different display on GitHub and pkgdown by providing both files.
+The homepage also includes a sidebar full of useful links (see `?build_home` for how these are generated and how you can customise them).
 
 ## Reference
 
@@ -116,12 +116,12 @@ It just re-builds the index page, making it faster to quickly change `_pkgdown.y
 ## Articles
 
 pkgdown will automatically build all vignettes found in `vignettes/`, translating them to HTML files in `articles/`.
-It is recommended to name your intro article with your package name to generate a Get Started page automatically.
+It is recommended to name your intro article with your package name to generate a "Get Started" page automatically.
 
 Due to the way that pkgdown has to integrate R Markdown generated HTML with its own HTML, relatively little control is available over the output format.
 You can see the details in `?build_articles`.
 
-If you want to include an [article](https://r-pkgs.org/website.html#non-vignette-articles) on the website but not in the package (e.g., because it's large), you can use `usethis::use_article()` to set it up.
+If you want to include an [article](https://r-pkgs.org/website.html#non-vignette-articles) on the website but not in the package (e.g., because it is large), you can use `usethis::use_article()` to set it up.
 
 ## News
 
diff --git a/vignettes/translations.Rmd b/vignettes/translations.Rmd
index ee39f62de..43f030357 100644
--- a/vignettes/translations.Rmd
+++ b/vignettes/translations.Rmd
@@ -53,9 +53,9 @@ Next, install [potools](https://michaelchirico.github.io/potools/) and [usethis]
 install.packages(c("potools", "usethis"))
 ```
 
-You'll then need to familiarise yourself with the basics of [translations with potools](https://michaelchirico.github.io/potools/articles/translators.html) and [creating pull requests](https://usethis.r-lib.org/articles/pr-functions.html) with usethis.
+You will then need to familiarise yourself with the basics of [translations with potools](https://michaelchirico.github.io/potools/articles/translators.html) and [creating pull requests](https://usethis.r-lib.org/articles/pr-functions.html) with usethis.
 
-If you don't already know it, you'll need to look up the ISO 639-1 abbreviation for [your language](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes). In the examples below, I'll pretend I'm providing translations for Zulu, which has code `zu`.
+If you do not already know it, you will need to look up the ISO 639-1 abbreviation for [your language](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes). In the examples below, I will pretend I am providing translations for Zulu, which has code `zu`.
 
 Start by initialising a pull request:
 
@@ -81,7 +81,7 @@ devtools::load_all()
 build_site("~/path/to/your/site")
 ```
 
-Once you're happy with your work, make sure to compile the changes:
+Once you are happy with your work, make sure to compile the changes:
 
 ```{r}
 #| eval: false

From 06f8f234c4d6eb2ccc2fe15e4e067270fef42505 Mon Sep 17 00:00:00 2001
From: cathariv <cathariv@mskcc.org>
Date: Thu, 15 Aug 2024 16:40:51 -0400
Subject: [PATCH 2/2] undoing contraction changes.

---
 vignettes/customise.Rmd                   | 34 ++++++++++-----------
 vignettes/how-to-update-released-site.Rmd | 36 +++++++++++------------
 vignettes/linking.Rmd                     |  2 +-
 vignettes/metadata.Rmd                    |  4 +--
 vignettes/pkgdown.Rmd                     | 10 +++----
 vignettes/translations.Rmd                |  6 ++--
 6 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/vignettes/customise.Rmd b/vignettes/customise.Rmd
index 585f29515..095726b2b 100644
--- a/vignettes/customise.Rmd
+++ b/vignettes/customise.Rmd
@@ -89,8 +89,8 @@ You can find the correct height by running `$(".navbar").outerHeight()` in the [
 ### bslib variables
 
 Instead of picking a complete theme, you can tweak fonts and colours individually using bslib variables.
-[bslib](https://rstudio.github.io/bslib/) is an R package that wraps scss, the tool that Boostrap uses to produce CSS from a special language called [scss](https://sass-lang.com).
-The primary advantage of scss over CSS is that it is more programmable, so you can have a few key bslib variables that affect appearance of many HTML elements.
+[bslib](https://rstudio.github.io/bslib/) is an R package that wraps sass, the tool that Boostrap uses to produce CSS from a special language called [scss](https://sass-lang.com).
+The primary advantage of scss over CSS is that it's more programmable, so you can have a few key bslib variables that affect appearance of many HTML elements.
 
 There are three key variables that affect the colour:
 
@@ -112,7 +112,7 @@ For example, `table-border-color` defaults to `border-color` which defaults to `
 If you want to change the colour of all borders, you can set `border-color` and if you just want to change the colour of table borders, you can set `table-border-color`.
 You can find a full list of variables in the [bslib docs](https://rstudio.github.io/bslib/articles/bs5-variables/index.html).
 
-If you are using the light switch, [many colours](https://getbootstrap.com/docs/5.3/customize/color-modes/#sass-variables) are available for customisation specifically for the dark theme.
+If you're using the light switch, [many colours](https://getbootstrap.com/docs/5.3/customize/color-modes/#sass-variables) are available for customisation specifically for the dark theme.
 
 Theming with bslib is powered by `bslib::bs_theme()` and the `bslib` field is a direct translation of the arguments to that function.
 As a result, you can fully specify a bslib theme using the `template.bslib` field, making it easy to share YAML with the `output.html_document.theme` field [of an R Markdown document](https://rstudio.github.io/bslib/articles/theming/index.html).
@@ -142,7 +142,7 @@ template:
     code_font: {google: "JetBrains Mono"}
 ```
 
-If you want to use a non-Google font, you will need to do a bit more work. There are two steps: you need to first configure the font with CSS and then use it in your `_pkgdown.yml`. There are two ways you might get the CSS:
+If you want to use a non-Google font, you'll need to do a bit more work. There are two steps: you need to first configure the font with CSS and then use it in your `_pkgdown.yml`. There are two ways you might get the CSS:
 
 * As a block of CSS which you should put in `pkgdown/extra.scss` or `pkgdown/extra.css`. The CSS will look something like this:
 
@@ -178,9 +178,9 @@ template:
     base_font: proxima-nova
 ```
 
-Depending on where the font is from (and if you purchased it), you may need to take additional steps to ensure that it can only be used from your site, and/or make sure that it can still be used when you're previewing locally. If you are having problems getting a custom font to work, looking for errors in the [browser developer console](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools) is a good place to start.
+Depending on where the font is from (and if you purchased it), you may need to take additional steps to ensure that it can only be used from your site, and/or make sure that it can still be used when you're previewing locally. If you're having problems getting a custom font to work, looking for errors in the [browser developer console](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools) is a good place to start.
 
-When iterating on fonts, you will need to run `build_home_index(); init_site()` then refresh your browser to see the update.
+When iterating on fonts, you'll need to run `build_home_index(); init_site()` then refresh your browser to see the update.
 
 
 ### Syntax highlighting
@@ -243,12 +243,12 @@ navbar:
   bg: primary
 ```
 
-You generally don not need to set `bg` if you use a bootswatch theme, as pkgdown will pick the `bg` used on the [Bootstwatch preview](https://bootswatch.com/).
-Similarly, you do not usually need to set `type` because bootstrap will guess it for you.
+You generally don't need to set `bg` if you use a bootswatch theme, as pkgdown will pick the `bg` used on the [Bootstwatch preview](https://bootswatch.com/).
+Similarly, you don't usually need to set `type` because bootstrap will guess it for you.
 If the guess is wrong, you can override with `type: light` or `type: dark` depending on whether the background colour is light (so you need dark text) or `type: dark` if the background is dark (so you need light text).
-Unfortunately, these are defined relative to the page background, so if you have a dark site you will need to flip `light` and `dark` (a little experimentation should quickly determine what looks best).
+Unfortunately, these are defined relative to the page background, so if you have a dark site you'll need to flip `light` and `dark` (a little experimentation should quickly determine what looks best).
 
-Because the navbar is styled with HTML, you will need to `build_home_index(); init_site()` to see the effect of changing this parameter.
+Because the navbar is styled with HTML, you'll need to `build_home_index(); init_site()` to see the effect of changing this parameter.
 
 ## Layout {#layout}
 
@@ -259,7 +259,7 @@ They all use a similar structure that separately defines the overall `structure`
 ### Navbar {#navbar-heading}
 
 You can customise the navigation bar that appears at the top of the page with the `navbar` field.
-It is made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
+It's made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
 This organisation makes it easy to mix and match pkgdown defaults with your own customisations.
 
 This is the default structure:
@@ -282,7 +282,7 @@ It makes use of the the following built-in components:
 -   `github`: a link to the source repository (with an icon), if it can be automatically determined from the `DESCRIPTION`.
 -   `lightswitch`; a ["light switch"](#light-switch) to select light mode, dark mode, or auto mode.
 
-Note that customising `navbar` like this comes with a downside: if pkgdown later changes the defaults, you will have to update your `_pkgdown.yml`.
+Note that customising `navbar` like this comes with a downside: if pkgdown later changes the defaults, you'll have to update your `_pkgdown.yml`.
 
 [^dots]: Note that dots (`.`) in the package name need to be replaced by hyphens (`-`) in the vignette filename to be recognized as the intro. That means for a
     package `foo.bar` the intro needs to be named `foo-bar.Rmd`.
@@ -360,7 +360,7 @@ You can also customise the colour scheme of the navbar by using the `type` and `
 ### Footer
 
 You can customise the footer with the `footer` field.
-It is made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
+It's made up of two pieces: `structure`, which defines the overall layout, and `components`, which defines what each piece looks like.
 This organisation makes it easy to mix and match the pkgdown defaults with your own customisations.
 
 This is the default structure:
@@ -427,7 +427,7 @@ It can contain any of the following:
 -   A configuration file in `inst/pkgdown/_pkgdown.yml`. This can be used to set (e.g.) author definitions, Bootstrap version and variables, the sidebar, footer, navbar, etc.
 -   Templates in `inst/pkgdown/templates/` will override the default templates.
 -   Assets in `inst/pkgdown/assets/` will be copied in to the destination directory.
-    (Note these files are only copied; you will need to reference them in your stylesheet or elsewhere in order for them to be actually used.)
+    (Note these files are only copied; you'll need to reference them in your stylesheet or elsewhere in order for them to be actually used.)
 -   `inst/pkgdown/extra.scss` will be added to the bslib ruleset.
     (Note that `extra.css` is not supported in templates.)
 
@@ -440,7 +440,7 @@ template:
   package: theverybest
 ```
 
-You then also need to make sure it is available when your site is built. Typically, you will not want to publish this package to CRAN, but you will want to publish to GitHub. Once you have done that, and assuming you are using the [usethis workflow](https://usethis.r-lib.org/reference/use_pkgdown.html), add the following line to your `DESCRIPTION`:
+You then also need to make sure it's available when your site is built. Typically, you won't want to publish this package to CRAN, but you will want to publish to GitHub. Once you've done that, and assuming you're using the [usethis workflow](https://usethis.r-lib.org/reference/use_pkgdown.html), add the following line to your `DESCRIPTION`:
 
 ```yaml
 Config/Needs/website: myorg/theverybest
@@ -454,11 +454,11 @@ To get some sense of how a theming package works, you can look at:
 -   [quillt](https://pkgs.rstudio.com/quillt) used for R Markdown packages;
 -   [rotemplate](https://github.com/ropensci-org/rotemplate) used for rOpenSci packages.
 
-But please note that these templates are not suitable for use with your own package as they are all designed to give a common visual identity to a specific family of packages.
+But please note that these templates aren't suitable for use with your own package as they're all designed to give a common visual identity to a specific family of packages.
 
 ### Porting a template package
 
-If you are updating a template package that works with pkgdown 1.0.0, create directories `inst/pkgdown/BS5/templates` and `inst/pkgdown/BS5/assets` (if you do not have any templates/assets make sure to a add dummy file to ensure that git tracks them).
+If you are updating a template package that works with pkgdown 1.0.0, create directories `inst/pkgdown/BS5/templates` and `inst/pkgdown/BS5/assets` (if you don't have any templates/assets make sure to a add dummy file to ensure that git tracks them).
 The `templates` and `assets` directories directly under `inst/pkgdown` will be used by pkgdown 1.0.0 and by pkgdown 2.0.0 if `boostrap: 3`.
 The directories under `inst/pkgdown/BS5/` will be used for pkgdown 2.0.0 with `boostrap: 5`.
 This lets your package support both versions of Bootstrap and pkgdown.
diff --git a/vignettes/how-to-update-released-site.Rmd b/vignettes/how-to-update-released-site.Rmd
index 410c1fd3e..353d25de9 100644
--- a/vignettes/how-to-update-released-site.Rmd
+++ b/vignettes/how-to-update-released-site.Rmd
@@ -20,29 +20,29 @@ knitr::opts_chunk$set(
 
 This vignette shows you how to update the released version of your site to match the dev version of the site, so the first step is to ensure that the dev site looks the way that you want it.
 
-This site assumes that you are using a recent version of our recommended [pkgdown action](https://github.com/r-lib/actions/blob/HEAD/examples/pkgdown.yaml). If your workflow does not contain `workflow_dispatch`, you will need to update `.github/actions/pkgdown.yaml` by running `use_github_action("pkgdown")`.
+This site assumes that you're using a recent version of our recommended [pkgdown action](https://github.com/r-lib/actions/blob/HEAD/examples/pkgdown.yaml). If your workflow does not contain `workflow_dispatch`, you will need to update `.github/actions/pkgdown.yaml` by running `use_github_action("pkgdown")`.
 
 ## Process
 
-If you are up to speed with the basic idea and just want some code to follow, here it is.
+If you're up to speed with the basic idea and just want some code to follow, here it is.
 Otherwise, read more below.
 
 ### Setup
 
-First, make sure you are in the `main` branch, and you have the latest version:
+First, make sure you're in the `main` branch, and you have the latest version:
 
 ```{r}
 gert::git_branch_checkout("main")
 gert::git_pull()
 ```
 
-Next figure out the released version that you are updating:
+Next figure out the released version that you're updating:
 
 ```{r}
 ver <- desc::desc_get_version()[1, 1:3]
 ```
 
-You will use this to create and checkout the branch that you will work in:
+You will use this to create and checkout the branch that you'll work in:
 
 ```{r}
 gert::git_branch_create(paste0("pkgdown-v", ver), paste0("v", ver))
@@ -70,7 +70,7 @@ files <- c(
 glue::glue("git checkout v{ver} -- {files}")
 ```
 
-If you backport `DESCRIPTION`, you will also need undo the change to the `Version`:
+If you backport `DESCRIPTION`, you'll also need undo the change to the `Version`:
 
 ```{r}
 desc::desc_set_version(ver)
@@ -97,7 +97,7 @@ Then trigger the pkgdown workflow:
 2.  Select the pkgdown workflow.
 3.  Click *Run workflow* and select the branch you just pushed.
 
-If there is no dropdown menu for this, that means your pkgdown workflow config is not current.
+If there's no dropdown menu for this, that means your pkgdown workflow config is not current.
 
 ## Context
 
@@ -124,7 +124,7 @@ This directs pkgdown to "generate different sites for the development and releas
 The readr package demonstrates what happens in automatic development mode:
 
 [readr.tidyverse.org](https://readr.tidyverse.org) documents the released version, i.e. what `install.packages()` will deliver.\
-[readr.tidyverse.org/dev/](https://readr.tidyverse.org/dev/) documents the dev version, i.e. what you would get by installing from GitHub.
+[readr.tidyverse.org/dev/](https://readr.tidyverse.org/dev/) documents the dev version, i.e. what you'd get by installing from GitHub.
 
 In this mode, `pkgdown::build_site()`, consults DESCRIPTION to learn the package's version number.
 For a development version number, the rendered site is written to `docs/dev/`.
@@ -135,9 +135,9 @@ Automatic development mode is recommended for packages with a broad user base be
 
 ### Publishing
 
-Now that we have established the meaning of a released (vs dev) site, we have to consider how the site is built (i.e. how the HTML is generated) and deployed (i.e. how the HTML is published to a website so people can see it.).
+Now that we've established the meaning of a released (vs dev) site, we have to consider how the site is built (i.e. how the HTML is generated) and deployed (i.e. how the HTML is published to a website so people can see it.).
 
-We recommend `usethis::use_pkgdown_github_pages()` to do basic pkgdown setup and configure a GitHub Actions (GHA) workflow to automatically render and publish the site to GitHub Pages. This function is bascially a shortcut for calling the following functions individually: 
+We recommend `usethis::use_pkgdown_github_pages()` to do basic pkgdown setup and configure a GitHub Actions (GHA) workflow to automatically render and publish the site to GitHub Pages. This function is basically a shortcut for calling the following functions individually: 
 
 * `use_pkgdown()`
 * `use_github_pages()`
@@ -176,8 +176,8 @@ Altogether this means that we:
 
 * Build and deploy for pushes to `main`.
 
-* Build, but do not deploy, for pull requests against `main`.
-  This reveals any pkgdown errors, but ensures the live site is not
+* Build, but don't deploy, for pull requests against `main`.
+  This reveals any pkgdown errors, but ensures the live site isn't
   updated until the pull request is merged (because the code is 
   pushed to `main`).
 
@@ -185,7 +185,7 @@ Altogether this means that we:
   By convention, we assume that a GitHub release coincides with a CRAN release.
   So this is the **primary mechanism for building the released pkgdown site**.
 
-`pkgdown::build_site_github_pages()` consults the version in DESCRIPTION to detect whether it is building from a released version or a dev version.
+`pkgdown::build_site_github_pages()` consults the version in DESCRIPTION to detect whether it's building from a released version or a dev version.
 That determines the `dest_dir`, e.g. `docs/` for released and `docs/dev/` for dev.
 For a package in automatic development mode, this means that almost all of your pushes trigger an update to the dev site.
 The released site is only updated when you push a state with a non-development version number or when you publish a GitHub release.
@@ -223,8 +223,8 @@ Files you must update:
 
 Other likely candidates:
 
--   `README.Rmd` + `README.md`, e.g., if you have updated badges.
--   Any documentation fixes that **apply to the released version**. This is the only reason to touch anything below `R/` and even then it should only affect roxygen comments. Do not forget to `document()` if you do this!
+-   `README.Rmd` + `README.md`, e.g., if you've updated badges.
+-   Any documentation fixes that **apply to the released version**. This is the only reason to touch anything below `R/` and even then it should only affect roxygen comments. Don't forget to `document()` if you do this!
 -   Any new vignettes or articles that apply to the released version.
 
 Here are some tips on backporting specific changes into this branch.
@@ -235,7 +235,7 @@ In that case, we can cherry pick such a commit by its SHA:
 git cherry-pick SHA
 ```
 
-If that does not cover everything for each file you want to update, identify a Git reference (meaning: a SHA, tag, or branch) where the file is in the desired state.
+If that doesn't cover everything for each file you want to update, identify a Git reference (meaning: a SHA, tag, or branch) where the file is in the desired state.
 Checkout that specific file path from that specific ref:
 
 ```         
@@ -251,7 +251,7 @@ git checkout main -- vignettes/column-types.Rmd
 
 Commit and push this new branch to GitHub.
 `usethis::pr_push()` can be handy for this.
-Just do not bother opening a pull request (the branch will still be pushed).
+Just don't bother opening a pull request (the branch will still be pushed).
 
 Now we will use the `workflow_dispatch` GHA trigger:
 
@@ -262,7 +262,7 @@ Now we will use the `workflow_dispatch` GHA trigger:
 
 This should kick off a pkgdown build-and-deploy and, specifically, it should cause updates to the **released** site.
 
-You can keep this branch around for a while, in case you did not get everything right the first time or if more things crop up that you'd like backport to the released site, before your next CRAN release.
+You can keep this branch around for a while, in case you didn't get everything right the first time or if more things crop up that you'd like backport to the released site, before your next CRAN release.
 
 ## Problem-solving
 
diff --git a/vignettes/linking.Rmd b/vignettes/linking.Rmd
index 3e559b1db..2c5d54479 100644
--- a/vignettes/linking.Rmd
+++ b/vignettes/linking.Rmd
@@ -19,7 +19,7 @@ knitr::opts_chunk$set(
 
 ## Within a package
 
-pkgdown will automatically link to documentation and articles wherever it is possible to do unambiguously. This includes:
+pkgdown will automatically link to documentation and articles wherever it's possible to do unambiguously. This includes:
 
 * Bare function calls, like `build_site()`.
 * Calls to `?`, like `?build_site` or `package?pkgdown`.
diff --git a/vignettes/metadata.Rmd b/vignettes/metadata.Rmd
index edd8219e3..09edc6c80 100644
--- a/vignettes/metadata.Rmd
+++ b/vignettes/metadata.Rmd
@@ -16,7 +16,7 @@ knitr::opts_chunk$set(
 )
 ```
 
-Package authors can customize the metadata used by Twitter and the [Open Graph protocol][ogp] for rich social media cards. In addition to specifying an alternate description for the package and any individual articles, you may also choose the preview the image(s) shown and the style of the card used on Twitter.
+Package authors can customize the metadata used by Twitter and the [Open Graph protocol][ogp] for rich social media cards. In addition to specifying an alternate description for the package and any individual articles, you may also choose the preview image shown and the style of the card used on Twitter.
 
 You can preview and validate the appearance of the social media cards with online tools:
 
@@ -52,7 +52,7 @@ template:
       card: summary_large_image
 ```
 
-The `home: title` and `home: description` fields override the `Title` and `Description` fields in the package `DESCRIPTION`. It is good practice to set these fields to make your package documentation easier to find via search, rather than sticking with the title and description needed by CRAN.
+The `home: title` and `home: description` fields override the `Title` and `Description` fields in the package `DESCRIPTION`. It's good practice to set these fields to make your package documentation easier to find via search, rather than sticking with the title and description needed by CRAN.
 
 The `template: opengraph` section allows you to further customize the social media card.
 
diff --git a/vignettes/pkgdown.Rmd b/vignettes/pkgdown.Rmd
index 79e8d38d1..22af5467d 100644
--- a/vignettes/pkgdown.Rmd
+++ b/vignettes/pkgdown.Rmd
@@ -10,7 +10,7 @@ vignette: >
 ---
 
 The goal of pkgdown is to make it easy to make an elegant and useful package website with a minimum of work.
-You can get a basic website up and running in just a couple of minutes. If you are using GitHub, we recommend setting up pkgdown and GitHub actions to automatically build and publish your site:
+You can get a basic website up and running in just a couple of minutes. If you're using GitHub, we recommend setting up pkgdown and GitHub actions to automatically build and publish your site:
 
 ```{r, eval = FALSE}
 # Run this once to publish your site regularly
@@ -28,9 +28,9 @@ pkgdown::build_site()
 ```
 
 
-While you will get a decent website without any additional work, if you want a website that really pops, you will need to read the rest of this vignette.
+While you'll get a decent website without any additional work, if you want a website that really pops, you'll need to read the rest of this vignette.
 It starts by showing you how to configure pkgdown with a `_pkgdown.yml`.
-You will learn about the main components of the site (the home page, reference, articles, and news), and then how to publish and promote your site.
+You'll learn about the main components of the site (the home page, reference, articles, and news), and then how to publish and promote your site.
 
 ## Metadata
 
@@ -64,7 +64,7 @@ pkgdown's defaults work to ensure that your site is accessible to as many people
 ## Home page
 
 The contents of the home page are automatically generated from `index.md` or `README.md`.
-pkgdown tries to put them in order, so it is possible to have a different display on GitHub and pkgdown by providing both files.
+pkgdown tries to put them in order, so it's possible to have a different display on GitHub and pkgdown by providing both files.
 The homepage also includes a sidebar full of useful links (see `?build_home` for how these are generated and how you can customise them).
 
 ## Reference
@@ -121,7 +121,7 @@ It is recommended to name your intro article with your package name to generate
 Due to the way that pkgdown has to integrate R Markdown generated HTML with its own HTML, relatively little control is available over the output format.
 You can see the details in `?build_articles`.
 
-If you want to include an [article](https://r-pkgs.org/website.html#non-vignette-articles) on the website but not in the package (e.g., because it is large), you can use `usethis::use_article()` to set it up.
+If you want to include an [article](https://r-pkgs.org/website.html#non-vignette-articles) on the website but not in the package (e.g., because it's large), you can use `usethis::use_article()` to set it up.
 
 ## News
 
diff --git a/vignettes/translations.Rmd b/vignettes/translations.Rmd
index 43f030357..ee39f62de 100644
--- a/vignettes/translations.Rmd
+++ b/vignettes/translations.Rmd
@@ -53,9 +53,9 @@ Next, install [potools](https://michaelchirico.github.io/potools/) and [usethis]
 install.packages(c("potools", "usethis"))
 ```
 
-You will then need to familiarise yourself with the basics of [translations with potools](https://michaelchirico.github.io/potools/articles/translators.html) and [creating pull requests](https://usethis.r-lib.org/articles/pr-functions.html) with usethis.
+You'll then need to familiarise yourself with the basics of [translations with potools](https://michaelchirico.github.io/potools/articles/translators.html) and [creating pull requests](https://usethis.r-lib.org/articles/pr-functions.html) with usethis.
 
-If you do not already know it, you will need to look up the ISO 639-1 abbreviation for [your language](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes). In the examples below, I will pretend I am providing translations for Zulu, which has code `zu`.
+If you don't already know it, you'll need to look up the ISO 639-1 abbreviation for [your language](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes). In the examples below, I'll pretend I'm providing translations for Zulu, which has code `zu`.
 
 Start by initialising a pull request:
 
@@ -81,7 +81,7 @@ devtools::load_all()
 build_site("~/path/to/your/site")
 ```
 
-Once you are happy with your work, make sure to compile the changes:
+Once you're happy with your work, make sure to compile the changes:
 
 ```{r}
 #| eval: false