Overview
On the Kuma platform that powers MDN, the template system for automating aspects of content on the wiki is called KumaScript. KumaScript is powered by server-side JavaScript, implemented using Node.js. This article provides basic information on how to use KumaScript.
For a detailed overview and Q&A of KumaScript, watch the MDN dev team's KumaScript Fireside Chat. KumaScript replaced DekiScript, which was the template language for MindTouch, the previous platform used by MDN.
What is KumaScript?
- A way to reuse and localize content that appears repeatedly between documents (e.g., compatibility labels, section navigation, warning banners).
- A way to build documents out of content pulled from other documents.
- A way to fetch and include content from other web sites and services (e.g., Bugzilla).
What KumaScript is not
- KumaScript does not support interactive scripting of the kind that can accept form submissions.
- KumaScript does not have access to a database, files, or any other way to store information persistently.
- KumaScript does not support site personalization based on the user currently logged in.
- KumaScript does not have access to user information, only to the content and metadata of a wiki page being viewed.
Basics
KumaScript works by allowing trusted MDN users to write embedded JavaScript templates. These templates can be invoked in document content by any MDN author, through the use of macros.
A template looks like this:
<% for (var i = 0; i < $0; i++) { %>
Hello #<%= i %>
<% } %>
A macro looks like this:
\{{ hello("3") }}
The output of the macro looks like this:
Hello #0 Hello #1 Hello #2
Macro Syntax
KumaScript templates are invoked in document content with macros, like this:
\{{ templateName("arg0", "arg1", ..., "argN") }}
Macro syntax consists of these rules:
- Macros start and end with
\{{and\}}characters. - The first part of the macro is the name of a template. This corresponds to a wiki page at
/en-US/docs/Template:{name}— editing and creating these pages requires a special permission that admins can grant to trusted editors. - A template can accept parameters, and this parameter list starts and ends with parentheses.
- In a template, the parameters passed in are available inside the macro as the variables
$0,$1,$2, and so on. - All non-numeric parameters must be in quotes. Numbers can be left unquoted.
- The entire list of parameters is also available in a template as the variable
arguments.
Using JSON as a macro parameter
There is one more semi-experimental feature available to macros: you can supply a JSON object for the first and only parameter, like so:
\{{ templateName({ "Alpha":"one", "Beta":["a","b","c"], "Foo":"http:\/\/mozilla.org\/" }) }}
The data from this macro is available in template code as an object in the $0 argument (e.g., $0.Alpha, $0.Beta, $0.Foo). This also allows you to express complex data structures in macro parameters that are hard or impossible to do with a simple list of parameters.
Note that this parameter style is very picky - it must adhere to JSON syntax exactly, which has some escaping demands that are easy to miss (e.g., all forward slashes are escaped). When in doubt, try running your JSON through a validator.
How to write "\{{"
Since the character sequence "\{{" is used to indicate the start of a macro, this can be troublesome if you actually just want to use "\{{" and "}}" in a page. It will probably produce DocumentParsingError messages.
In this case, you can escape the first brace with a backslash, like so: \\{
Template Syntax
KumaScript templates are processed by an embedded JavaScript template engine with a few simple rules:
- Most text is treated as output and included in the output stream.
- JavaScript variables and expressions can be inserted into the output stream with these blocks:
<%= expr %>— the value of a JavaScript expression is escaped for HTML before being included in output (e.g., characters like<and>are turned into<and>).<%- expr %>— the value of a JavaScript expression is included in output without any escaping. (Use this if you want to dynamically build markup or use the results of another template that may include markup.)- It is an error to include semicolons inside these blocks.
- Anything inside a
<% %>block is interpreted as JavaScript. This can include loops, conditionals, etc. - Nothing inside a
<% %>block can ever contribute to the output stream. But, you can transition from JS mode to output mode using<% %>—for example:<% for (var i = 0; i < $0; i++) { %> Hello #<%= i %> <% } %>Note how the JS is contained in
<% ... %>, and output happens in the space between%> ... <%. The for loop in JS can begin in one<% %>block, transition to output mode, and finish up in a second<% %>JS block. - For more details on EJS syntax, check out the upstream module documentation.
Tips
Dates and times
It's important to note that the standard JavaScript {{jsxref("Date")}} constructor is overridden by the KumaScript Date interface. You can create a JavaScript Date by calling the KumaScript date.now() or date.parse() function.
Advanced Features
Beyond the basics, the KumaScript system offers some advanced features.
Environment variables
When the wiki makes a call to the KumaScript service, it passes along some context on the current document that KumaScript makes available to templates as variables:
env.path- The path to the current wiki document
env.url- The full URL to the current wiki document
env.id- A short, unique ID for the current wiki document
env.files- An array of the files attached to the current wiki document; each object in the array is as described under {{ anch("File objects") }} below
env.review_tags- An array of the review tags on the article ("technical", "editorial", etc.)
env.locale- The locale of the current wiki document
env.title- The title of the current wiki document
env.slug- The URL slug of the current wiki document
env.tags- An array list of tag names for the current wiki document
env.modified- Last modified timestamp for the current wiki document
env.cache_controlCache-Controlheader sent in the request for the current wiki document, useful in deciding whether to invalidate caches
File objects
Each file object has the following fields:
title- The attachment's title
description- A textual description of the current revision of the file
filename- The file's name
size- The size of the file in bytes
author- The username of the person who uploaded the file
mime- The MIME type of the file
url- The URL at which the file can be found
Working with tag lists
The env.tags and env.review_tags variables return arrays of tags. You can work with these in many ways, of course, but here are a couple of suggestions.
Looking to see if a specific tag is set
You can look to see if a specific tag exists on a page like this:
if (env.tags.indexOf("tag") != −1) {
// The page has the tag "tag"
}
Iterating over all the tags on a page
You can also iterate over all the tags on a page, like this:
env.tag.forEach(function(tag) {
// do whatever you need to do, such as:
if (tag.indexOf("a") == 0) {
// this tag starts with "a" - woohoo!
}
});
APIs and Modules
KumaScript offers some built-in utility APIs, as well as the ability to define new APIs in modules editable as wiki documents.
Built-in methods
This manually-maintained documentation is likely to fall out of date with the code. With that in mind, you can always check out the latest state of built-in APIs in the KumaScript source. But here is a selection of useful methods exposed to templates:
md5(string)- Returns an MD5 hex digest of the given string.
template("name", ["arg0", "arg1", ..., "argN"])- Executes and returns the result of the named template with the given list of parameters.
- Used in templates like so:
<%- template("warning", ["foo", "bar", "baz"]) %>. - This is a JavaScript function. So, if one of the parameters is an arg variable like $2, do not put it in quotes. Like this:
<%- template("warning", [$1, $2, "baz"]) %>. If you need to call another template from within a block of code, do not use<%...%>. Example:myvar = "<li>" + template("LXRSearch", ["ident", "i", $1]) + "</li>"; require(name)- Loads another template as a module; any output is ignored. Anything assigned to
module.exportsin the template is returned. - Used in templates like so:
<% var my_module = require('MyModule'); %>. cacheFn(key, timeout, function_to_cache)- Using the given key and cache entry lifetime, cache the results of the given function. Honors the value of
env.cache_controlto invalidate cache onno-cache, which can be sent by a logged-in user hitting shift-refresh. request- Access to
mikeal/request, a library for making HTTP requests. Using this module in KumaScript templates is not yet very friendly, so you may want to wrap usage in module APIs that simplify things. log.debug(string)- Outputs a debug message into the script log on the page (i.e. the big red box that usually displays errors).
Built-in API modules
There's only one API built in at the moment, in the kuma namespace. You can see the most up to date list of methods under kuma from the KumaScript source code, but here are a few:
kuma.inspect(object)- Renders any JS object as a string, handy for use with
log.debug(). See also: node.jsutil.inspect().
kuma.htmlEscape(string)- Escapes the characters
&, <, >, "to&, <, >, ", respectively. kuma.url- See also: node.js
urlmodule. kuma.fetchFeed(url)- Fetch an RSS feed and parse it into a JS object. See also:
Template:InsertFeedLinkList
Creating modules
Using the built-in require() method, you can load a template as a module to share common variables and methods between templates. A module can be defined in a template like this:
<%
module.exports = {
add: function (a, b) {
return a + b;
}
}
%>
Assuming this template is saved as /en-US/docs/Template:MathLib, you can use it in another template like so:
<%
var math_lib = require("MathLib");
%>
The result of 2 + 2 = <%= math_lib.add(2, 2) %>
And, the output of this template will be:
The result of 2 + 2 = 4
Auto-loaded modules
There are a set of modules editable as wiki templates that are automatically loaded and made available to every template. This set is defined in the configuration file for the KumaScript service - any changes to this requires an IT bug to edit configuration and a restart of the service.
For the most part, these attempt to provide stand-ins for legacy DekiScript features to ease template migration. But, going forward, these can be used to share common variables and methods between templates:
mdn.*- Template:MDN:CommonDate.*- Template:DekiScript:DatePage.*- Template:DekiScript:PageString.*- Template:DekiScript:StringUri.*- Template:DekiScript:UriWeb.*- Template:DekiScript:WebWiki.*- Template:DekiScript:Wiki
Note: You might notice that the DekiScript modules use a built-in method named buildAPI(), like so:
<% module.exports = buildAPI({
StartsWith: function (str, sub_str) {
return (''+str).indexOf(sub_str) === 0;
}
}); %>
The reason for this is because DekiScript is case-insensitive when it comes to references to API methods, whereas JavaScript is strict about uppercase and lowercase in references. So, buildAPI() is a hack to try to cover common case variations in DekiScript calls found in legacy templates.
With that in mind, please do not use buildAPI() in new modules.
Tips and caveats
Debugging
A useful tip when debugging. You can use the log.debug() method to output text to the scripting messages area at the top of the page that's running your template. Note that you need to be really sure to remove these when you're done debugging, as they're visible to all users! To use it, just do something like this:
<%- log.debug("Some text goes here"); %>
You can, of course, create more complex output using script code if it's helpful.
Limitations of content migration from MindTouch
When we make the move to Kuma, we will migrate content from the old MindTouch-based wiki to the new Kuma-based one. This script will do some basic work to attempt to convert scripts. But, there are many common code patterns that migration can't fix.
So, this means that we'll need human intervention to carry template scripts over the rest of the way to being functional.
To find templates in need of review and repair, check here: /en...eview/template.
To find examples of templates that have already been repaired, check here: /en...s/tag/ks-fixed.
Check the template usage stats bug file attachments to help prioritize templates to fix. If you know your way around gzip and grep, this attachment (a 1.5MB tab-delimited file listing template/document pairs) can help tell you what templates are used on which pages.
As you repair templates, please uncheck the "Template" review checkbox and add the tag "ks-fixed", which will keep the above lists accurate.
You can also find templates in need of repair by simply browsing through wiki content and spotting where content looks garbled with code or otherwise incorrect. Editing the page should show you the name of a macro that's in need of help. You may also see scripting errors on pages, which should offer editing links to the templates causing issues.
Keyword Shortcut for quick template editing
If you spend time editing a lot of KumaScript templates (e.g., to fix partly-migrated legacy DekiScript templates), you may find this keyword shortcut bookmark handy:
| Name | edit mdn template |
|---|---|
| Location | /en...mplate:%s$edit |
| Keyword | te |
Armed with this bookmarklet, you can copy the name of a template, open a new tab, and type T , E , Ctrl + V , Return to start editing the template. This helps when a template is misbehaving, yet not badly enough to cause a scripting error message.
Changing Locale Identifiers
The identifiers for various locales have changed from MindTouch to Kuma:
en->en-UScn->zh-CNzh_cn->zh-CNzh_tw->zh-TWpt->pt-PT
This list should not change in the future, assuming we've not missed any. These locale identifier changes become significant in legacy DekiWIki templates.
URL pattern changes
The URL pattern for all wiki documents has changed:
/{locale}/{slug}->/{locale}/docs/{slug}
So, for example:
/en/JavaScript->/en-US/docs/JavaScript/de/JavaScript->/de/docs/JavaScript/ja/JavaScript->/ja/docs/JavaScript
To avoid breaking links, there is an attempt to automatically redirect requests to the legacy-style URLs to new-style URLs. But, efforts should be made to change links to the new-style URLs whenever possible.
Differences from DekiScript
It's useful to note a few changes from templates in DekiScript, in case you encounter these in migrated content:
- No more
<span class="script"> - No more
template.norwiki.templateprefixing - No more
template({name}[, arguments])syntax - Arguments must be quoted - e.g.,
bug(123456)becomesbug("123456")- unless you are calling the template from within another template, and the argument is one of the passed-in args like$1in this example:template("LXRSearch", ["ident", "i", $1]).
Caching
KumaScript templates are heavily cached to improve performance. For the most part, this works great to serve up content that doesn't change very often. But, as a logged in user, you have two options to force a page to be regenerated, in case you notice issues with scripting:
- Hit Refresh in your browser. This causes KumaScript to invalidate its cache for the content on the current page by issuing a request with a
Cache-Control: max-age=0header. - Hit Shift-Refresh in your browser. This causes KumaScript to invalidate cache for the current page, as well as for any templates or content used by the current page by issuing a request with a
Cache-Control: no-cacheheader.
Cookbook
This section will list examples of common patterns for templates used on MDN, including samples of legacy DekiScript templates and their new KumaScript equivalents.
Force templates used on a page to be reloaded
It bears repeating: To force templates used on a page to be reloaded after editing, hit Shift-Reload. Just using Reload by itself will cause the page contents to be regenerated, but using cached templates and included content. A Shift-Reload is necessary to invalidate caches beyond just the content of the page itself.
Recovering from "Unknown Error"
Sometimes, you'll see a scripting message like this when you load a page:
Kumascript service failed unexpectedly: <class 'httplib.BadStatusLine'>
This is probably a temporary failure of the KumaScript service. If you Refresh the page, the error may disappear. If that doesn't work, try a Shift-Refresh. If, after a few tries, the error persists - file an IT bug for Mozilla Developer Network to ask for an investigation.
Broken wiki.languages() macros
On some pages, you'll see a scripting error like this:
Syntax error at line 436, column 461: Expected valid JSON object as the parameter of the preceding macro but...
If you edit the page, you'll probably see a macro like this at the bottom of the page:
\{{ wiki.languages({ "zh-tw": "zh_tw/Core_JavaScript_1.5_教學/JavaScript_概要", ... }) }}
To fix the problem, just delete the macro. Or, replace the curly braces on either side with HTML comments <!-- --> to preserve the information, like so:
<!-- wiki.languages({ "zh-tw": "zh_tw/Core_JavaScript_1.5_教學/JavaScript_概要", ... }) -->
Because Kuma supports localization differently, these macros aren't actually needed any more. But, they've been left intact in case we need to revisit the relationships between localized pages. Unfortunately, it seems like migration has failed to convert some of them properly.
Unconverted inline script blocks
Occasionally, you'll find some text like this at the bottom of a page, or even somewhere in the middle:
autoPreviousNext("JSGChapters");
wiki.languages({
"fr": "fr/Guide_JavaScript_1.5/Expressions_rationnelles",
"ja": "ja/Core_JavaScript_1.5_Guide/Regular_Expressions"
});
This is a script block that didn't get converted to a KumaScript macro during migration. It happens, unfortunately. If you switch to HTML source editing mode, you'll see this, a <pre class="script"> element:
<pre class="script" style="font-size: 16px;">
autoPreviousNext("JSGChapters");
wiki.languages({
"fr": "fr/Guide_JavaScript_1.5/Expressions_rationnelles",
"ja": "ja/Core_JavaScript_1.5_Guide/Regular_Expressions"
});
</pre>
This is an inline script - previously allowed by DekiScript, no longer supported by KumaScript.
For this particular example, common to the JavaScript Guide, you can fix it by removing the wiki.languages part (see previous section) and change the autoPreviousNext() into a macro like so:
\{{ autoPreviousNext("JSGChapters") }}
If you see a block of code that's more complex than the above, you will need to create a new template, move the code there, and replace the code in its previous spot with a macro calling the new template.
Finding the Current Page's Language
In KumaScript, the locale of the current document is exposed as an environment variable:
var lang = env.locale;
In legacy DekiScript templates, coming up with the locale was a bit harder. You'll see chunks of code like this:
/* accepts as input one required parameter: MathML element to create an xref to */
var u = uri.parts(Page.uri);
var lang = string.tolower(u.path[0]);
if (string.contains(lang, "project") || string.contains(lang, "Project")) {
lang = string.substr(lang, 8);
}
/* fall back to page.language on a user page */
else if (string.StartsWith(lang, "user:")) {
lang = page.language;
}
Please replace code like the above with the new KumaScript example. The env.locale variable should be reliable and defined for every document.
Reading the contents of a page attachment
You can read the contents of an attached file by using the mdn.getFileContent() function, like this:
<% var contents = mdn.getFileContent(fileUrl); ... do stuff with the contents ... %>
or
<%-mdn.getFileContent(fileObject)%>
In other words, you may specify either the URL of the file to read or as a file object. The file objects for a page can be accessed through the array env.files. So, for example, to embed the contents of the first file attached to the article, you can do this:
<%-mdn.getFileContent(env.files[0])%>
If the file isn't found, an empty string is returned. There is currently no way to tell the difference between an empty file and a nonexistent one. But if you're putting empty files on the wiki, you're doing it wrong.
Localizing template content
Templates cannot be translated like other wiki pages. KumaScript only looks for templates in the en-US locale (i.e., /en-US/docs/Template:{name}), and does not look for templates that have been translated to another locale (i.e., /fr/docs/Template:{name}).
So the main way to output content tailored to the current document locale is to pivot on the value of env.locale. There are many ways to do this, but a few patterns are common in the conversion of legacy DekiScript templates:
If/else blocks in KumaScript
The KumaScript equivalent of this can be achieved with simple if/else blocks, like so:
<% if ("fr" == env.locale) { %>
<%- template("CSSRef") %> « <a title="Référence_CSS/Extensions_Mozilla" href="/fr/docs/Référence_CSS/Extensions_Mozilla">Référence CSS:Extensions Mozilla</a>
<% } else if ("ja" == env.locale) { %>
<%- template("CSSRef") %> « <a title="CSS_Reference/Mozilla_Extensions" href="/ja/docs/CSS_Reference/Mozilla_Extensions">CSS リファレンス:Mozilla 拡張仕様</a>
<% } else if ("pl" == env.locale) { %>
<%- template("CSSRef") %> « <a title="Dokumentacja_CSS/Rozszerzenia_Mozilli" href="/pl/docs/Dokumentacja_CSS/Rozszerzenia_Mozilli">Dokumentacja CSS:Rozszerzenia Mozilli</a>
<% } else if ("de" == env.locale) { %>
<%- template("CSSRef") %> « <a title="CSS_Referenz/Mozilla_CSS_Erweiterungen" href="/de/docs/CSS_Referenz/Mozilla_CSS_Erweiterungen">CSS Referenz: Mozilla Erweiterungen</a>
<% } else { %>
<%- template("CSSRef") %> « <a title="CSS_Reference/Mozilla_Extensions" href="/en-US/docs/CSS_Reference/Mozilla_Extensions">CSS Reference:Mozilla Extensions</a>
<% } %>
Legacy DekiScript
A similar way this was done in DekiScript was using <span>'s with lang="{locale}" attributes, like so:
<p><span lang="*" class="lang lang-*"><span class="script">CSSRef()</span> « <a title="en/CSS_Reference/Mozilla_Extensions" href="/en/CSS_Reference/Mozilla_Extensions">CSS Reference:Mozilla Extensions</a></span> <span lang="en" class="lang lang-en"><span class="script">CSSRef()</span> « <a title="en/CSS_Reference/Mozilla_Extensions" href="/en/CSS_Reference/Mozilla_Extensions">CSS Reference:Mozilla Extensions</a> <span lang="fr" class="lang lang-fr"><span class="script">CSSRef()</span> « <a title="fr/Référence_CSS/Extensions_Mozilla" href="/fr/Référence_CSS/Extensions_Mozilla">Référence CSS:Extensions Mozilla</a></span> <span lang="ja" class="lang lang-ja"><span class="script">CSSRef()</span> « <a title="ja/CSS_Reference/Mozilla_Extensions" href="/ja/CSS_Reference/Mozilla_Extensions">CSS リファレンス:Mozilla 拡張仕様</a></span> <span lang="pl" class="lang lang-pl"> <span class="script">CSSRef()</span> « <a title="pl/Dokumentacja_CSS/Rozszerzenia_Mozilli" href="/pl/Dokumentacja_CSS/Rozszerzenia_Mozilli">Dokumentacja CSS:Rozszerzenia Mozilli</a></span> <span lang="de" class="lang lang-de"><span class="script">CSSRef()</span> « <a title="de/CSS_Referenz/Mozilla_CSS_Erweiterungen" href="/de/CSS_Referenz/Mozilla_CSS_Erweiterungen">CSS Referenz: Mozilla Erweiterungen</a></span></span></p>
This is no longer supported. If you encounter templates built using the legacy DekiScript approach, revise them to use the new KumaScript pattern.
Depending on what text editor is your favorite, you may be able to copy & paste from the browser-based editor and attack this pattern with a series of search/replace regexes to get you most of the way there.
My favorite editor is MacVim, and a series of regexes like this does the bulk of the work with just a little manual clean up following:
%s#<span#^M<span#g
%s#<span lang="\(.*\)" .*>#<% } else if ("\1" == env.locale) { %>#g
%s#<span class="script">template.Cssxref(#<%- template("Cssxref", [#
%s#)</span> </span>#]) %>
Your mileage may vary, and patterns change slightly from template to template. That's why the migration script was unable to just handle this automatically, after all.
String variables and switch
Rather than switch between full chunks of markup, you can define a set of strings, switch them based on locale, and then use them to fill in placeholders in a single chunk of markup:
<%
var s_title = 'Firefox for Developers';
switch (env.locale) {
case 'de':
s_title = "Firefox für Entwickler";
break;
case 'fr':
s_title = "Firefox pour les développeurs";
break;
case 'es':
s_title = "Firefox para desarrolladores";
break;
};
%>
<span class="title"><%= s_title %></span>
You'll see examples of this in legacy DekiScript templates. For the most part, this pattern should work as-is, but you may need to adjust the expected values of locales (e.g., en, cn, pt become en-US, zh-CN, pt-PT respectively).
Use mdn.localString()
A recent addition to the Template:MDN:Common module is mdn.localString(), used like this:
<%
var s_title = mdn.localString({
"en-US": "Firefox for Developers",
"de": "Firefox für Entwickler",
"es": "Firefox para desarrolladores"
});
%>
<span class="title"><%= s_title %></span>
This is more concise than the switch statement, and may be a better choice where a single string is concerned. However, if many strings need to be translated (e.g., as in CSSRef), a switch statement might help keep all the strings grouped by locale and more easily translated that way.
When the object does not have the appropriate locale, the value of "en-US" is used as the initial value.
Before and after examples
Carriage returns added here and there for clarity.
// Before: DOM0() template Dekiscript
<p><span class="lang lang-en" lang="en">DOM Level 0. Not part of any standard. </span>
<span class="lang lang-es" lang="es">DOM Nivel 0. No es parte de ninguna norma. </span>
<span class="lang lang-*" lang="*">DOM Level 0. Not part of any standard. </span>
<span class="lang lang-fr" lang="fr">DOM Level 0. Ne fait partie d'aucune spécification. </span>
<span class="lang lang-ja" lang="ja">DOM Level 0。どの標準にも属しません。 </span>
<span class="lang lang-pl" lang="pl">DOM Level 0. Nie jest częścią żadnego standardu. </span>
<span class="lang lang-zh-cn" lang="zh-cn">DOM Level 0 不属于任何标准.</span></p>
// After: Kumascript version
<% if ("fr" == env.locale) { %>
<p>DOM Level 0. Ne fait partie d'aucune spécification.</p>
<% } else if ("ja" == env.locale) { %>
<p>DOM Level 0。どの標準にも属しません。 </p>
<% } else if ("pl" == env.locale) { %>
<p>DOM Level 0. Nie jest częścią żadnego standardu.</p>
<% } else if ("es" == env.locale) { %>
<p>DOM Nivel 0. No es parte de ninguna norma.</p>
<% } else if ("zh-CN" == env.locale) { %>
<p>DOM Level 0 不属于任何标准.</p>
<% } else { %>
<p>DOM Level 0. Not part of any standard.</p>
<% } %>
// From ReleaseChannelInfo() template
// Before:
web.html("<p>Firefox " + $0 + ", based on Gecko " + $1 + ", will ship in " + $2 + ".
This article provides information about the changes in this release that will
affect developers. Nightly builds of what will become Firefox " + $0 + " are "
+ web.link(url, "currently available") + " on the " + string.ToUpperFirst($3)
+ " channel.</p>");
// After:
<p>Firefox <%= $0 %>, based on Gecko <%= $1 %>, will ship in <%= $2 %>. This
article provides information about the changes in this release that will
affect developers. Nightly builds of what will become Firefox <%= $0 %>
are <%- web.link(url, "currently available")%> on the
<%= string.ToUpperFirst($3) %> channel.</p>
// Before: old Dekiscript snippet
if ($1 && string.length($1)) {
optionsText = optionsText + "<li>" + LXRSearch("ident", "i", $1) + "</li>";
}
// After: new Kumascript. Quote parameters to template() unless it is an arg variable (like $1).
if ($1 && string.length($1)) {
optionsText = optionsText + "<li>" + template("LXRSearch", ["ident", "i", $1]) + "</li>";
}
// Note that template() within <% ... %> outputs nothing directly. If you want to call another
// template and display its output, use <%= %> or <%- %> like this:
<%- template("LXRSearch", ["ident", "i", $1]) %>