View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020071 | mantisbt | localization | public | 2015-09-02 19:54 | 2019-05-06 09:57 |
Reporter | cproensa | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 1.2.19 | ||||
Summary | 0020071: lang_exists should account for plugin lang strings | ||||
Description | the function "lang_exists(...)" in "lang_api.php
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 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:
I want to pass a message id to "email_generic" wich has translations in my plugin lang files. | ||||
Tags | No tags attached. | ||||
I agree with that, current behavior is not consistent. That being said,
Maybe I'm missing something, but why would core need to process plugin strings ? Some more context might allow better understanding. |
|
when using email_generic(), from my plugin: the parameter $p_message_id is used to look up, for each recipient language, the translated string i would define the message_id in my lang files, eg:
seems like a workaround, in teh meantime, can trick the language system. Doing this from my plugin: |
|
FYI, i tried this
and had to use my email message_id like this to get it work: |
|
anotehr example, in history_api: history_localize_item() |
|
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: If that raises concerns of having too much non-core strings loaded, |
|