Merge pull request #194 from lucaboesch/javascript

andrewnicols · web-flow · commit c20d4b3c49e4 · 2022-06-08T13:30:45.000+08:00
[docs] Spell JavaScript correctly.
diff --git a/docs/apis/_files/amd-dir.mdx b/docs/apis/_files/amd-dir.mdx
@@ -1,7 +1,7 @@
 <!-- markdownlint-disable first-line-heading -->
 JavaScript in Moodle is written in the ESM format, and transpiled into AMD modules for deployment.
 
-The [Moodle JavaScript Guide](../guides/javascript) has detailed information and examples on writing JavaScript in Moodle. Further information is also available in the [Javascript Modules](https://docs.moodle.org/dev/Javascript_Modules) documentation.
+The [Moodle JavaScript Guide](../guides/javascript) has detailed information and examples on writing JavaScript in Moodle. Further information is also available in the [JavaScript Modules](https://docs.moodle.org/dev/Javascript_Modules) documentation.
 
 :::caution
 
diff --git a/docs/apis/_files/yui-dir.mdx b/docs/apis/_files/yui-dir.mdx
@@ -1,5 +1,5 @@
 <!-- markdownlint-disable first-line-heading -->
-In older versions of Moodle, JavaScript was written in the YUI format. This is being phased out in favour of [Javascript Modules](https://docs.moodle.org/dev/Javascript_Modules), although some older uses still remain in Moodle core.
+In older versions of Moodle, JavaScript was written in the YUI format. This is being phased out in favour of [JavaScript Modules](https://docs.moodle.org/dev/Javascript_Modules), although some older uses still remain in Moodle core.
 
 - [YUI/Modules](https://docs.moodle.org/dev/YUI/Modules)
 - [YUI](https://docs.moodle.org/dev/YUI)
diff --git a/docs/apis/plugintypes/filter/index.md b/docs/apis/plugintypes/filter/index.md
@@ -180,7 +180,7 @@ class filter_helloworld extends moodle_text_filter {
 
 ## Filtering dynamic content
 
-It is possible that page content is loaded by ajax after the page is loaded. In certain filter types (for example MathJax) javascript is required to be run on the output of the filter in order to do the final markup. For these types of filters, a javascript event is triggered when new content is added to the page (the content will have already been processed by the filter in php). The javascript for a filter can listen for these event notifications and reprocess the affected dom nodes.
+It is possible that page content is loaded by ajax after the page is loaded. In certain filter types (for example MathJax) JavaScript is required to be run on the output of the filter in order to do the final markup. For these types of filters, a JavaScript event is triggered when new content is added to the page (the content will have already been processed by the filter in php). The JavaScript for a filter can listen for these event notifications and reprocess the affected dom nodes.
 
 The content updated event is registered in the `core_filters/events` module and can be imported as:
 
diff --git a/docs/apis/plugintypes/format/index.md b/docs/apis/plugintypes/format/index.md
@@ -176,7 +176,7 @@ However, if for some reason you cannot use the latest version of tool_pluginskel
 3. Rename language files in course/format/pluginname/lang/
 4. Change `$string['pluginname']` in course/format/pluginname/lang/en/format_pluginname.php to the new name.
 5. Rename class name in lib.php to format_pluginname.
-6. Search and replace other occurrences of the old format name, for example in renderer, capabilities names, settings, javascript libraries, etc.
+6. Search and replace other occurrences of the old format name, for example in renderer, capabilities names, settings, JavaScript libraries, etc.
 7. The new format is ready for modification.
 8. After modifying the code, check it with the Code checker.
 
@@ -594,7 +594,7 @@ And third, consider using "local/content" as your main course template, "output\
 
 ## The course editor structure
 
-The core_courseformat provides several javascript modules that will be enabled when a teacher edits the course. Those libraries use a reactive pattern to keep the course updated when some edit action is executed.
+The core_courseformat provides several JavaScript modules that will be enabled when a teacher edits the course. Those libraries use a reactive pattern to keep the course updated when some edit action is executed.
 
 The following diagram represents the data flow of the new architecture:
 
diff --git a/docs/guides/javascript/reactive/index.md b/docs/guides/javascript/reactive/index.md
@@ -1,7 +1,7 @@
 ---
 title: Creating a reactive UI
 tags:
-  - Javascript
+  - JavaScript
   - Library
   - Frontend
 ---
@@ -969,7 +969,7 @@ As can be seen in the example, the mutation does not need to enable or disable t
 
 #### Private methods inside the mutations library
 
-Javascript is famous for not having private methods. This means all the methods inside the mutations library will be accessible by the Reactive Instance. To prevent components from dispatch private methods the Reactive instance "dispatch" method will raise an expectation in some cases.
+JavaScript is famous for not having private methods. This means all the methods inside the mutations library will be accessible by the Reactive Instance. To prevent components from dispatch private methods the Reactive instance "dispatch" method will raise an expectation in some cases.
 
 Mutation names that components cannot dispatch:
 
@@ -1003,7 +1003,7 @@ When this happens, the components' stateReady hooks will be executed and the wat
 
 #### Initial state data limitations
 
-While the Javascript standard does not offer a suitable native solution for fully reactive data structures, implementing a deep reactive object will be a complex task. Depending on the depth of the changes tracked it will require many frontend resources and many lines of code to maintain. That is the main reason why most people use complex reactive frameworks for it.
+While the JavaScript standard does not offer a suitable native solution for fully reactive data structures, implementing a deep reactive object will be a complex task. Depending on the depth of the changes tracked it will require many frontend resources and many lines of code to maintain. That is the main reason why most people use complex reactive frameworks for it.
 
 To keep the state fast and simple, the reactive.js library can only store two kinds of data at the ROOT level:
 
diff --git a/docs/moodleapp/development/development-guide.md b/docs/moodleapp/development/development-guide.md
@@ -377,7 +377,7 @@ All the nomenclature can be a bit confusing, so let's do a recap:
 
 ## Application Lifecycle
 
-When the application is launched, the contents of [index.html](#indexhtml) are rendered on screen. This file is intentionally concise because all the flare is added by Javascript, and the splash screen will be covering the application UI until it has fully started. If you are developing in the browser, this will be a blank screen for you given that the splash screen is not available on the web. We are not targeting browsers in production, so it's acceptable to have this behaviour during development.
+When the application is launched, the contents of [index.html](#indexhtml) are rendered on screen. This file is intentionally concise because all the flare is added by JavaScript, and the splash screen will be covering the application UI until it has fully started. If you are developing in the browser, this will be a blank screen for you given that the splash screen is not available on the web. We are not targeting browsers in production, so it's acceptable to have this behaviour during development.
 
 Before the UI is rendered, the startup process will take place. First, Angular will instantiate `AppModule` and all the imported modules (features, addons, etc.), and then it will execute the initializers (this includes all the initializers, not only the ones declared under [core/initializers/](#coreinitializers)). In our application, we have overridden [Angular's initialisation service](https://angular.io/api/core/ApplicationInitStatus) to get a hold of the root injector so that we can safely use the [Service Singletons](#service-singletons) pattern within initializers. However, we should avoid this pattern within constructors, because those can be called during the instantiation phase.
 
diff --git a/docs/moodleapp/development/plugins-development-guide/index.md b/docs/moodleapp/development/plugins-development-guide/index.md
@@ -1360,7 +1360,7 @@ this.MyAddonClass
 
 A link handler allows you to decide what to do when a link with a certain URL is clicked. This is useful, for example, to open your plugin page when a link to your plugin is clicked.
 
-After the 4.0 version, the Moodle app automatically creates two link handlers for module plugins, you don't need to create them in your plugin's Javascript code anymore:
+After the 4.0 version, the Moodle app automatically creates two link handlers for module plugins, you don't need to create them in your plugin's JavaScript code anymore:
 
 - A handler to treat links to *mod/pluginname/view.php?id=X*. When this link is clicked, it will open your module in the app.
 - A handler to treat links to *mod/pluginname/index.php?id=X*. When this link is clicked, it will open a page in the app listing all the modules of your type inside a certain course.
diff --git a/docs/moodleapp/development/release-process.md b/docs/moodleapp/development/release-process.md
@@ -19,7 +19,7 @@ tags:
 | 6. | Contact the marketing team announcing the new release and highlights. | Integration Lead |
 | 7. | Add new QA tests to the "Testing cases" document. New QA tests should be labeled with [qa_test_required](https://tracker.moodle.org/issues/?jql=project%20%3D%20MOBILE%20AND%20resolution%20in%20(Unresolved%2C%20Fixed)%20AND%20labels%20%3D%20qa_test_required%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC). Remove that label once are added to the document. | Tester |
 | 8. | Run `npm audit` to ensure all the dependencies are OK and check github vulnerabilities report. | Developer |
-| 9. | Freeze Cordova plugins and Javascript libraries versions (node modules) in the integration branch. | Developer |
+| 9. | Freeze Cordova plugins and JavaScript libraries versions (node modules) in the integration branch. | Developer |
 | 10. | **Start testing** | Tester |
 
 ## The release day
@@ -43,7 +43,7 @@ tags:
 | 3. | Review the users and developers documentation (check that everything is in order). Review the [docs_required and dev_docs_required_tags](https://tracker.moodle.org/issues/?jql=project%20%3D%20MOBILE%20AND%20labels%20in%20%28docs_required%2C%20dev_docs_required%29). Review the [Mobile features wiki documentation](https://docs.moodle.org/en/Moodle_Mobile_features). | All the team |
 | 4. | Delete the integration and desktop branches and create it again based on master. | Team Lead |
 | 5. | Bump version numbers in the following files in the integration branch: `config.xml` (version), `package.json` (version), `moodle.config.json` (versionname) appending a `-dev` to indicate that is a development version). | Integration Lead |
-| 6. | Unfreeze Cordova plugins and Javascript libraries versions (node modules). | Developer |
+| 6. | Unfreeze Cordova plugins and JavaScript libraries versions (node modules). | Developer |
 | 7. | Check that the [Docker image](https://cloud.docker.com/u/moodlehq/repository/docker/moodlehq/moodleapp/general) for the new version was successfully built. | Integration Lead |
 | 8. | Update of the [local_moodlemobileapp](https://moodle.org/plugins/view.php?id=997) plugin (as final release) in moodle.org/plugins. | Developer |
 
diff --git a/docs/moodleapp/overview.md b/docs/moodleapp/overview.md
@@ -61,7 +61,7 @@ The app has two types of delegates:
 
 Moodle plugins can also be adapted to work with the mobile app. Given that more than one site can be used with the app, the plugins that are activated depend on the site the app is connected to. That's why they are called site plugins.
 
-When the application connects with a site, it will fetch information about which plugins have mobile support and register their functionality using [the delegates system](#delegates-and-handlers). Plugins can be written using only PHP, but javascript is also supported for some advanced use-cases.
+When the application connects with a site, it will fetch information about which plugins have mobile support and register their functionality using [the delegates system](#delegates-and-handlers). Plugins can be written using only PHP, but JavaScript is also supported for some advanced use-cases.
 
 ## Platform Support
 
diff --git a/general/community/credits/thirdpartylibs.md b/general/community/credits/thirdpartylibs.md
@@ -320,7 +320,7 @@ This library is not currently used in Moodle
 
 :::note lib/editor
 
-Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla
+JavaScript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla
 
 **Version**: 3.0 beta (with modifications)<br/>
 **License**: htmlArea License (based on BSD license)
@@ -763,7 +763,7 @@ This library is not currently used in Moodle
 
 :::note lib/overlib.js
 
-Javascript library to enable DHTML popups, floating windows, events etc
+JavaScript library to enable DHTML popups, floating windows, events etc
 
 **Version**: July 2004<br/>
 **License**: Artistic Open Source License
@@ -779,7 +779,7 @@ Copyright © 1998-2004 Erik Bosrup
 
 :::note media/player/videojs/amd/src/local/ogv/ogv.js
 
-Javascript media decoder and player for Ogg Vorbis/Opus/Theora and WebM VP8/VP9/AV1 video.
+JavaScript media decoder and player for Ogg Vorbis/Opus/Theora and WebM VP8/VP9/AV1 video.
 
 **Version**: 1.8.4<br/>
 **License**: MIT
diff --git a/general/development/policies.md b/general/development/policies.md
@@ -72,15 +72,15 @@ This helps consistency across browsers in a nicely-degrading way (especially tho
 
 ## JavaScript
 
-New Javascript in Moodle should be written as Vanilla javascript in the ES6 style. The use of jQuery, YUI, and other frameworks is strongly discouraged and will not be accepted into core except when dealing with legacy interfaces which require the use of those objects.
+New JavaScript in Moodle should be written as Vanilla JavaScript in the ES6 style. The use of jQuery, YUI, and other frameworks is strongly discouraged and will not be accepted into core except when dealing with legacy interfaces which require the use of those objects.
 
 In general code should be written to avoid displaying interfaces which are removed, or adding new interfaces as the page loads.
 
-All Javascript must be accessible.
+All JavaScript must be accessible.
 
 :::info
 
-For more about this, see the [Javascript guide](/docs/guides/javascript).
+For more about this, see the [JavaScript guide](/docs/guides/javascript).
 
 :::
 
diff --git a/general/development/policies/accessibility.md b/general/development/policies/accessibility.md
@@ -106,7 +106,7 @@ In some cases, a single component can contain many smaller components. In order
 
 ### Forms
 
-Moodle forms created with the standard forms library are designed to be accessible. Any custom (for example javascript) form or custom form elements must also be accessible.
+Moodle forms created with the standard forms library are designed to be accessible. Any custom (for example JavaScript) form or custom form elements must also be accessible.
 
 - All form elements must have a label
 - The form must be able to be completed entirely with the keyboard
@@ -133,7 +133,7 @@ See [the WCAG 2.1 success criteria for web page titles](https://www.w3.org/TR/WC
 
 ### Advanced UX Widgets
 
-When it is determined that an advanced interface is required (typically one that relies on javascript), a minimum set of principles need to be applied to make sure that the feature "provides equal functionality and information to all people". Each use case is different, but a minimum set of things to be checked are:
+When it is determined that an advanced interface is required (typically one that relies on JavaScript), a minimum set of principles need to be applied to make sure that the feature "provides equal functionality and information to all people". Each use case is different, but a minimum set of things to be checked are:
 
 - Does this component work entirely when accessed only via the keyboard?
 - Does this component map to any widget from the [ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices-1.1/) document and if so, does it implement all of the "Keyboard Interaction" and "WAI-ARIA Roles, States and Properties" listed for that widget?
diff --git a/general/development/policies/codingstyle/index.md b/general/development/policies/codingstyle/index.md
@@ -1875,7 +1875,7 @@ This document was drawn from the following sources:
 
 ## See also
 
-- [Javascript Coding Style](https://docs.moodle.org/dev/Javascript/Coding_Style)
+- [JavaScript Coding Style](https://docs.moodle.org/dev/Javascript/Coding_Style)
 - [CSS Coding Style](https://docs.moodle.org/dev/CSS_Coding_Style)
 - [SQL coding style](https://docs.moodle.org/dev/SQL_coding_style)
 - [Coding](/general/development/policies)
diff --git a/general/development/policies/component-communication/index.md b/general/development/policies/component-communication/index.md
@@ -48,7 +48,7 @@ There are different ways to call code in Moodle. Most of them are listed here an
 
 - Direct php function calls
 - External functions
-- Javascript Modules (AMD)
+- JavaScript Modules (AMD)
 - Templates
 - get_string calls
 - Event observers
@@ -88,9 +88,9 @@ Additional rules for calling external functions:
 
 - Always use the `external_api::call_external_function()` wrapper when calling from php.
 
-### Javascript Modules (AMD)
+### JavaScript Modules (AMD)
 
-It is possible through the Javascript loader to load an AMD module from any component and call its functions. This is a form of inter-component communication and must obey the strict rules for which components AMD modules can be loaded from.
+It is possible through the JavaScript loader to load an AMD module from any component and call its functions. This is a form of inter-component communication and must obey the strict rules for which components AMD modules can be loaded from.
 
 ### get_string
 
diff --git a/general/development/policies/naming.md b/general/development/policies/naming.md
@@ -6,7 +6,7 @@ tags:
 
 ## Components
 
-## Javascript
+## JavaScript
 
 ## Web services
 
diff --git a/general/development/policies/security/index.md b/general/development/policies/security/index.md
@@ -86,15 +86,15 @@ Teachers are usually creating course content, enrolling students and teaching. T
 - Create and manage activities
 - Access student grades and other personal information
 
-Uploading of files with javascript, flash and other scripted is often considered to be a security risk. Unfortunately we can not remove these risks from teacher roles because even basic SCORM packages consist of HTML and Javascript which needs to use user session.
+Uploading of files with JavaScript, flash and other scripted is often considered to be a security risk. Unfortunately we can not remove these risks from teacher roles because even basic SCORM packages consist of HTML and JavaScript which needs to use user session.
 
 Browser trusts everything coming from one server, it does not know anything about our courses or origin of data. Once the file is uploaded to server it becomes part of the server application. It is not possible to differentiate between wanted and unwanted code stored on the server.
 
 :::info
 
 All teachers with risky capabilities have to be trusted, it is not possible to give teacher access to students. In theory teachers may use XSS attacks to gain administrator access.
 
-Technically it would be possible to create a system where teachers can not attack other users but it would prevent all Javascript, Flash, SCORM, Java, HTML forms, SVG, etc.
+Technically it would be possible to create a system where teachers can not attack other users but it would prevent all JavaScript, Flash, SCORM, Java, HTML forms, SVG, etc.
 
 :::
 
@@ -109,7 +109,7 @@ Uploaded files must not be opened directly in browser from the same server. Inst
 
 :::info
 
-All student submitted text has to be sanitised before printing the text on any page, this prevent XSS attacks on other users but at the same time prevents Flash, Javascript, SVG and all other HTML scripting. Moodle uses HTML Purifier library for this purpose.
+All student submitted text has to be sanitised before printing the text on any page, this prevent XSS attacks on other users but at the same time prevents Flash, JavaScript, SVG and all other HTML scripting. Moodle uses HTML Purifier library for this purpose.
 
 :::
 
diff --git a/general/development/process/peer-review.md b/general/development/process/peer-review.md
@@ -48,7 +48,7 @@ To allow the community of Moodle developers to work together, conventions should
 - $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used.
 
 :::tip
-See the [Coding style guide](/general/development/policies/codingstyle) for details. Most of the previous items list are checked automatically by the CiBot (Automated code review). So in this case it's recommended to review the execution results to validate that there aren't errors. However, take into account that for now, CiBot is not checking all file types (it happens, for instance, with the Javascript files).
+See the [Coding style guide](/general/development/policies/codingstyle) for details. Most of the previous items list are checked automatically by the CiBot (Automated code review). So in this case it's recommended to review the execution results to validate that there aren't errors. However, take into account that for now, CiBot is not checking all file types (it happens, for instance, with the JavaScript files).
 :::
 
 ### Output
diff --git a/general/releases/2.0.md b/general/releases/2.0.md
diff --git a/general/releases/2.9.md b/general/releases/2.9.md
diff --git a/versioned_docs/version-4.0/policy/naming.md b/versioned_docs/version-4.0/policy/naming.md
