Pick up translations from PHP script run from cron/CLI

[itimpi]

The current guide on multi-language support describes how to pick up translations from .php files that are started from a web page and I am doing this successfully.   However it does not seem to cover the case where the .php script is started from a cron job (or the CLI).   Is there any guidance on what do in such cases.

 

I am currently working on trying to do some reverse engineering on how the translations are loaded for web pages, but thought I should ask in case there is already something I can look at for the cron/CLI cases.

[itimpi]

After investigation and testing I have found that if I simply replace line 115 in Translations.php that reads

$locale   = $_SESSION['locale'] ?? $login_locale;

with

$locale   = ($_SESSION['locale'] ?? $login_locale)??parse_ini_file('/boot/config/plugins/dynamix/
dynamix.cfg', true)['display']['locale'];

to get the PHP $locale variable set even when not running from the browser then I can get translations working in PHP scripts called via cron or from the command line. 

 

I feel there should be a more efficient way of doing this to avoid excessive parsing of the dynamix.cfg but not sure what that would be (perhaps add the locale variable to vars.ini?)

 

What do I need to do to get this (or an equivalent) added to standard Unraid to improve the multi-language support?

 

 

[Squid]

CA does it like this 

https://github.com/Squidly271/community.applications/blob/master/source/community.applications/usr/local/emhttp/plugins/community.applications/scripts/updatePluginSupport.php

 

But I use a wrapper for the _() function that sees if translations are supported and calls _ accordingly (tr function - only called on the last line)

[itimpi]

16 hours ago, Squid said:

CA does it like this 

https://github.com/Squidly271/community.applications/blob/master/source/community.applications/usr/local/emhttp/plugins/community.applications/scripts/updatePluginSupport.php

 

But I use a wrapper for the _() function that sees if translations are supported and calls _ accordingly (tr function - only called on the last line)

Thanks for that.  I must have had a blind spot because I did not even consider setting $_SESSION['locale'] explicitly in the PHP cote before including the Translations.php file which also achieves the effect that I wanted without changing any existing Unraid code.

 

Ideally this tip should be added to the Multi-Language Guide?

[Squid]

Just noticed your changelog.  Personally, I wouldn't bother with translations in the syslog.  Nothing else does it

[itimpi]

2 hours ago, Squid said:

Just noticed your changelog.  Personally, I wouldn't bother with translations in the syslog.  Nothing else does it

Maybe the change log message is not well worded   It is not just syslog messages that were not being translated, but also all the ones that could be output as notifications.  The translation file already has a comment suggesting that syslog messages are probably not worth translating although the very common top level ones are there if a translator wants to bother.   In fact the ‘testing’ type syslog messages are not even in the translation file as they really are meant for my use in diagnosing issues, and so if testing mode is used I want to see syslog messages I understand

 

After the latest plugin update the visible change that the user will now see is notifications from the plugin being out put in the translated language.