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

View 2 revisions

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.

Issue History

Date Modified Username Field Change
2015-09-02 19:54 cproensa New Issue
2015-09-03 03:24 dregad Note Added: 0051362
2015-09-03 04:20 cproensa Note Added: 0051367
2015-09-03 10:46 cproensa Note Added: 0051369
2016-02-28 18:51 cproensa Note Added: 0052597
2016-02-29 13:55 cproensa Note Added: 0052608
2019-05-06 09:55 dregad Description Updated View Revisions
2019-05-06 09:57 dregad Note Edited: 0051369 View Revisions