View Issue Details

IDProjectCategoryView StatusLast Update
0020071mantisbtlocalizationpublic2019-05-06 09:57
Reportercproensa Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version1.2.19 
Summary0020071: lang_exists should account for plugin lang strings
Description

the function "lang_exists(...)" in "lang_api.php

function lang_exists( $p_string, $p_lang ) {
    global $g_lang_strings;

    return( isset( $g_lang_strings[$p_lang] ) && isset( $g_lang_strings[$p_lang][$p_string] ) );

returns FALSE even if the string is defined in the plugin lang files

however "lang_get(...)" does return the string, in the else case, checking for current plugin lang files

    if( lang_exists( $p_string, $t_lang ) ) {
        return $g_lang_strings[$t_lang][$p_string];
    } else {
        $t_plugin_current = plugin_get_current();
        if( !is_null( $t_plugin_current ) ) {
            lang_load( $t_lang, config_get( 'plugin_path' ) . $t_plugin_current . DIRECTORY_SEPARATOR . 'lang' . DIRECTORY_SEPARATOR );
            if( lang_exists( $p_string, $t_lang ) ) {
                return $g_lang_strings[$t_lang][$p_string];
            }
        }

if the string is resolvable from lang_get, it should be also validated by lang_exists

this is a problem if code in core uses lang_exists for a plugin string, example:

  • function email_bug_info_to_one_user

    $t_message = lang_get_defaulted( $p_message_id, null );

I want to pass a message id to "email_generic" wich has translations in my plugin lang files.

TagsNo tags attached.

Activities

dregad

dregad

2015-09-03 03:24

developer   ~0051362

if the string is resolvable from lang_get, it should be also validated by lang_exists

I agree with that, current behavior is not consistent. That being said,

this is a problem if code in core uses lang_exists for a plugin string

Maybe I'm missing something, but why would core need to process plugin strings ? Some more context might allow better understanding.

cproensa

cproensa

2015-09-03 04:20

developer   ~0051367

when using email_generic(), from my plugin:
email_generic( $p_bugid, 'new', 'email_notification_title_for_action_bug_moved' );

the parameter $p_message_id is used to look up, for each recipient language, the translated string
Lookup is done with a call to lang_get_defaulted(...)
which first uses lang_exists(), before an actual lang_get()

i would define the message_id in my lang files, eg:
$s_email_notification_title_for_action_bug_moved = 'The following issue has been MOVED.';

  • i want to define a message_id in my plugin (instead of ad-hoc text) because email_api will use the proper localization string for each recipient
  • i dont want to modify custom_string.inc, which would be against the "plugability" of plugins

seems like a workaround, in teh meantime, can trick the language system. Doing this from my plugin:
$g_lang_strings[$LANG]['string_id']= lang_get('string_id',$LANG);
for each $LANG language that is defined in my plugin.
(note also that plugin_lang_get does not accept a language parameter!!)

cproensa

cproensa

2015-09-03 10:46

developer   ~0051369

Last edited: 2019-05-06 09:57

FYI, i tried this

seems like a workaround, in the meantime, can trick the language system. Doing this from my plugin:
$g_lang_strings[$LANG]['string_id']= lang_get('string_id',$LANG);
for each $LANG language that is defined in my plugin.
(note also that plugin_lang_get does not accept a language parameter!!)

and had to use my email message_id like this to get it work:
'plugin_BASENAME_email_notification_title_for_action_bug_moved'

cproensa

cproensa

2016-02-28 18:51

developer   ~0052597

anotehr example, in history_api:

history_localize_item()
for a history entry made from a plugin, it searchs for localized title, but using lang_get_defaulted as is, the plugin lang files are never reached

cproensa

cproensa

2016-02-29 13:55

developer   ~0052608

The problem with history_localize_item() may be a pattern:

Sometimes mantis should look up for plugin lang strings, but they are not available when the execution is in core, outside of plugin scope. Indeed, in the history_localize_item() example, we don't know which plugin to look up, as lang_get relies on plugin_get_current(), and there is no plugin in the stack.

One possible solution:
Load all plugin strings at startup so they are available directly in $g_lang_strings

If that raises concerns of having too much non-core strings loaded,
an alternative may be to provide a way for plugins to inject some strings in the global scope, probably at initialization. Those strings that are needed outside the plugin scope.