Improve clarity of the FAQ entry

docs/apis/subsystems/privacy/faq.md

@@ -64,6 +64,6 @@ You can ultimately work out which enrol plugin a user is enrolled with, but the
 
 ## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do?
 
-You need to implement *\core_privacy\local\metadata\provider* so that you can describe the sub-systems used by your plugin in *get_metadata*.
+You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider.
 
 The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.

versioned_docs/version-4.1/apis/subsystems/privacy/faq.md

@@ -64,6 +64,6 @@ You can ultimately work out which enrol plugin a user is enrolled with, but the
 
 ## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do?
 
-You need to implement *\core_privacy\local\metadata\provider* so that you can describe the sub-systems used by your plugin in *get_metadata*.
+You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider.
 
 The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.

versioned_docs/version-4.2/apis/subsystems/privacy/faq.md

@@ -64,6 +64,6 @@ You can ultimately work out which enrol plugin a user is enrolled with, but the
 
 ## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do?
 
-You need to implement *\core_privacy\local\metadata\provider* so that you can describe the sub-systems used by your plugin in *get_metadata*.
+You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider.
 
 The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.

versioned_docs/version-4.3/apis/subsystems/privacy/faq.md

@@ -64,6 +64,6 @@ You can ultimately work out which enrol plugin a user is enrolled with, but the
 
 ## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do?
 
-You need to implement *\core_privacy\local\metadata\provider* so that you can describe the sub-systems used by your plugin in *get_metadata*.
+You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider.
 
 The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.

versioned_docs/version-4.4/apis/subsystems/privacy/faq.md

@@ -64,6 +64,6 @@ You can ultimately work out which enrol plugin a user is enrolled with, but the
 
 ## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do?
 
-You need to implement *\core_privacy\local\metadata\provider* so that you can describe the sub-systems used by your plugin in *get_metadata*.
+You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider.
 
 The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.