allow -> enable in the docs, per our guidelines.

docs/source/developer/css.rst

@@ -16,7 +16,7 @@ CSS checklist
 -  The JupyterLab default CSS variables in the ``theme-light-extension``
    and ``theme-dark-extension`` packages are used to style packages
    where ever possible. Individual packages should not npm-depend on
-   these packages though, to allow the theme to be swapped out.
+   these packages though, to enable the theme to be swapped out.
 -  Additional public/private CSS variables are defined by plugins
    sparingly and in accordance with the conventions described below.
 
@@ -147,7 +147,7 @@ CSS class name that gives a semantic naming of the component, such as:
 In general, the parent ``MyWidget`` should add these classes to the
 children. This applies when the children are plain DOM nodes or
 ``Widget`` instances/subclasses themselves. Thus, the general naming of
-CSS classes is of the form ``jp-WidgetName-semanticChild``. This allows
+CSS classes is of the form ``jp-WidgetName-semanticChild``. This enables
 the styling of these children in a manner that is independent of the
 children implementation or CSS classes they have themselves.
 

docs/source/developer/documents.rst

@@ -59,7 +59,7 @@ fetch the model (e.g. text, base64, notebook).
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Adds additional functionality to a widget type. An extension instance is
-created for each widget instance, allowing the extension to add
+created for each widget instance, enabling the extension to add
 functionality to each widget or observe the widget and/or its context.
 
 *Examples*

docs/source/developer/extension_dev.rst

@@ -97,9 +97,9 @@ as patterns and objects for writing clean, well-abstracted code. The
 widgets in the application are primarily **Phosphor widgets**, and
 Phosphor concepts, like message passing and signals, are used
 throughout. **Phosphor messages** are a *many-to-one* interaction that
-allows information like resize events to flow through the widget
+enables information like resize events to flow through the widget
 hierarchy in the application. **Phosphor signals** are a *one-to-many*
-interaction that allow listeners to react to changes in an observed
+interaction that enable listeners to react to changes in an observed
 object.
 
 Extension Authoring
@@ -300,7 +300,7 @@ Storing Extension Data
 In addition to the file system that is accessed by using the
 ``@jupyterlab/services`` package, JupyterLab offers two ways for
 extensions to store data: a client-side state database that is built on
-top of ``localStorage`` and a plugin settings system that allows for
+top of ``localStorage`` and a plugin settings system that provides for
 default setting values and user overrides.
 
 State Database

docs/source/developer/patterns.rst

@@ -17,7 +17,7 @@ Initialization Options
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Objects will typically have an ``IOptions`` interface for initializing
-the widget. The use of this interface allows options to be later added
+the widget. The use of this interface enables options to be later added
 while preserving backward compatibility.
 
 ContentFactory Option
@@ -44,7 +44,7 @@ The "Private" module namespace is used to group variables and functions
 that are not intended to be exported and may have otherwise existed as
 module-level variables and functions. The use of the namespace also
 makes it clear when a variable access is to an imported name or from the
-module itself. Finally, the namespace allows the entire section to be
+module itself. Finally, the namespace enables the entire section to be
 collapsed in an editor if desired.
 
 Disposables
@@ -81,11 +81,11 @@ Signals are intended for one-to-many communication where outside objects
 react to changes on another object. Signals are always emitted with the
 sender as the first argument, and contain a single second argument with
 the payload. Signals should generally not be used to trigger the
-"default" behavior for an action, but to allow others to trigger
+"default" behavior for an action, but to enable others to trigger
 additional behavior. If a "default" behavior is intended to be provided
 by another object, then a callback should be provided by that object.
 Wherever possible as signal connection should be made with the pattern
-``.connect(this._onFoo, this)``. Providing the ``this`` context allows
+``.connect(this._onFoo, this)``. Providing the ``this`` context enables
 the connection to be properly cleared by ``clearSignalData(this)``.
 Using a private method avoids allocating a closure for each connection.
 
@@ -96,8 +96,8 @@ Some of the more advanced widgets have a model associated with them. The
 common pattern used is that the model is settable and must be set
 outside of the constructor. This means that any consumer of the widget
 must account for a model that may be ``null``, and may change at any
-time. The widget should emit a ``modelChanged`` signal to allow
-consumers to handle a change in model. The reason to allow a model to
+time. The widget should emit a ``modelChanged`` signal to enable
+consumers to handle a change in model. The reason to enable a model to
 swap is that the same widget could be used to display different model
 content while preserving the widget's location in the application. The
 reason the model cannot be provided in the constructor is the

docs/source/getting_started/overview.rst

@@ -19,12 +19,12 @@ addition, it enables other models of interactive computing, such as:
 
 -  :ref:`code_console` provide transient scratchpads for running code
    interactively, with full support for rich output.
--  :ref:`Kernel-backed documents <kernel-backed-documents>` allow code in any text file (Markdown,
+-  :ref:`Kernel-backed documents <kernel-backed-documents>` enable code in any text file (Markdown,
    Python, R, LaTeX, etc.) to be run interactively in any Jupyter
    kernel.
 
 JupyterLab also offers a unified model for viewing and handling data
-formats. This allows data in many formats (images, CSV, JSON, Markdown,
+formats. This enables data in many formats (images, CSV, JSON, Markdown,
 PDF, Vega, Vega-Lite, etc.) to be opened as a file or returned by a
 kernel as rich output. See :ref:`file-and-output-formats` for more
 information.

docs/source/user/code_console.rst

@@ -3,7 +3,7 @@
 Code Consoles
 -------------
 
-Code consoles allow you to run code interactively in a kernel. The cells
+Code consoles enable you to run code interactively in a kernel. The cells
 of a code console show the order in which code was executed in the
 kernel, as opposed to the explicit ordering of cells in a notebook
 document. Code consoles also display rich output, just like notebook

docs/source/user/documents_kernels.rst

@@ -5,7 +5,7 @@ Documents and kernels
 
 In the Jupyter architecture, kernels are separate processes started by
 the server that run your code in different programming languages and
-environments. JupyterLab allows you to connect any open text file to a
+environments. JupyterLab enables you to connect any open text file to a
 :ref:`code console and kernel <code_console>`. This means you can easily run code from the
 text file in the kernel interactively.
 

docs/source/user/extensions.rst

@@ -175,7 +175,7 @@ page_config.json
 The ``page_config.json`` data is used to provide config data to the
 application environment.
 
-Two important fields in the ``page_config.json`` file allow control of
+Two important fields in the ``page_config.json`` file enable control of
 which plugins load:
 
 1. ``disabledExtensions`` for extensions that should not load at all.

docs/source/user/file_formats.rst

@@ -191,7 +191,7 @@ Vega-Lite:
 -  File extensions: ``.vl``, ``.vl.json``
 -  MIME type: ``application/vnd.vegalite.v1+json``
 
-Vega and Vega-Lite are declarative visualization grammars that allow
+Vega and Vega-Lite are declarative visualization grammars that enable
 visualizations to be encoded as JSON data. For more information, see the
 documentation of Vega or Vega-Lite. JupyterLab supports rendering Vega
 2.x and Vega-Lite 1.x data in files and cell output.
@@ -215,7 +215,7 @@ the “Open With…” submenu in the file browser content menu:
   </div>
 
 As with other files in JupyterLab, multiple views of a single file
-remain synchronized, allowing you to interactively edit and render
+remain synchronized, enabling you to interactively edit and render
 Vega/Vega-Lite visualizations:
 
 .. raw:: html

docs/source/user/files.rst

@@ -6,7 +6,7 @@ Working with Files
 Opening Files
 ~~~~~~~~~~~~~
 
-The file browser and File menu allow you to work with files and
+The file browser and File menu enable you to work with files and
 directories on your system. This includes opening, creating, deleting,
 renaming, downloading, copying, and sharing files and directories.
 
@@ -80,8 +80,8 @@ Creating Files and Activities
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Create new files or activities by clicking the ``+`` button at the top
-of the file browser. This will open a new Launcher tab in the main area,
-which allows you to pick an activity and kernel:
+of the file browser. This will open a new Launcher tab in the main work area,
+which enables you to pick an activity and kernel:
 
 .. raw:: html
 

docs/source/user/running.rst

@@ -13,8 +13,8 @@ directories:
 
 As with the classic Jupyter Notebook, when you close a notebook
 document, code console, or terminal, the underlying kernel or terminal
-running on the server continues to run. This allows you to perform
-long-running actions and return later. The Running tab allows you to
+running on the server continues to run. This enables you to perform
+long-running actions and return later. The Running tab enables you to
 re-open or focus the document linked to a given kernel or terminal:
 
 .. raw:: html