Use plugin_lang_get to display repo settings keys, trans bool values

[obmsch]

Instead of just displaying the raw keys, be user friendly and show the lang
strings as repo_update does. For bool values use trans_bool to get a nice
check mark.

[dregad]

Thanks for your contribution.

There are 2 things that I think should be improved:

1. If a repo's data contains keys that are not recognized, an error message is displayed (this can happen with old repos created before a change in how the plugin stored its data):
   
   or, if $g_display_errors is set to hide warnings, we get a very narrow line with no data
   
   I would expect a graceful fall-back to the raw string in this case
2. While having a descriptive label is a lot better than the raw key, I don't like seeing the "helper text" below, as this is intended as a guide for input. I suggest splitting the strings and only display the helper text in repo_update_page.php

[dregad]

To make the code easier to read, I would suggest to use a ternary operator here, i.e.

<td><?php echo is_bool( $t_value ) ? trans_bool( $t_value ) : $t_value ?></td>

[obmsch]

Rebased, and hopefully adressed all your comments.
Local function "plugin_lang_get_defaulted" eventually moves to mantisbt core.
A lot of implications and dependencies, surely beyond the scope of this PR.

[dregad]

Hello Martin, and thanks for the revised PR.

hopefully adressed all your comments

Actually you missed point 2 in #215 (review), i.e. splitting the language strings between label and help text.

Incidentally, that should remove the need for the explode( '<br', ... operation.

Local function "plugin_lang_get_defaulted" eventually moves to mantisbt core.
A lot of implications and dependencies, surely beyond the scope of this PR.

That makes perfect sense, I'll prepare a MantisBT PR so it becomes part of core in a future version.

In the meanwhile, to keep the code clean I think it would be better to move this function into Source.API.php, and also wrap it around an if function_exists block to facilitate the transition.

[obmsch]

Hello Damien,
moving (and wrapping) "plugin_lang_get_defaulted" to Source.API.php makes sense, will look into that later.
I am not sure what you have in mind on the string splitting issue. Are you asking for something like:
$s_plugin_SourceGithub_master_branch = 'Primary Branches
(comma-separated list or "*" for all branches)';
gets

a) $s_plugin_SourceGithub_master_branch = 'Primary Branches';
$s_plugin_SourceGithub_master_branch_help = '
(comma-separated list or "*" for all branches)';

b) $s_plugin_SourceGithub_master_branch_label = 'Primary Branches';
$s_plugin_SourceGithub_master_branch_help = '
(comma-separated list or "*" for all branches)';

c) $s_plugin_SourceGithub_master_branch_label = 'Primary Branches';
$s_plugin_SourceGithub_master_branch = 'Primary Branches
(comma-separated list or "*" for all branches)';

As repo_manage_page and repo_update_page use the same keys to lookup the lang strings

a) 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.
b) In principle the same as a), but the first lookup has to be adjusted too.
c) Despite more effort on the lang maintenance, translations, this would be the easiest way to go for. No side effects, only repo_manage_page affected.
instead of
# Extract the descriptive part of the $t_key lang entry
list( $t_description ) = explode( "<br", plugin_lang_get_defaulted( $t_key, $t_vcs->basename, $t_key ) );
... echo $t_description ...
then simply
... echo plugin_lang_get_defaulted( $t_key . "_label", $t_vcs->basename, $t_key ) ...

Thoughts?

[dregad]

From a design perspective, I never liked these labels including help text with HTML formatting, so I thought that this would be a good opportunity to get rid of them.

As for implementation, I was actually thinking along the lines of your option a) which I think is cleaner than c); b) does not make sense IMO.

I must admit that this was just an idea, I did not fully consider or analyze the implications on the code base and development effort. That being said, I'm not overly concerned about the extra plugin_lang_get() calls, as this would be a one time change.

Anyway this is diverging from your PR's original scope, so maybe it would be better to track this refactoring separately.

[obmsch]

One more update to the PR. Made "basename" otional and last param in "plugin_lang_get_defaulted".
More convenient, I guess only a few cases (like repo_manage_page) where current basename differs
from the target basename.

For now help text are shown too (minor issue) and will be tackled, when issue #228 gets fixed.

[dregad]

One more update to the PR. Made "basename" otional and last param in "plugin_lang_get_defaulted".

Indeed, much better this way, and closer to lang_get_defaulted()'s signature too.

[dregad]

I'll prepare a MantisBT PR so it becomes part of core in a future version.

https://mantisbt.org/bugs/view.php?id=26747