Skip to content

[repo_manage_page] no lang fallback with plugin_lang_get_defaulted

Created by: 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 (eb25dfbb), I suggest to replace plugin_lang_get_defaulted( $t_key, $t_key, t_vcs->basename ) repo_mange_page_1 with plugin_lang_get( $t_key, $t_vcs->basename ) repo_mange_page_2 [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(?) my_view_page [2.2]Empty label resolved to a php-page(?) manage_overview_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.