Just suggestion - could you consider to implement lan changes back to 2.3?

[Jimmi08]

Hi,
I don't use 2.3.x anymore. All my sites are now on 2.4.x but I think it would be very helpful for translators to add support for LAN arrays back to 2.3.

Why? Because the 2.4 language handler is tested and works flawlessly with the define and array versions.

No compatibility issue, no need to edit files; define still works

I don't suggest changes in core 2.3.x LANs files; only support for situations where somebody already has the array version and they want to use it for 2.3 pack.

Thanks

[tgtje]

@Jimmi08 English is the fallback language, but in 2.3 ( > incl 2.3.11). these are in also in define mode. (no change suggested in post)
Else you still have THEM (older versions) to alter core code files ( holding the 'method' ( who will do so for x versions??)

They will be stuck when reaching php 8.4 (E_strict etc.) so they have to make a choice in time

But looking at the big picture in last year, and the differences between v2... 2.3.11 and the Developer Git master. it is already a kind of
split. Core evolves, so tranlations naturally would/should/expected too.

For 'the 2.3 user' it could benefit if the ARRAY (non English) language packs from/for Git Master clould be/or were provided in define too (being so larger in size, but culprit is BC, which would be ok as long as no split occurs, in case v 2.4 (let's call it so, looses BC ).
( in tests i have both ready, containing all up to git master)

Function is one-sided no defined lan (locale)> fall back to English for LAN's used in core...
The otherway around gives : what 'old' core does not know it (besides typo errors in new ones excluded) it will not react on ?..

So thats up to the translators. (since automated scripts now can be applied (;-) ) for lang def> lang array).(a mirror script doing the other way around array>define),
create pack, make available, ONLy issue there > how's lang pack importer seeing the difference between array and define mode (TAG name?)..

but ok, my opinion

for those interested :
when master is up to date and 2.3.11 would run with an up to date Define pack for master (if available eg pack contains old and new defs ones) these will throw lang verify errors:
lan_cron 5x commented out LAN.13.14.15.16.60
lan_installer +1 lan 151 ..Secure random number generator.... > introduced in 2.3.10 >>> ONLY FOR 2.3(10-11?)OR FORGOTTEN>not in present master.....
download admin code line MD5 EXPRESSION (html to bbcode change).

[e107help[bot]]

@Jimmi08 The gap on 2.3 is more literal than "not supported yet": an array file there is not ignored, it is discarded. e107::includeLan() includes the file and hands back whatever it returned, with no branch for an array. The pack loads, returns its several hundred strings, and not one constant gets defined. Every reference to them then fatals on PHP 8. So the ask is real, and it is not a flag somebody forgot to set.

Master grew the missing half in two pieces: the is_array($ret) branch and the private includeLanArray() that defines the keys and fills the gaps from English. Copying those across is the small part. I traced what else is in the way, and it falls into two piles worth keeping apart, because they are not the same decision.

Decides whether a pack works at all: the call sites. Master sends almost every language file through the handler. Counting direct includes of an e_LANGUAGEDIR path, master has two left and 2.3.x has eleven, and one of them is the file that matters most: class2.php:560 pulls <Lang>/<Lang>.php in raw, where master calls includeLan(). The rest are in form_handler.php, mail.php, iphandler_class.php, users_extended.php, users.php and install.php. Until those are converted, the site-wide pack, the biggest file a translator ships, is still thrown away in array form.

Decides only what the admin screen says: Language Check. @tgtje asked the right question about the importer. On 2.3.x fill_phrases_array() is a regex over define(; master's was rewritten on token_get_all(). So an array pack could run perfectly and Verify would still report every string missing, which is what #5782 looked like from the admin side. Deltik has already pointed that rewrite (#5703) at v2.4.

The split matters because "port the loader and the call sites, and let Verify be wrong on 2.3" is a coherent answer, and a far smaller one than doing all three.

The decision is Deltik's and he has not made it. In June 2026 he wrote that release/v2.3.x does not carry master's features, array LANs included (comment). That was while the branch took security fixes only; v2.3.8 through v2.3.11 have since shipped a good deal that is nothing of the sort, so the rule that made it automatic is not the rule any more, and the question is open rather than answered. I have put it in front of him instead of answering it for you. If this thread goes quiet, tag him on it.

One thing would help him weigh it, and only you have it: which existing array pack, and whose 2.3 site? You raised it for translators without naming one, so at the moment he has the cost of the work and no measure of the demand.