Docs: Change wording from "this document" to "this page" for Bazel site pages
PiperOrigin-RevId: 352115854
diff --git a/site/docs/android-build-performance.md b/site/docs/android-build-performance.md
index f5887b4..500a2ef 100644
--- a/site/docs/android-build-performance.md
+++ b/site/docs/android-build-performance.md
@@ -5,7 +5,7 @@
# Android Build Performance
-This document contains information on optimizing build performance for Android
+This page contains information on optimizing build performance for Android
apps specifically. For general build performance optimization with Bazel, see
[Optimizing Performance](skylark/performance.html).
diff --git a/site/docs/android-instrumentation-test.md b/site/docs/android-instrumentation-test.md
index eb6e88e..f8c6885 100644
--- a/site/docs/android-instrumentation-test.md
+++ b/site/docs/android-instrumentation-test.md
@@ -218,7 +218,7 @@
we recommend using a Maven resolver like
[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external).
-For the rest of this documentation, we will be using `rules_jvm_external` to
+The rest of this page shows how to use `rules_jvm_external` to
resolve and fetch dependencies from Maven repositories.
# Choosing an android_device target
diff --git a/site/docs/best-practices.md b/site/docs/best-practices.md
index 4d7b3c9..9828143 100644
--- a/site/docs/best-practices.md
+++ b/site/docs/best-practices.md
@@ -20,7 +20,7 @@
program that produces no errors with strict checking." However, incorporating as many of these
principles as possible should make a project more readable, less error-prone, and faster to build.
-This document uses the requirement levels described in
+This page uses the requirement levels described in
[this RFC](https://www.ietf.org/rfc/rfc2119.txt).
## Running builds and tests
diff --git a/site/docs/build-event-protocol.md b/site/docs/build-event-protocol.md
index dec812b..3ece3d2 100644
--- a/site/docs/build-event-protocol.md
+++ b/site/docs/build-event-protocol.md
@@ -54,9 +54,7 @@
## Build Event Protocol example
The full specification of the Build Event Protocol can be found in its protocol
-buffer definition and describing it here is beyond the scope of this document.
-However, it might be helpful to build up some intuition before looking at the
-specification.
+buffer definition. However, it might be helpful to build up some intuition before looking at the specification.
Consider a simple Bazel workspace that consists of two empty shell scripts
`foo.sh` and `foo_test.sh` and the following BUILD file:
diff --git a/site/docs/build-ref.html b/site/docs/build-ref.html
index 862b6f5..3eba968 100644
--- a/site/docs/build-ref.html
+++ b/site/docs/build-ref.html
@@ -4,7 +4,7 @@
---
<h1>Concepts and Terminology</h1>
<p>
- This document provides an overview of the source tree layout and the
+ This page provides an overview of the source tree layout and the
terminology used in Bazel.
</p>
<h2 id="intro">Introduction</h2>
diff --git a/site/docs/cc-toolchain-config-reference.md b/site/docs/cc-toolchain-config-reference.md
index fdc6c7c..c28b0c3 100644
--- a/site/docs/cc-toolchain-config-reference.md
+++ b/site/docs/cc-toolchain-config-reference.md
@@ -91,8 +91,8 @@
Once a toolchain has been selected, corresponding `feature` and `action_config`
objects in the Starlark rule govern the configuration of the build (that is,
-items described later in this document). These messages allow the
-implementation of fully fledged C++ features in Bazel without modifying the
+items described later). These messages allow the implementation of
+fully fledged C++ features in Bazel without modifying the
Bazel binary. C++ rules support multiple unique actions documented in detail
[in the Bazel source code](https://source.bazel.build/bazel/+/4f547a7ea86df80e4c76145ffdbb0c8b75ba3afa:tools/build_defs/cc/action_names.bzl).
@@ -459,7 +459,7 @@
its tool path and execution requirements to the Bazel action. A tool is selected
by iterating through the `tools` attribute on an `action_config` until a tool
with a `with_feature` set matching the feature configuration is found
-(see [Feature relationships](#feature-relationships) earlier in this document
+(see [Feature relationships](#feature-relationships) earlier on this page
for more information). We recommend that you end your tool lists with a default
tool that corresponds to an empty feature configuration.
diff --git a/site/docs/remote-execution-ci.md b/site/docs/remote-execution-ci.md
index fda95e4..42221a3 100644
--- a/site/docs/remote-execution-ci.md
+++ b/site/docs/remote-execution-ci.md
@@ -13,7 +13,7 @@
## Prerequisites
-Before completing the steps in this document, ensure the following:
+Before completing the steps on this page, ensure the following:
* Your GitHub repository is part of the
[Bazel GitHub organization](https://github.com/bazelbuild).
@@ -70,7 +70,7 @@
your rules require tools not present in the default container, you must
create a custom container based on the
[`rbe-ubuntu16-04`](https://console.cloud.google.com/marketplace/details/google/rbe-ubuntu16-04)
- container and include those tools as described later in this document.
+ container and include those tools as described later.
* **Build or test targets are using rules that are incompatible with remote
execution.** See
@@ -185,7 +185,7 @@
````
4. Take note of the SHA256 checksum of your custom container. You will need to
- provide it in your build platform definition later in this document.
+ provide it in your build platform definition later.
5. Configure the container for public access as described in publicly
accessible as explained in
diff --git a/site/docs/test-encyclopedia.html b/site/docs/test-encyclopedia.html
index f2200a5..46d913a 100644
--- a/site/docs/test-encyclopedia.html
+++ b/site/docs/test-encyclopedia.html
@@ -26,7 +26,7 @@
<h2>Objective</h2>
-<p>The goal of this document is to formally establish the runtime environment
+<p>The goal of this page is to formally establish the runtime environment
for and expected behavior of Bazel tests. It will also impose requirements on
the test runner and the build system.
@@ -36,20 +36,20 @@
holes which currently allow many tests to pass despite not being
properly hermetic, deterministic, and reentrant.</p>
-<p>This document is intended to be both normative and authoritative. If
+<p>This page is intended to be both normative and authoritative. If
this specification and the implemented behavior of test runner disagree, the
specification takes precedence.</p>
<h2>Proposed Specification</h2>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in IETF RFC 2119.</p>
<h2>Purpose of tests</h2>
<p>The purpose of Bazel tests is to confirm some property of the source files
-checked into the repository. (In this document, "source files" includes test data,
+checked into the repository. (On this page, "source files" includes test data,
golden outputs, and anything else kept under version control.) One
user writes a test to assert an invariant which they expect to be maintained.
Other users execute the test later to check whether the invariant has been
