As discovered - lang_api revision 1.26 is "bad boy"

I hate this, I think everyone who changes the way lang_api works comes up with a more creative name for the global variable. The last one who changed this was Andre. However, I can't blame such changes. I think the reason this keeps breaking custom_strings_inc.php is due to lack of encapsulation. What we need is to add an API like lang_get_current() which returns the language that should be used by custom strings.

So this is still broken?

Last lang_api now yet
lang_api.php,v 1.28 2004/07/10 15:40:21
and yes, it can't be used - I live with 1.25

OK, I do indeed see a couple of different names for this.

If we add lang_get_current(), will that fix the problem? I can't think of any way to warn users that they should use this though.

In 1.26, the language key changed from $g_current_language to $g_active_language. The documentation also references an older $g_lang_current. It also appears not to be set right before the custom file is loaded.

What variable are you using?

(On a side note, the fix for 0004147 may address this. I added a function "lang_peek" that will return the current language).

Changing to $g_active_language cured problem
Issue can be resolved

Let's leave this open until the documentation is updated to point to lang_peek?

At least I can't find this function :-) in sources

Alex, the patch from 4147 is yet to be applied.

Victor, should I rename/create lang_get_current() as part of the 4147 fix?

with the commit for 0004147, there is now a function "lang_get_current()" that will return the current language for the load. $g_active_language is also set.