String API - Revision history

Stronk7: master2main

2024-04-10T11:13:13Z

master2main

← Older revision		Revision as of 11:13, 10 April 2024
Line 209:		Line 209:

	===Changing or creating a new lang string?===		===Changing or creating a new lang string?===
	New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in ~~master~~, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but this is considered to be the lang pack bug.		New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in main, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but this is considered to be the lang pack bug.

	When a new string is introduced, the old one should be [[String deprecation \| deprecated or removed]] so that unused strings do not accumulate.		When a new string is introduced, the old one should be [[String deprecation \| deprecated or removed]] so that unused strings do not accumulate.
	:A) Basically I see it as (for ~~master~~ only issues):		:A) Basically I see it as (for main only issues):
	:		:
	:# Any change is allowed (semantic or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).		:# Any change is allowed (semantic or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).
Line 220:		Line 220:
	:#* But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.		:#* But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.

	:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to ~~master~~, these changes will also imply the [[String deprecation \| standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).		:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to main, these changes will also imply the [[String deprecation \| standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).
	===User names placeholders===		===User names placeholders===
	Some strings may contain placeholders to display the user's name. Common examples include various email templates or welcome messages. Developers may be tempted to use just the user's firstname in such cases, to make the text feel informal and friendlier:		Some strings may contain placeholders to display the user's name. Common examples include various email templates or welcome messages. Developers may be tempted to use just the user's firstname in such cases, to make the text feel informal and friendlier:

Tsala: /* Help strings */ stringname_link update - MDLSITE-7236

2024-01-16T09:08:24Z

Help strings: stringname_link update - MDLSITE-7236

← Older revision		Revision as of 09:08, 16 January 2024
Line 36:		Line 36:
	* ''stringname'' - identifier of the string we provide the help for, may be used as a title of the help popup		* ''stringname'' - identifier of the string we provide the help for, may be used as a title of the help popup
	* ''stringname_help'' - string with the help text		* ''stringname_help'' - string with the help text
	* ''stringname_link'' - an optional string naming a path in Moodle Docs, only if required, calculated just like the link in the footer to go to the right language etc, and shown after the help text in the popup as a link with an icon to "More help...". These strings don't need to be translated~~, so are~~ hidden in the AMOS UI ~~(with the exception of some TinyMCE strings~~).		* ''stringname_link'' - an optional string naming a path in Moodle Docs, only if required, calculated just like the link in the footer to go to the right language etc, and shown after the help text in the popup as a link with an icon to "More help...". These strings don't usually need to be translated. (They were previously hidden in the AMOS UI then unhidden in 2023. See MDLSITE-7236 for details.)
	* ''stringname_desc'' - an admin setting description replacing the legacy ''configstringname''		* ''stringname_desc'' - an admin setting description replacing the legacy ''configstringname''
	Example:		Example:

Tsala: /* Help strings */ _link strings hidden in AMOS (MDLSITE-7236)

2023-05-03T05:38:41Z

Help strings: _link strings hidden in AMOS (MDLSITE-7236)

← Older revision		Revision as of 05:38, 3 May 2023
Line 36:		Line 36:
	* ''stringname'' - identifier of the string we provide the help for, may be used as a title of the help popup		* ''stringname'' - identifier of the string we provide the help for, may be used as a title of the help popup
	* ''stringname_help'' - string with the help text		* ''stringname_help'' - string with the help text
	* ''stringname_link'' - an optional string naming a path in Moodle Docs, only if required, calculated just like the link in the footer to go to the right language etc, and shown after the help text in the popup as a link with an icon to "More help..."		* ''stringname_link'' - an optional string naming a path in Moodle Docs, only if required, calculated just like the link in the footer to go to the right language etc, and shown after the help text in the popup as a link with an icon to "More help...". These strings don't need to be translated, so are hidden in the AMOS UI (with the exception of some TinyMCE strings).
	* ''stringname_desc'' - an admin setting description replacing the legacy ''configstringname''		* ''stringname_desc'' - an admin setting description replacing the legacy ''configstringname''
	Example:		Example:
Line 71:		Line 71:
	* Users - people across the site		* Users - people across the site
	([[User:Martin Dougiamas\|Martin Dougiamas]] 16:13, 20 April 2010 (UTC): I'm not entirely comfortable with this choice even though I just re-confirmed it, as I'd prefer to be using words like facilitator/moderator to subtly and continually promote a less transmissionist pedgagogy and I know many Moodle users would agree. However, I think these terms are far more commonly used in the community and in discussion, and from the point of view that we need to build a consistent system for usability they are less distracting and better for documentation.)		([[User:Martin Dougiamas\|Martin Dougiamas]] 16:13, 20 April 2010 (UTC): I'm not entirely comfortable with this choice even though I just re-confirmed it, as I'd prefer to be using words like facilitator/moderator to subtly and continually promote a less transmissionist pedgagogy and I know many Moodle users would agree. However, I think these terms are far more commonly used in the community and in discussion, and from the point of view that we need to build a consistent system for usability they are less distracting and better for documentation.)

	==Files==		==Files==
	String functions are defined in		String functions are defined in

Brendanheywood: /* Should the colon sign be hard-coded or included in a language string? */

2022-05-23T01:50:31Z

Should the colon sign be hard-coded or included in a language string?

Show changes

Mudrd8mz: /* FAQ */ Add section on using user names in string placeholders

2021-09-29T20:11:00Z

FAQ: Add section on using user names in string placeholders

← Older revision		Revision as of 20:11, 29 September 2021
Line 252:		Line 252:

	:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to master, these changes will also imply the [[String deprecation \| standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).		:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to master, these changes will also imply the [[String deprecation \| standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).

			===User names placeholders===

			Some strings may contain placeholders to display the user's name. Common examples include various email templates or welcome messages. Developers may be tempted to use just the user's firstname in such cases, to make the text feel informal and friendlier:

			<syntaxhighlight lang="php">
			// Do NOT do this.
			$string['welcome'] = 'Hello {$a}! Welcome to the course.';
			</syntaxhighlight>

			But some cultures or institutions may want the full name or last name to be used, rather than the first name. To enable sites to easily customise such strings and have lastname and alternatename placeholders available, the following pattern should be used.

			Let the language strings file for the given component define the default display of the name:

			<syntaxhighlight lang="php">
			$string['welcome'] = 'Hello {$a->firstname}! Welcome to the course.';
			</syntaxhighlight>

			Then in the file making use of the string:

			<syntaxhighlight lang="php">
			$namefields = [
			'fullname' => fullname($USER),
			'alternativefullname' => fullname($USER, true),
			];

			foreach (\core_user\fields::get_name_fields() as $namefield) {
			$namefields[$namefield] = $USER->{$namefield};
			}

			echo get_string('welcome', 'xyz_component', $namefields);
			</syntaxhighlight>

			That way, the string can be locally customised and use any combination of the following placeholders as needed: firstnamephonetic, lastnamephonetic, middlename, alternatename, firstname, lastname, fullname and alternativefullname.

			<syntaxhighlight lang="php">
			// Locally customised variant of the string.
			$string['welcome'] = 'Welcome to the course, {$a->fullname}';
			</syntaxhighlight>

	==See also==		==See also==

Tsala: /* Changing or creating a new lang string? */

2021-09-27T13:30:40Z

Changing or creating a new lang string?

← Older revision		Revision as of 13:30, 27 September 2021
Line 239:		Line 239:
	===Changing or creating a new lang string?===		===Changing or creating a new lang string?===

	New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in master, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but is is considered to be the lang pack bug.		New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in master, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but this is considered to be the lang pack bug.

	When a new string is introduced, the old one should be [[String deprecation \| deprecated or removed]] so that unused strings do not accumulate.		When a new string is introduced, the old one should be [[String deprecation \| deprecated or removed]] so that unused strings do not accumulate.

Tsala: /* FAQ */ Changing or creating a new lang string? comments from Eloy copied from Talk:Improving English language strings

2021-09-10T12:34:19Z

FAQ: Changing or creating a new lang string? comments from Eloy copied from Talk:Improving English language strings

← Older revision		Revision as of 12:34, 10 September 2021
Line 235:		Line 235:
	===Should the colon sign be hard-coded or included in a language string?===		===Should the colon sign be hard-coded or included in a language string?===

	The colon sign should not be hard-coded because languages may use a different symbol, or have a space before or after the colon sign.		The colon sign should not be hard-coded because languages may use a different symbol, or have a space before or after the colon sign. Instead, the colon sign may be included in a language string, though please consider first if it is really necessary. A colon sign in a field label is not recommended. (MDL-12192 is for removing existing hard-coded colon signs.)

	~~Instead, the colon sign may be included in~~ a ~~language~~ string~~, though please consider first if it is really necessary. A colon sign in a field label is not recommended.~~		===Changing or creating a new lang string?===

	(~~MDL~~-~~12192~~ is for ~~removing~~ existing ~~hard-coded colon signs~~.)		New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in master, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but is is considered to be the lang pack bug.

			When a new string is introduced, the old one should be [[String deprecation \| deprecated or removed]] so that unused strings do not accumulate.

			:A) Basically I see it as (for master only issues):
			:
			:# Any change is allowed (semantic or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).
			:# If for any reason we stop using any string (because a feature is out or because we have decided to create a new different string instead of change existing)), then:
			:#* if the old string is really specific (not suitable for reuse) we can safely proceed to delete it,.
			:#* If the string belongs to a plugin, IMO we can also proceed to delete it (reuse of plugin strings should not be allowed).
			:#* But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.

			:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to master, these changes will also imply the [[String deprecation \| standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).

	==See also==		==See also==

Tsala: /* See also */ links update

2021-09-10T12:30:51Z

Mudrd8mz: Text replacement - "" to ""

2021-07-14T20:04:31Z

Text replacement - "</code>" to "</syntaxhighlight>"

← Older revision		Revision as of 20:04, 14 July 2021
Line 24:		Line 24:
	$string['editingquiz'] = 'Editing quiz';		$string['editingquiz'] = 'Editing quiz';
	$string['editingquiz_help'] = 'Help for editing quiz';		$string['editingquiz_help'] = 'Help for editing quiz';
	</~~code~~>		</syntaxhighlight>

	===Run-time parameters===		===Run-time parameters===
Line 38:		Line 38:
	echo get_string('greeting', 'tool_example', 'Mr. Anderson');		echo get_string('greeting', 'tool_example', 'Mr. Anderson');
	echo get_string('info', 'tool_example', ['count' => 42, 'from' => 'Mr. Smith']);		echo get_string('info', 'tool_example', ['count' => 42, 'from' => 'Mr. Smith']);
	</~~code~~>		</syntaxhighlight>

	== Help strings ==		== Help strings ==
Line 58:		Line 58:
	$string['submissionsize_link'] = 'mod/workshop/submission';		$string['submissionsize_link'] = 'mod/workshop/submission';
	$string['submissionsize_desc'] = 'Default value for submission size. This value will be pre-filled and can be blah blah ...';		$string['submissionsize_desc'] = 'Default value for submission size. This value will be pre-filled and can be blah blah ...';
	</~~code~~>		</syntaxhighlight>

	Help string text should be short and simple - two small paragraphs maximum with no headings, no links, no bold, no tables etc.		Help string text should be short and simple - two small paragraphs maximum with no headings, no links, no bold, no tables etc.
Line 72:		Line 72:
	<syntaxhighlight lang="php">		<syntaxhighlight lang="php">
	$string['groupimport_link'] = 'group/import';		$string['groupimport_link'] = 'group/import';
	</~~code~~>		</syntaxhighlight>

	will make a link to something like <nowiki>'https://docs.moodle.org/32/en/group/import'</nowiki> (if you are an English user of Moodle 3.2). This page in turn should be a redirect page to the actual page providing the info. Note the <nowiki>'https://docs.moodle.org'</nowiki> part comes from $CFG->docroot.		will make a link to something like <nowiki>'https://docs.moodle.org/32/en/group/import'</nowiki> (if you are an English user of Moodle 3.2). This page in turn should be a redirect page to the actual page providing the info. Note the <nowiki>'https://docs.moodle.org'</nowiki> part comes from $CFG->docroot.
Line 80:		Line 80:
	<syntaxhighlight lang="php">		<syntaxhighlight lang="php">
	$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>		$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>
	</~~code~~>		</syntaxhighlight>

	This case is detected by seeing if the string starts with <nowiki>http:// or https://</nowiki>. This option is useful if the documentation for your plugin is hosted at Github wiki, for example.		This case is detected by seeing if the string starts with <nowiki>http:// or https://</nowiki>. This option is useful if the documentation for your plugin is hosted at Github wiki, for example.
Line 155:		Line 155:
	<syntaxhighlight lang="php">		<syntaxhighlight lang="php">
	$stringman = get_string_manager();		$stringman = get_string_manager();
	</~~code~~>		</syntaxhighlight>

	The factory function get_string_manager() returns singleton instance of <tt>core_string_manager_install</tt> in early stages of the site installation, or instance of <tt>core_string_manager_standard</tt> in all normal situations. These managers implement interface <tt>core_string_manager</tt>. Methods provided by the interface are		The factory function get_string_manager() returns singleton instance of <tt>core_string_manager_install</tt> in early stages of the site installation, or instance of <tt>core_string_manager_standard</tt> in all normal situations. These managers implement interface <tt>core_string_manager</tt>. Methods provided by the interface are
Line 166:		Line 166:
	// Do something.		// Do something.
	}		}
	</~~code~~>		</syntaxhighlight>

	;string_deprecated():Has the string been deprecated? See [[String deprecation]] for details.		;string_deprecated():Has the string been deprecated? See [[String deprecation]] for details.
Line 185:		Line 185:
	// Custom string manager class can be defined in the main config.php file.		// Custom string manager class can be defined in the main config.php file.
	$CFG->customstringmanager = '\local_stringman\dummy_string_manager';		$CFG->customstringmanager = '\local_stringman\dummy_string_manager';
	</~~code~~>		</syntaxhighlight>

	==textlib (core_text) class==		==textlib (core_text) class==

Mudrd8mz: Text replacement - "`" to ""`


2021-07-14T13:37:00Z
Text replacement - "<code php>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:37, 14 July 2021
				
Line 21:
Line 21:
Strings are defined via the associative array <tt>$string</tt> provided by the string file. The array key is the string identifier, the value is the string text in the given language. Strings are defined via the associative array <tt>$string</tt> provided by the string file. The array key is the string identifier, the value is the string text in the given language.



<code php> <syntaxhighlight lang="php">
$string['editingquiz'] = 'Editing quiz'; $string['editingquiz'] = 'Editing quiz';
$string['editingquiz_help'] = 'Help for editing quiz'; $string['editingquiz_help'] = 'Help for editing quiz';
Line 30:
Line 30:
Strings can define placeholders like <tt>{$a}</tt> or <tt>{$a->foobar}</tt>. These placeholders are replaced with a value passed to the <tt>get_string()</tt> function call. Strings can define placeholders like <tt>{$a}</tt> or <tt>{$a->foobar}</tt>. These placeholders are replaced with a value passed to the <tt>get_string()</tt> function call.



<code php> <syntaxhighlight lang="php">
// Strings defined in the language file. // Strings defined in the language file.
$string['greeting'] = 'Dear {$a}'; $string['greeting'] = 'Dear {$a}';
Line 53:
Line 53:
Example: Example:



<code php> <syntaxhighlight lang="php">
$string['submissionsize'] = 'Submission size'; $string['submissionsize'] = 'Submission size';
$string['submissionsize_help'] = 'Blah blah blah some useful text, optionally using Markdown syntax'; $string['submissionsize_help'] = 'Blah blah blah some useful text, optionally using Markdown syntax';
Line 70:
Line 70:
Example: Example:



<code php> <syntaxhighlight lang="php">
$string['groupimport_link'] = 'group/import'; $string['groupimport_link'] = 'group/import';
</code> </code>
Line 78:
Line 78:
The second option is that you can give an absolute link, if you want, and that will be used unmodified. The second option is that you can give an absolute link, if you want, and that will be used unmodified.



<code php> <syntaxhighlight lang="php">
$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki> $string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>
</code> </code>
Line 153:
Line 153:
Most of function listed above are just handful wrappers for the methods provided by the string manager class. Some strings related functionality is available only via directly calling the manager's methods. Most of function listed above are just handful wrappers for the methods provided by the string manager class. Some strings related functionality is available only via directly calling the manager's methods.



<code php> <syntaxhighlight lang="php">
$stringman = get_string_manager(); $stringman = get_string_manager();
</code> </code>
Line 162:
Line 162:
;string_exists():Does the given string actually exist? This is typically checked by a code like ;string_exists():Does the given string actually exist? This is typically checked by a code like



<code php> <syntaxhighlight lang="php">
if (get_string_manager()->string_exists('stringidentifier', 'component_name')) { if (get_string_manager()->string_exists('stringidentifier', 'component_name')) {
     // Do something.      // Do something.
Line 182:
Line 182:
{{Moodle 2.9}}Plugins can provide custom implementation of the string manager. This is supposed to be used in experimental and/or development scenarios only, not in typical production environment. See MDL-49361 for use cases and implementation details. An example of such an implementation can be found at [https://github.com/mudrd8mz/moodle-local_stringman moodle-local_stringman.git] repository. {{Moodle 2.9}}Plugins can provide custom implementation of the string manager. This is supposed to be used in experimental and/or development scenarios only, not in typical production environment. See MDL-49361 for use cases and implementation details. An example of such an implementation can be found at [https://github.com/mudrd8mz/moodle-local_stringman moodle-local_stringman.git] repository.



<code php> <syntaxhighlight lang="php">
// Custom string manager class can be defined in the main config.php file. // Custom string manager class can be defined in the main config.php file.
$CFG->customstringmanager = '\local_stringman\dummy_string_manager'; $CFG->customstringmanager = '\local_stringman\dummy_string_manager';

← Older revision		Revision as of 12:30, 10 September 2021
Line 244:		Line 244:
	* [[Output_functions]]		* [[Output_functions]]
	* [[Core APIs]]		* [[Core APIs]]
	* [[~~Languages~~]]		* [[AMOS]]
	* [[~~Languages/AMOS~~]]		* The section 'Language strings' in [[Coding style]]
			* [[String deprecation]]
			* [[Improving English language strings]]

	[[Category:API]]		[[Category:API]]
			[[Category:Language]]

← Older revision		Revision as of 13:37, 14 July 2021
Line 21:		Line 21:
	Strings are defined via the associative array <tt>$string</tt> provided by the string file. The array key is the string identifier, the value is the string text in the given language.		Strings are defined via the associative array <tt>$string</tt> provided by the string file. The array key is the string identifier, the value is the string text in the given language.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$string['editingquiz'] = 'Editing quiz';		$string['editingquiz'] = 'Editing quiz';
	$string['editingquiz_help'] = 'Help for editing quiz';		$string['editingquiz_help'] = 'Help for editing quiz';
Line 30:		Line 30:
	Strings can define placeholders like <tt>{$a}</tt> or <tt>{$a->foobar}</tt>. These placeholders are replaced with a value passed to the <tt>get_string()</tt> function call.		Strings can define placeholders like <tt>{$a}</tt> or <tt>{$a->foobar}</tt>. These placeholders are replaced with a value passed to the <tt>get_string()</tt> function call.

	<~~code~~ php>		<syntaxhighlight lang="php">
	// Strings defined in the language file.		// Strings defined in the language file.
	$string['greeting'] = 'Dear {$a}';		$string['greeting'] = 'Dear {$a}';
Line 53:		Line 53:
	Example:		Example:

	<~~code~~ php>		<syntaxhighlight lang="php">
	$string['submissionsize'] = 'Submission size';		$string['submissionsize'] = 'Submission size';
	$string['submissionsize_help'] = 'Blah blah blah some useful text, optionally using Markdown syntax';		$string['submissionsize_help'] = 'Blah blah blah some useful text, optionally using Markdown syntax';
Line 70:		Line 70:
	Example:		Example:

	<~~code~~ php>		<syntaxhighlight lang="php">
	$string['groupimport_link'] = 'group/import';		$string['groupimport_link'] = 'group/import';
	</code>		</code>
Line 78:		Line 78:
	The second option is that you can give an absolute link, if you want, and that will be used unmodified.		The second option is that you can give an absolute link, if you want, and that will be used unmodified.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>		$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>
	</code>		</code>
Line 153:		Line 153:
	Most of function listed above are just handful wrappers for the methods provided by the string manager class. Some strings related functionality is available only via directly calling the manager's methods.		Most of function listed above are just handful wrappers for the methods provided by the string manager class. Some strings related functionality is available only via directly calling the manager's methods.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$stringman = get_string_manager();		$stringman = get_string_manager();
	</code>		</code>
Line 162:		Line 162:
	;string_exists():Does the given string actually exist? This is typically checked by a code like		;string_exists():Does the given string actually exist? This is typically checked by a code like

	<~~code~~ php>		<syntaxhighlight lang="php">
	if (get_string_manager()->string_exists('stringidentifier', 'component_name')) {		if (get_string_manager()->string_exists('stringidentifier', 'component_name')) {
	// Do something.		// Do something.
Line 182:		Line 182:
	{{Moodle 2.9}}Plugins can provide custom implementation of the string manager. This is supposed to be used in experimental and/or development scenarios only, not in typical production environment. See MDL-49361 for use cases and implementation details. An example of such an implementation can be found at [https://github.com/mudrd8mz/moodle-local_stringman moodle-local_stringman.git] repository.		{{Moodle 2.9}}Plugins can provide custom implementation of the string manager. This is supposed to be used in experimental and/or development scenarios only, not in typical production environment. See MDL-49361 for use cases and implementation details. An example of such an implementation can be found at [https://github.com/mudrd8mz/moodle-local_stringman moodle-local_stringman.git] repository.

	<~~code~~ php>		<syntaxhighlight lang="php">
	// Custom string manager class can be defined in the main config.php file.		// Custom string manager class can be defined in the main config.php file.
	$CFG->customstringmanager = '\local_stringman\dummy_string_manager';		$CFG->customstringmanager = '\local_stringman\dummy_string_manager';