UG: Variable table -> Variable section

pekkaklarck · pekkaklarck · commit 5c2b0f5cbf4e · 2021-03-04T00:22:33.000+02:00
diff --git a/doc/userguide/src/CreatingTestData/ResourceAndVariableFiles.rst b/doc/userguide/src/CreatingTestData/ResourceAndVariableFiles.rst
@@ -12,7 +12,7 @@ as well. The main difference is that resource files cannot have tests.
 variables. For example, they allow values other than strings and
 enable creating variables dynamically. Their flexibility comes from
 the fact that they are created using Python code, which also makes
-them somewhat more complicated than `Variable tables`_.
+them somewhat more complicated than `Variable sections`_.
 
 .. contents::
    :depth: 2
@@ -127,7 +127,7 @@ Variable files
 --------------
 
 Variable files contain variables_ that can be used in the test
-data. Variables can also be created using variable tables or set from
+data. Variables can also be created using Variable sections or set from
 the command line, but variable files allow creating them dynamically
 and also make it easy to create other variable values than strings.
 
@@ -301,7 +301,7 @@ Using objects as values
 '''''''''''''''''''''''
 
 Variables in variable files are not limited to having only strings or
-other base types as values like variable tables. Instead, their
+other base types as values like Variable sections. Instead, their
 variables can contain any objects. In the example below, the variable
 `${MAPPING}` contains a Java Hashtable with two values (this
 example works only when running tests on Jython).
@@ -585,8 +585,8 @@ from the command line using :option:`--variablefile` option, in the settings
 table using :setting:`Variables` setting, and dynamically using the
 :name:`Import Variables` keyword.
 
-If the above YAML file is imported, it will create exactly the same
-variables as the following variable table:
+If the above YAML file is imported, it will create exactly the same variables
+as this Variable section:
 
 .. sourcecode:: robotframework
 
@@ -603,7 +603,7 @@ types supported by YAML syntax. If names or values contain non-ASCII
 characters, YAML variables files must be UTF-8 encoded.
 
 Mappings used as values are automatically converted to special dictionaries
-that are used also when `creating dictionary variables`_ in the variable table.
+that are used also when `creating dictionary variables`_ in the Variable section.
 Most importantly, values of these dictionaries are accessible as attributes
 like `${DICT.one}`, assuming their names are valid as Python attribute names.
 If the name contains spaces or is otherwise not a valid attribute name, it is
diff --git a/doc/userguide/src/CreatingTestData/Variables.rst b/doc/userguide/src/CreatingTestData/Variables.rst
@@ -472,11 +472,13 @@ Creating variables
 
 Variables can spring into existence from different sources.
 
-Variable table
-~~~~~~~~~~~~~~
+.. _Variable sections:
 
-The most common source for variables are Variable tables in `test case
-files`_ and `resource files`_. Variable tables are convenient, because they
+Variable section
+~~~~~~~~~~~~~~~~
+
+The most common source for variables are Variable sections in `test case
+files`_ and `resource files`_. Variable sections are convenient, because they
 allow creating variables in the same place as the rest of the test
 data, and the needed syntax is very simple. Their main disadvantages are
 that values are always strings and they cannot be created dynamically.
@@ -487,7 +489,7 @@ Creating scalar variables
 
 The simplest possible variable assignment is setting a string into a
 scalar variable. This is done by giving the variable name (including
-`${}`) in the first column of the Variable table and the value in
+`${}`) in the first column of the Variable section and the value in
 the second one. If the second column is empty, an empty string is set
 as a value. Also an already defined variable can be used in the value.
 
@@ -525,7 +527,7 @@ Creating list variables
 '''''''''''''''''''''''
 
 Creating list variables is as easy as creating scalar variables. Again, the
-variable name is in the first column of the Variable table and
+variable name is in the first column of the Variable section and
 values in the subsequent columns. A list variable can have any number
 of values, starting from zero, and if many values are needed, they
 can be `split into several rows`__.
@@ -544,7 +546,7 @@ __ `Dividing data to several rows`_
 Creating dictionary variables
 '''''''''''''''''''''''''''''
 
-Dictionary variables can be created in the variable table similarly as
+Dictionary variables can be created in the Variable section similarly as
 list variables. The difference is that items need to be created using
 `name=value` syntax or existing dictionary variables. If there are multiple
 items with same name, the last value has precedence. If a name contains
@@ -598,7 +600,7 @@ Variables can be set from the command line either individually with
 the :option:`--variable (-v)` option or using a variable file with the
 :option:`--variablefile (-V)` option. Variables set from the command line
 are globally available for all executed test data files, and they also
-override possible variables with the same names in the Variable table and in
+override possible variables with the same names in the Variable section and in
 variable files imported in the test data.
 
 The syntax for setting individual variables is :option:`--variable
@@ -722,7 +724,7 @@ verifies that the returned value is a dictionary or dictionary-like similarly
 as it verifies that list variables can only get a list-like value.
 
 A bigger benefit is that the value is converted into a special dictionary
-that it uses also when `creating dictionary variables`_ in the variable table.
+that it uses also when `creating dictionary variables`_ in the Variable section.
 Values in these dictionaries can be accessed using attribute access like
 `${dict.first}` in the above example. These dictionaries are also ordered, but
 if the original dictionary was not ordered, the resulting order is arbitrary.
@@ -775,7 +777,7 @@ keyword.
 Variables set with :name:`Set Suite Variable` keyword are available
 everywhere within the scope of the currently executed test
 suite. Setting variables with this keyword thus has the same effect as
-creating them using the `Variable table`_ in the test data file or
+creating them using the `Variable section`_ in the test data file or
 importing them from `variable files`_. Other test suites, including
 possible child test suites, will not see variables set with this
 keyword.
@@ -1062,7 +1064,7 @@ Variable priorities
 
    Variables `set in the command line`__ have the highest priority of all
    variables that can be set before the actual test execution starts. They
-   override possible variables created in Variable tables in test case
+   override possible variables created in Variable sections in test case
    files, as well as in resource and variable files imported in the
    test data.
 
@@ -1076,16 +1078,16 @@ Variable priorities
 
 __ `Setting variables in command line`_
 
-*Variable table in a test case file*
+*Variable section in a test case file*
 
-   Variables created using the `Variable table`_ in a test case file
+   Variables created using the `Variable section`_ in a test case file
    are available for all the test cases in that file. These variables
    override possible variables with same names in imported resource and
    variable files.
 
-   Variables created in the variable tables are available in all other tables
+   Variables created in the Variable sections are available in all other sections
    in the file where they are created. This means that they can be used also
-   in the Setting table, for example, for importing more variables from
+   in the Setting section, for example, for importing more variables from
    resource and variable files.
 
 *Imported resource and variable files*
@@ -1097,13 +1099,13 @@ __ `Setting variables in command line`_
    variables, the ones in the file imported first are taken into use.
 
    If a resource file imports resource files or variable files,
-   variables in its own Variable table have a higher priority than
+   variables in its own Variable section have a higher priority than
    variables it imports. All these variables are available for files that
    import this resource file.
 
    Note that variables imported from resource and variable files are not
-   available in the Variable table of the file that imports them. This
-   is due to the Variable table being processed before the Setting table
+   available in the Variable section of the file that imports them. This
+   is due to the Variable section being processed before the Setting section
    where the resource files and variable files are imported.
 
 *Variables set during test execution*
@@ -1119,7 +1121,7 @@ __ `Setting variables in command line`_
 
    `Built-in variables`_ like `${TEMPDIR}` and `${TEST_NAME}`
    have the highest priority of all variables. They cannot be overridden
-   using Variable table or from command line, but even they can be reset during
+   using Variable section or from command line, but even they can be reset during
    the test execution. An exception to this rule are `number variables`_, which
    are resolved dynamically if no variable is found otherwise. They can thus be
    overridden, but that is generally a bad idea. Additionally `${CURDIR}`
@@ -1148,7 +1150,7 @@ Test suite scope
 
 Variables with the test suite scope are available anywhere in the
 test suite where they are defined or imported. They can be created
-in Variable tables, imported from `resource and variable files`_,
+in Variable sections, imported from `resource and variable files`_,
 or set during the test execution using the BuiltIn_ keyword
 :name:`Set Suite Variable`.
 
diff --git a/doc/userguide/src/RobotFrameworkUserGuide.rst b/doc/userguide/src/RobotFrameworkUserGuide.rst
@@ -156,7 +156,6 @@
 .. _user keyword timeouts: `User keyword timeout`_
 .. _keyword timeout: `User keyword timeout`_
 .. _variable: Variables_
-.. _Variable tables: `Variable table`_
 .. _automatic variable: `Automatic variables`_
 .. _test libraries: `Using test libraries`_
 .. _test library: `test libraries`_
