Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split language strings to store label and help text separately #228

Open
dregad opened this issue Jun 13, 2017 · 3 comments
Open

Split language strings to store label and help text separately #228

dregad opened this issue Jun 13, 2017 · 3 comments

Comments

@dregad
Copy link
Member

dregad commented Jun 13, 2017

Following discussion with @obmsch in #215.

The general idea is to refactor existing labels for the repository update form, such as

$s_plugin_SourceGithub_master_branch = 'Primary Branches<br/><span class="small">(comma-separated list or "*" for all branches)</span>';

into 2 distinct strings

$s_plugin_SourceGithub_master_branch = 'Primary Branches';
$s_plugin_SourceGithub_master_branch_help = '<span class="small">(comma-separated list or "*" for all branches)</span>';

This would require an additional lookup at least in all $t_vcs->update_repo_form( $t_repo ) variants, for a key (help) which may (intentionally) not exist.

@obmsch
Copy link
Contributor

obmsch commented Jun 14, 2017

What about something like:

function plugin_lang_get_with_help( $p_name, $p_basename = null ) {
	$t_string = plugin_lang_get( $p_name, $p_basename );
	$t_help_string = plugin_lang_get_defaulted( $p_name . "_help", "", $p_basename );
	if( !empty( $t_help_string ) ) {
		$t_string .= "<br/>" . $t_help_string;
	}

	return $t_string;
}

and call that instead of "plugin_lang_get" where appropriate.

@atrol
Copy link
Member

atrol commented Jun 14, 2017

Concerning function plugin_lang_get_with_help

Plugins are not the right place to introduce some kind of help concept.
Such a concept should be introduced in Mantis core.

The help string should not be part of the returned string, as the caller would not be able to decide what to do with the help string.
e.g. it should be possible to decide if you want display the help in a tool tip, or if you want to use it in a text area field as a place holder string.

I am not sure if it's a good idea to link help strings to our existing message identifiers.
Maybe it's better to link them to identifiers of visible UI elements (the same id's that are used for CSS).
Something like $s_help_<Name of the page>_<Identifier of the UI element>, e.g. $s_help_bug_report_page_description

@obmsch
Copy link
Contributor

obmsch commented Jun 14, 2017

Apart from your more general remarks on how to introduce and handle help strings,
my proposal was not meant to be a general purpose function. So naming it
"plugin_lang_get_with_help" was perhaps not the right choice.
OTOH I have no problems with making a separate call for the help string and complete
the UI element with it. Just a lot of code duplication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants