[repo_manage_page] no lang fallback with plugin_lang_get_defaulted

[obmsch]

[1]In contrast to plugin_lang_get/lang_get the paired plugin_lang_get_defaulted/lang_get_defaulted
don't fallback to 'english' if a string isn't found for the current language. As I take some responsibility
for that (eb25dfb), I suggest to replace plugin_lang_get_defaulted( $t_key, $t_key, t_vcs->basename )

with plugin_lang_get( $t_key, $t_vcs->basename )

[2]I would have preferred to change the underlying core lang_get_defaulted but a straightforward:

function lang_get_defaulted( $p_string, $p_default = null, $p_lang = null ) {
	$t_lang = $p_lang;

	if( null === $t_lang ) {
		$t_lang = lang_get_current();
	}

	# Now we'll make sure that the requested language is loaded
	lang_ensure_loaded( $t_lang );

	$t_string = lang_get( $p_string, $t_lang );
	if ( !is_blank( $t_string ) ) {
		return $t_string;
	} else {
		if( null === $p_default ) {
			return $p_string;
		} else {
			return $p_default;
		}
	}
}

Has some ugly drawbacks:
[2.1]Two calls to plugin localized strings into core(?)

[2.2]Empty label resolved to a php-page(?)

And there might be others.

@dregad No probs with a PR for [1], but how to proceed with [2.x]? Currently all this probs got
drawn into the kitchen sink.

[dregad]

The warnings are triggered by calling lang_get() from lang_get_defaulted(), with an already-translated text (from the menu item) which of course is not a valid language string.

In my opinion, for this to work a second lang_exists() call to check the English string is needed e.g.

diff --git a/core/lang_api.php b/core/lang_api.php
index 79dac1eca..3a08532f1 100644
--- a/core/lang_api.php
+++ b/core/lang_api.php
@@ -349,6 +349,11 @@ function lang_get_defaulted( $p_string, $p_default = null, $p_lang = null ) {
        return lang_get( $p_string );
    } else {
        if( null === $p_default ) {
+           # If string does not exist in requested language, fall back to English
+           if( lang_exists( $p_string, 'english' ) ) {
+               return lang_get( $p_string, 'english' );
+           }
+           # English string was not found either, return original string as-is
            return $p_string;
        } else {
            return $p_default;

Note: that's just a quick proof-of-concept, I have not tested this further for potential regressions. Anyway, this yields:

Let me know what you think, does that address the problem ?

[2.2]Empty label resolved to a php-page(?)

This is a fallback mechanism from print_menu() function - if there is no label defined for the menu item to display, it falls back to displaying the URL instead (see https://github.com/mantisbt/mantisbt/blob/release-2.23.0/core/html_api.php#L586)

[dregad]

As a side note, this reminded me that I never followed up on #215 (comment) 😊

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.

[obmsch]

I applied your patch (mantis 2.23.0) and changed the second param of the plugin_lang_get_defaulted
calls (repo_manage_page) to null.

As far as I can debug this lang_exists( $p_string, 'english' ) is the problem here. At least in my
environment the plugins lang(english) strings are not loaded. Config and user lang settings are 'auto'.
So what's the difference with yours.

I'm not sure about the precedence $p_default rules lang fallback, I would expect the other way round.

[dregad]

You're right, it does not work (anymore). Not sure how I tested this yesterday or what I did as obviously it was working then, but now I get the same result as you just posted (no English string loaded for SourceGithub plugin, only German). 😕

Config and user lang settings are 'auto'. So what's the difference with yours.

My browser is in English so I can't use "auto"; I have just my set test user's prefs to German. All other settings default.

I'm not sure about the precedence $p_default rules lang fallback, I would expect the other way round.

Do you mean, in the else block, to first check for lang_exists(English) and if not found check for default === null to return string or default ?

[dregad]

@obmsch I thought of another possible way of fixing this :

1. modify lang_ensure_loaded() to not only load the core strings, but also the currently active plugin's (currently this operation is only performed in lang_get())
2. add a recursive call to lang_get_defaulted() so it follows the same logic as lang_get() for falling back to English
3. if the English string does not exist, return the default if provided, or the original string if not.

This should not require any change to plugin_lang_get_defaulted() or to Source Integration plugin.

I actually need to implement and test this, and will publish code when I have done so. Until then feel free to let me know what you think of the approach.

[obmsch]

@dregad I am Ok with that approach, but wouldn't it be easier to just change lang_get_defaulted
to enforce the loading of the plugins lang strings in that case? Something like

		if( $t_lang !== 'english') {
			$t_plugin_current = plugin_get_current();
			if( !is_null( $t_plugin_current ) ) {
				lang_load( 'english', config_get_global( 'plugin_path' ) . $t_plugin_current . DIRECTORY_SEPARATOR . 'lang' . DIRECTORY_SEPARATOR );
			}	
			if( lang_exists( $p_string, 'english' ) ) {
				return lang_get( $p_string, 'english' );
			}
		} 
		if( null === $p_default ) {
			return $p_string;
		} else {
			return $p_default;
		}

[dregad]

Please try this - I did not fully test it yet, but (dare I say it 😉) it seems to work:
https://github.com/dregad/mantisbt/tree/source-i337-lang-defaulted

[obmsch]

Works for me.

[dregad]

As it turns out, this problem had already been reported on mantisbt.org nearly 4 years ago : https://mantisbt.org/bugs/view.php?id=21201

[dregad]

Upstream issue will be fixed in MantisBT 2.24.0.