Munurin millum rættingarnar hjá "Module:Road data/strings/doc"
EileenSanda (kjak | íkøst) Stovnaði síðu við "This module is used to store type data for use with several road templates, including {{tl|jct}} and {{tl|routelist row}}. Background information and a summary of the synt..." |
s Bot: Erstatt forældet <source> -tag og parameteren "enclose" [https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2020-April/002284.html] |
||
Linja 5: | Linja 5: | ||
At its most basic level, this module is a nested table of strings. At the top is the root table, named for the abbreviation of a country, state, or province. This table stores the type data for a particular place, which is named in the comment in the first line, and is returned at the end of the module. The table is composed of further tables, one per type. The basic syntax for a type table is: |
At its most basic level, this module is a nested table of strings. At the top is the root table, named for the abbreviation of a country, state, or province. This table stores the type data for a particular place, which is named in the comment in the first line, and is returned at the end of the module. The table is composed of further tables, one per type. The basic syntax for a type table is: |
||
< |
<syntaxhighlight lang="lua"> |
||
place.type = {shield = "", |
place.type = {shield = "", |
||
link = "", |
link = "", |
||
abbr = ""} |
abbr = ""} |
||
</syntaxhighlight> |
|||
</source> |
|||
The three main fields in a type table are <code>shield</code>, <code>link</code>, and <code>abbr</code>. Generally, <code>shield</code> determines the shield that is displayed, if any; <code>link</code> specifies the target of the link generated by a including module, if any; and <code>abbr</code> determines the displayed abbreviation. Currently, these are the three types used by all countries. By convention, they are always specified, using an empty string if there is no value. |
The three main fields in a type table are <code>shield</code>, <code>link</code>, and <code>abbr</code>. Generally, <code>shield</code> determines the shield that is displayed, if any; <code>link</code> specifies the target of the link generated by a including module, if any; and <code>abbr</code> determines the displayed abbreviation. Currently, these are the three types used by all countries. By convention, they are always specified, using an empty string if there is no value. |
||
Linja 16: | Linja 16: | ||
Once a type is defined, it can be referred to later in the code. A common idiom used for bannered types is defining the shield to be the shield field of the base type (from [[Module:Road data/strings/USA/MO]]): |
Once a type is defined, it can be referred to later in the code. A common idiom used for bannered types is defining the shield to be the shield field of the base type (from [[Module:Road data/strings/USA/MO]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
MO.US = {shield = "US %route%.svg", |
MO.US = {shield = "US %route%.svg", |
||
link = "U.S. Route %route% in Missouri", |
link = "U.S. Route %route% in Missouri", |
||
Linja 27: | Linja 27: | ||
banner = "Alternate plate.svg", |
banner = "Alternate plate.svg", |
||
width = "expand"} |
width = "expand"} |
||
</syntaxhighlight> |
|||
</source> |
|||
Another common idiom is defining a type alias by setting an entry in the root table equal to a previously defined type (from [[Module:Road data/strings/HKG]]): |
Another common idiom is defining a type alias by setting an entry in the root table equal to a previously defined type (from [[Module:Road data/strings/HKG]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
HKG.Route = {shield = "HK Route%route%.svg", |
HKG.Route = {shield = "HK Route%route%.svg", |
||
link = "Route %route% (Hong Kong)", |
link = "Route %route% (Hong Kong)", |
||
Linja 36: | Linja 36: | ||
HKG.route = HKG.Route |
HKG.route = HKG.Route |
||
</syntaxhighlight> |
|||
</source> |
|||
===Parser arguments=== |
===Parser arguments=== |
||
Linja 65: | Linja 65: | ||
The two statements may be combined. The parser will parse the if-then-else statement first, and then perform the argument inclusion. This combination is commonly used with bannered routes in the United States, where the <code>dab</code> argument is tested and the link disambiguation is adjusted accordingly, as follows (from [[Module:Road data/strings/USA/AL]]): |
The two statements may be combined. The parser will parse the if-then-else statement first, and then perform the argument inclusion. This combination is commonly used with bannered routes in the United States, where the <code>dab</code> argument is tested and the link disambiguation is adjusted accordingly, as follows (from [[Module:Road data/strings/USA/AL]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
AL["US-Bus"] = {shield = "US %route%.svg", |
AL["US-Bus"] = {shield = "US %route%.svg", |
||
link = "U.S. Route %route% Business ([dab||%dab%, |]Alabama)", |
link = "U.S. Route %route% Business ([dab||%dab%, |]Alabama)", |
||
Linja 71: | Linja 71: | ||
banner = "Business plate.svg", |
banner = "Business plate.svg", |
||
width = "expand"} |
width = "expand"} |
||
</syntaxhighlight> |
|||
</source> |
|||
When parsing the <code>link</code> field, the parser first checks to see if the <code>dab</code> argument was provided. If so, it replaces the statement with <code>%dab%, </code>. If not, the statement is replaced with the empty string placed in the <code>else</code> block. Then, the parser replaces <code>%route%</code> with the route number and, if the <code>dab</code> argument was provided, <code>%dab%</code> with the value of that argument. |
When parsing the <code>link</code> field, the parser first checks to see if the <code>dab</code> argument was provided. If so, it replaces the statement with <code>%dab%, </code>. If not, the statement is replaced with the empty string placed in the <code>else</code> block. Then, the parser replaces <code>%route%</code> with the route number and, if the <code>dab</code> argument was provided, <code>%dab%</code> with the value of that argument. |
||
Linja 79: | Linja 79: | ||
The most straightforward functionality provided by nested tables is switching. In its most basic form, the table consists of a series of key-value pairs, with the keys being route numbers and the values being the format strings used by those routes. Usually, the format string returned does not need parsing, but the option is there. A <code>default</code> entry should be provided to handle any route numbers not explicitly stated. The following is a representative example of route-based switching (from [[Module:Road data/strings/USA/AR]]): |
The most straightforward functionality provided by nested tables is switching. In its most basic form, the table consists of a series of key-value pairs, with the keys being route numbers and the values being the format strings used by those routes. Usually, the format string returned does not need parsing, but the option is there. A <code>default</code> entry should be provided to handle any route numbers not explicitly stated. The following is a representative example of route-based switching (from [[Module:Road data/strings/USA/AR]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
AR.AR = {shield = {default = "Arkansas %route%.svg", |
AR.AR = {shield = {default = "Arkansas %route%.svg", |
||
["917"] = "Arkansas 917-1.svg", |
["917"] = "Arkansas 917-1.svg", |
||
Linja 86: | Linja 86: | ||
abbr = "Hwy. %route%", |
abbr = "Hwy. %route%", |
||
width = "expand"} |
width = "expand"} |
||
</syntaxhighlight> |
|||
</source> |
|||
In this example, Highways 917 and 980 have non-standard shield names, which are explicitly provided. Other route numbers use the default format. |
In this example, Highways 917 and 980 have non-standard shield names, which are explicitly provided. Other route numbers use the default format. |
||
Switching on other arguments is also allowed. The name of the argument to be used for switching is stated in the <code>arg</code> field of the table. Nesting switches on different arguments is also allowed. A good example that uses both forms of switching can be found in [[Module:Road data/strings/CAN/ON|Ontario]]: |
Switching on other arguments is also allowed. The name of the argument to be used for switching is stated in the <code>arg</code> field of the table. Nesting switches on different arguments is also allowed. A good example that uses both forms of switching can be found in [[Module:Road data/strings/CAN/ON|Ontario]]: |
||
< |
<syntaxhighlight lang="lua"> |
||
local regionalShields = {arg = "county", |
local regionalShields = {arg = "county", |
||
["Essex"] = "Essex County Road %route%.png", |
["Essex"] = "Essex County Road %route%.png", |
||
Linja 99: | Linja 99: | ||
["Simcoe"] = {["52"] = "Simcoe county road 52.png", |
["Simcoe"] = {["52"] = "Simcoe county road 52.png", |
||
default = "Simcoe County Road %route%.JPG"}} |
default = "Simcoe County Road %route%.JPG"}} |
||
</syntaxhighlight> |
|||
</source> |
|||
In this example, which is a shield table that is reused by several types in Ontario, the <code>county</code> argument is used for the primary switch. If the route is in Simcoe County, a second switch is performed, this time on the route number. |
In this example, which is a shield table that is reused by several types in Ontario, the <code>county</code> argument is used for the primary switch. If the route is in Simcoe County, a second switch is performed, this time on the route number. |
||
Linja 105: | Linja 105: | ||
===Existence testing=== |
===Existence testing=== |
||
Another use for tables is existence testing. If a table has the <code>ifexists</code> field set to <code>true</code>, the parser will perform existence testing on the result of parsing the <code>default</code> field. If the test fails, the result of parsing the <code>otherwise</code> field is returned. Existence testing may be chained by using a second ifexists table as the value of the first table's <code>otherwise</code> field, and so on. Here's an example of nested existence testing (from [[Module:Road data/strings/GBR]]): |
Another use for tables is existence testing. If a table has the <code>ifexists</code> field set to <code>true</code>, the parser will perform existence testing on the result of parsing the <code>default</code> field. If the test fails, the result of parsing the <code>otherwise</code> field is returned. Existence testing may be chained by using a second ifexists table as the value of the first table's <code>otherwise</code> field, and so on. Here's an example of nested existence testing (from [[Module:Road data/strings/GBR]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
GBR.B = {shield = {ifexists = true, |
GBR.B = {shield = {ifexists = true, |
||
default = "UK road B%route%.svg", |
default = "UK road B%route%.svg", |
||
Linja 112: | Linja 112: | ||
link = "", |
link = "", |
||
abbr = "B%route%"} |
abbr = "B%route%"} |
||
</syntaxhighlight> |
|||
</source> |
|||
===Hooks=== |
===Hooks=== |
||
Linja 118: | Linja 118: | ||
Generally speaking, a hook is called by setting the <code>hook</code> field in a table as equal to the name of a hook. Hooks receive two arguments, both tables: <code>parameters</code>, which is the table in the definition; and <code>args</code>, which is simply the table of arguments normally passed to the parser. The hook returns a string, which is then parsed as usual. A powerful feature of hooks is that they can add arbitrary values to the argument table, which may be referenced in the string returned by the hook. Generally, the format string returned by the hook is specified in some form by the <code>default</code> field of the table, though there are exceptions. Here is an example of a hook (from [[Module:Road data/strings/MEX]]): |
Generally speaking, a hook is called by setting the <code>hook</code> field in a table as equal to the name of a hook. Hooks receive two arguments, both tables: <code>parameters</code>, which is the table in the definition; and <code>args</code>, which is simply the table of arguments normally passed to the parser. The hook returns a string, which is then parsed as usual. A powerful feature of hooks is that they can add arbitrary values to the argument table, which may be referenced in the string returned by the hook. Generally, the format string returned by the hook is specified in some form by the <code>default</code> field of the table, though there are exceptions. Here is an example of a hook (from [[Module:Road data/strings/MEX]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
MEX.SH = {shield = {ifexists = true, |
MEX.SH = {shield = {ifexists = true, |
||
arg = "state", |
arg = "state", |
||
Linja 130: | Linja 130: | ||
default = "%fullstate% State Highway %route%"}, |
default = "%fullstate% State Highway %route%"}, |
||
abbr = "SH %route%"} |
abbr = "SH %route%"} |
||
</syntaxhighlight> |
|||
</source> |
|||
In this example, the parser will process the link by calling the <code>mask</code> hook. In short, this hook takes the argument referenced in <code>base</code>, passes it through the mask module specified in <code>mask</code>, and stores it in the field in the arguments noted in <code>masked</code>. The hook returns the string given in <code>default</code>, which has access to the <code>fullstate</code> argument added by the hook. |
In this example, the parser will process the link by calling the <code>mask</code> hook. In short, this hook takes the argument referenced in <code>base</code>, passes it through the mask module specified in <code>mask</code>, and stores it in the field in the arguments noted in <code>masked</code>. The hook returns the string given in <code>default</code>, which has access to the <code>fullstate</code> argument added by the hook. |
||
Linja 136: | Linja 136: | ||
===Other functionality=== |
===Other functionality=== |
||
Functionality exists to display multiple shields for one route, which is used to display tolled and free shields for routes where they differ. This is done by supplying a table with two values, which are listed without indices. The parser is called twice by the calling module, and it returns one shield per call. An example may be found in [[Module:Road data/strings/USA/TX|Texas]]: |
Functionality exists to display multiple shields for one route, which is used to display tolled and free shields for routes where they differ. This is done by supplying a table with two values, which are listed without indices. The parser is called twice by the calling module, and it returns one shield per call. An example may be found in [[Module:Road data/strings/USA/TX|Texas]]: |
||
< |
<syntaxhighlight lang="lua"> |
||
TX.Both = {shield = {"Texas %route%.svg", "Toll Texas %route% new.svg"}, |
TX.Both = {shield = {"Texas %route%.svg", "Toll Texas %route% new.svg"}, |
||
link = "Texas State Highway %route%", |
link = "Texas State Highway %route%", |
||
abbr = "SH %route%", |
abbr = "SH %route%", |
||
width = 40} |
width = 40} |
||
</syntaxhighlight> |
|||
</source> |
|||
==Structure== |
==Structure== |
||
Each country has its own module. In the United States and Canada, each state/territory/province also has its own module. Each module begins with a comment stating the name of the country or state, followed by the root table declaration, as follows (from [[Module:Road data/strings/USA/AS]]): |
Each country has its own module. In the United States and Canada, each state/territory/province also has its own module. Each module begins with a comment stating the name of the country or state, followed by the root table declaration, as follows (from [[Module:Road data/strings/USA/AS]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
-- American Samoa |
-- American Samoa |
||
local AS = {} |
local AS = {} |
||
</syntaxhighlight> |
|||
</source> |
|||
The root table is named based on the established abbreviation for the country or state, which is the same as the abbreviation used in the module title. This table stores the various types used in that particular place. Most of the remaining code in the module defines these various types. The module ends by returning the root table: |
The root table is named based on the established abbreviation for the country or state, which is the same as the abbreviation used in the module title. This table stores the various types used in that particular place. Most of the remaining code in the module defines these various types. The module ends by returning the root table: |
||
< |
<syntaxhighlight lang="lua"> |
||
return AS |
return AS |
||
</syntaxhighlight> |
|||
</source> |
|||
===Aliasing=== |
===Aliasing=== |
||
There are two ways to define a type as an alias. If the type is defined within the module, simply set the new type as equal to the type being aliased, as shown above (from [[Module:Road data/strings/HKG]]): |
There are two ways to define a type as an alias. If the type is defined within the module, simply set the new type as equal to the type being aliased, as shown above (from [[Module:Road data/strings/HKG]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
HKG.Route = {shield = "HK Route%route%.svg", |
HKG.Route = {shield = "HK Route%route%.svg", |
||
link = "Route %route% (Hong Kong)", |
link = "Route %route% (Hong Kong)", |
||
Linja 163: | Linja 163: | ||
HKG.route = HKG.Route |
HKG.route = HKG.Route |
||
</syntaxhighlight> |
|||
</source> |
|||
If the type is defined in a separate module, such as a state highway type being used in another state's module, a special syntax may be used to refer to that module (from [[Module:Road data/strings/USA/NJ]]): |
If the type is defined in a separate module, such as a state highway type being used in another state's module, a special syntax may be used to refer to that module (from [[Module:Road data/strings/USA/NJ]]): |
||
< |
<syntaxhighlight lang="lua"> |
||
NJ.NY = {alias = {module = "USA/NY", type = "NY"}} |
NJ.NY = {alias = {module = "USA/NY", type = "NY"}} |
||
</syntaxhighlight> |
|||
</source> |
|||
This code sets the <code>NY</code> type as a link to the <code>NY</code> type in [[Module:Road data/strings/USA/NY]]. The parser will import that module and process the type as if the original module had declared it itself. The alias declaration may not add or override any data in the type table it points to. |
This code sets the <code>NY</code> type as a link to the <code>NY</code> type in [[Module:Road data/strings/USA/NY]]. The parser will import that module and process the type as if the original module had declared it itself. The alias declaration may not add or override any data in the type table it points to. |
Seinasta endurskoðan sum var 22. apr 2020 kl. 16:38
This module is used to store type data for use with several road templates, including {{jct}} and {{routelist row}}. Background information and a summary of the syntax are listed below.
Syntax
[rætta wikitekst]Hierarchy and fields
[rætta wikitekst]At its most basic level, this module is a nested table of strings. At the top is the root table, named for the abbreviation of a country, state, or province. This table stores the type data for a particular place, which is named in the comment in the first line, and is returned at the end of the module. The table is composed of further tables, one per type. The basic syntax for a type table is:
place.type = {shield = "",
link = "",
abbr = ""}
The three main fields in a type table are shield
, link
, and abbr
. Generally, shield
determines the shield that is displayed, if any; link
specifies the target of the link generated by a including module, if any; and abbr
determines the displayed abbreviation. Currently, these are the three types used by all countries. By convention, they are always specified, using an empty string if there is no value.
Two additional fields are used in the United States. banner
stores the name of the banner file, while width
stores a code representing the width of the shield. Unlike the three main fields, these are generally omitted entirely when unused.
Once a type is defined, it can be referred to later in the code. A common idiom used for bannered types is defining the shield to be the shield field of the base type (from Module:Road data/strings/USA/MO):
MO.US = {shield = "US %route%.svg",
link = "U.S. Route %route% in Missouri",
abbr = "US %route%",
width = "expand"}
MO["US-Alt"] = {shield = MO.US.shield,
link = "U.S. Route %route% Alternate ([dab||%dab%, |]Missouri)",
abbr = "US %route% Alt.",
banner = "Alternate plate.svg",
width = "expand"}
Another common idiom is defining a type alias by setting an entry in the root table equal to a previously defined type (from Module:Road data/strings/HKG):
HKG.Route = {shield = "HK Route%route%.svg",
link = "Route %route% (Hong Kong)",
abbr = "Route %route%"}
HKG.route = HKG.Route
Parser arguments
[rætta wikitekst]When the parser function of Module:Road data/parser is called, it is passed up to three parameters. The second one is the field to parse, and the last one is a rarely-used option designed for multiple-shield types. The first and most important parameter is a table of arguments collected by the calling module, which generally includes the state, country, or both; the type and number of the route; and a few miscellaneous arguments. This table of arguments forms the basis of the parser's format string syntax.
The table accessible by the strings includes the following entries by default:
state
: The state or province the route is located in.country
: The country the route is located in. If the country is not passed by the calling module, the parser will attempt to include it.
The above entries are primarily used to find the string module itself, so they should not be a concern for module writers.
type
: The type of the route. This determines the entry of the root table that is used by the parser.route
: The route "number". This is easily the most important argument for module writers.
The following entries are used less often:
county
: The county the route is located in. This is usually used for county routes in the United States.township
: This entry is similar in function and utility to thecounty
entry.dab
: A tag used to disambiguate the link target. This is mostly used for bannered routes in the United States.denom
: This rare entry is used exclusively for West Virginia county routes.
Parser hooks, which will be described later, can add entries to this table that may be used by strings.
Basic string syntax
[rætta wikitekst]The most basic value that can be used for most type table fields is a specially formatted string, which will be referred to in this documentation as a format string. This is the string that will ultimately be parsed and returned by the parser. A format string is an ordinary string object. The power of these strings comes in the form of two special instructions that are recognized by the parser.
The first is anything in %argument%
form. The parser will replace such a statement with the value of the argument
entry in the arguments table described earlier. This is what allows the route number to be spliced into a shield or link name.
The second special string is in the form of [arg|equals|then|else]
. This functions as a rudimentary if-then-else statement. The parser tests the value of arg
to see if it is equal to the value specified in equals
. equals
may be empty, in which case the parser tests the existence of the arg
argument. If the result of the test is true, the statement is replaced with the value of the then
block. Otherwise, it is replaced with the value of the else
block.
The two statements may be combined. The parser will parse the if-then-else statement first, and then perform the argument inclusion. This combination is commonly used with bannered routes in the United States, where the dab
argument is tested and the link disambiguation is adjusted accordingly, as follows (from Module:Road data/strings/USA/AL):
AL["US-Bus"] = {shield = "US %route%.svg",
link = "U.S. Route %route% Business ([dab||%dab%, |]Alabama)",
abbr = "US-%route% Bus.",
banner = "Business plate.svg",
width = "expand"}
When parsing the link
field, the parser first checks to see if the dab
argument was provided. If so, it replaces the statement with %dab%,
. If not, the statement is replaced with the empty string placed in the else
block. Then, the parser replaces %route%
with the route number and, if the dab
argument was provided, %dab%
with the value of that argument.
Switching
[rætta wikitekst]Some logic is too complicated to represent with only format strings. This framework provides several methods to express complex data. All of these involve storing a nested table as the value of a field.
The most straightforward functionality provided by nested tables is switching. In its most basic form, the table consists of a series of key-value pairs, with the keys being route numbers and the values being the format strings used by those routes. Usually, the format string returned does not need parsing, but the option is there. A default
entry should be provided to handle any route numbers not explicitly stated. The following is a representative example of route-based switching (from Module:Road data/strings/USA/AR):
AR.AR = {shield = {default = "Arkansas %route%.svg",
["917"] = "Arkansas 917-1.svg",
["980"] = "Arkansas 980(Airport).svg"},
link = "Arkansas Highway %route% [dab||(%dab%)|]",
abbr = "Hwy. %route%",
width = "expand"}
In this example, Highways 917 and 980 have non-standard shield names, which are explicitly provided. Other route numbers use the default format.
Switching on other arguments is also allowed. The name of the argument to be used for switching is stated in the arg
field of the table. Nesting switches on different arguments is also allowed. A good example that uses both forms of switching can be found in Ontario:
local regionalShields = {arg = "county",
["Essex"] = "Essex County Road %route%.png",
["York"] = "York Regional Road %route%.svg",
["Durham"] = "Durham Regional Road %route%.svg",
["Niagara"] = "Niagara Regional Road %route%.svg",
["Simcoe"] = {["52"] = "Simcoe county road 52.png",
default = "Simcoe County Road %route%.JPG"}}
In this example, which is a shield table that is reused by several types in Ontario, the county
argument is used for the primary switch. If the route is in Simcoe County, a second switch is performed, this time on the route number.
Existence testing
[rætta wikitekst]Another use for tables is existence testing. If a table has the ifexists
field set to true
, the parser will perform existence testing on the result of parsing the default
field. If the test fails, the result of parsing the otherwise
field is returned. Existence testing may be chained by using a second ifexists table as the value of the first table's otherwise
field, and so on. Here's an example of nested existence testing (from Module:Road data/strings/GBR):
GBR.B = {shield = {ifexists = true,
default = "UK road B%route%.svg",
otherwise = {ifexists = true,
default = "UK road B%route%.png"}},
link = "",
abbr = "B%route%"}
Hooks
[rætta wikitekst]Due to technical limitations, these string modules cannot contain functions. Rather than force functionality into the string framework, the parser can call functions in a separate hooks module. The functions in this module, Module:Road data/parser/hooks, are more-or-less fully functional functions. The exact functionalities of these hooks are beyond the scope of this documentation. Descriptions of these hooks may be found on their documentation page.
Generally speaking, a hook is called by setting the hook
field in a table as equal to the name of a hook. Hooks receive two arguments, both tables: parameters
, which is the table in the definition; and args
, which is simply the table of arguments normally passed to the parser. The hook returns a string, which is then parsed as usual. A powerful feature of hooks is that they can add arbitrary values to the argument table, which may be referenced in the string returned by the hook. Generally, the format string returned by the hook is specified in some form by the default
field of the table, though there are exceptions. Here is an example of a hook (from Module:Road data/strings/MEX):
MEX.SH = {shield = {ifexists = true,
arg = "state",
SON = "HIGHWAYSON %route%.jpg",
NLE = "Nuevo Leon State Highway %route%.PNG",
default = ""},
link = {hook = "mask",
mask = "Road data/masks/MEX",
base = "state",
masked = "fullstate",
default = "%fullstate% State Highway %route%"},
abbr = "SH %route%"}
In this example, the parser will process the link by calling the mask
hook. In short, this hook takes the argument referenced in base
, passes it through the mask module specified in mask
, and stores it in the field in the arguments noted in masked
. The hook returns the string given in default
, which has access to the fullstate
argument added by the hook.
Other functionality
[rætta wikitekst]Functionality exists to display multiple shields for one route, which is used to display tolled and free shields for routes where they differ. This is done by supplying a table with two values, which are listed without indices. The parser is called twice by the calling module, and it returns one shield per call. An example may be found in Texas:
TX.Both = {shield = {"Texas %route%.svg", "Toll Texas %route% new.svg"},
link = "Texas State Highway %route%",
abbr = "SH %route%",
width = 40}
Structure
[rætta wikitekst]Each country has its own module. In the United States and Canada, each state/territory/province also has its own module. Each module begins with a comment stating the name of the country or state, followed by the root table declaration, as follows (from Module:Road data/strings/USA/AS):
-- American Samoa
local AS = {}
The root table is named based on the established abbreviation for the country or state, which is the same as the abbreviation used in the module title. This table stores the various types used in that particular place. Most of the remaining code in the module defines these various types. The module ends by returning the root table:
return AS
Aliasing
[rætta wikitekst]There are two ways to define a type as an alias. If the type is defined within the module, simply set the new type as equal to the type being aliased, as shown above (from Module:Road data/strings/HKG):
HKG.Route = {shield = "HK Route%route%.svg",
link = "Route %route% (Hong Kong)",
abbr = "Route %route%"}
HKG.route = HKG.Route
If the type is defined in a separate module, such as a state highway type being used in another state's module, a special syntax may be used to refer to that module (from Module:Road data/strings/USA/NJ):
NJ.NY = {alias = {module = "USA/NY", type = "NY"}}
This code sets the NY
type as a link to the NY
type in Module:Road data/strings/USA/NY. The parser will import that module and process the type as if the original module had declared it itself. The alias declaration may not add or override any data in the type table it points to.
Style
[rætta wikitekst]There are a few style guidelines that should be followed:
- Align table fields using spaces. All tables should be aligned so that fields line up with each other, as shown in the above examples.
- Do not place a table's closing brace on a separate line.
- Each table field should be on its own line.
- Add spaces to either side of an assignment operator (equals sign).
- Leave a blank line between types. Type aliases should be set off from their base type by a blank line, but no blank lines should be placed between the aliases themselves.