Language support under Debian Buster does not work as expected #2924
Comments
|
Don't use debian package. Use git. You would have more fresh code. For You issue try: |
|
@interduo: php-gettext has been retired from debian bullseye's repository |
|
Yes, @Benhool77 is correct it was retired and I agreed with it as I'd been informed we were not reliant upon it for some time. Unfortunately, that appears to be incorrect as my testing is showing it actively being used so we need to review this more thoroughly to see what we do next. |
|
So, when Paul mentioned that they are removing phpgettext, I was certain it was the php module, and not the emulation layer that we use in the case that the php maintained module php-gettext was not available. I would like to ask @paulgevers, what Debian plans to use as a replacement for gettext in PHP for web application that wish to work with different languages. Seems almost like cutting off one arm due to the face that you cant stand to look at the wart that formed there. |
|
@cigamit, cacti was together with one other package the only web application that was using phpgettext. As mentioned in issue #2508, there is a maintained fork: https://github.com/phpmyadmin/motranslator/, which is also available in Debian (unstable). |
|
I think the confusion with php-gettext is that there is a php module as well as a php code library of the same name and that Debian uses the original php-gettext as an alias to php-php-gettext (which is the code version not the module). Since it is the emulator (php-php-getttext) that's being removed, I took a look at the above motranslator and it would appear to be relatively simple to drop in though I haven't checked the licensing yet. As long as we have all the pre-requisites it needs in the vendor folder (as Cacti doesn't utilise composer itself) for those who aren't using the debian package. @mortenstevens will likely want to update his package requirements to mirror this too once we have it in place. |
netniV
changed the title
|
I took a look at MoTranslator though that has some dependancies and requirements that we can't really support right now as the minimum PHP version must be 7.1. I have had a look and also found https://github.com/oscarotero/Gettext which appears to be another library which I have managed to get working and supports PHP 5.4+. Would that one be OK to use or do we need to keep looking? Failing that, we are going to have to raise the minimum PHP level which I don't mind doing for 1.3 when it eventually comes out but I would hate to enforce on a patch revision of 1.2.x |
|
Hi Mark,
On 12-09-2019 14:57, Mark Brugnoli-Vinten wrote:
I took a look at MoTranslator though that has some dependancies and
requirements that we can't really support right now as the minimum PHP
version must be 7.1. I have had a look and also found
https://github.com/oscarotero/Gettext which appears to be another
library which I have managed to get working and supports PHP 5.4+.
Would that one be OK to use or do we need to keep looking? Failing that,
we are going to have to raise the minimum PHP level which I don't mind
doing for 1.3 when it eventually comes out but I would hate to enforce
on a patch revision of 1.2.x
Hmm, is this a clone of the old phpgettext (doesn't seem like it) or is
this really different code. In either case I am not very enthusiastic
because it means I have to maintain another package for Cacti, but I see
where you are coming from.
How bad is the situation really at this moment? Can we leave this issue
"unfixed" while still on 1.2.x and go for the MoTranslator solution with
1.3? Or is the current user experience really bad? That would warrant
updating the current Ubuntu development branch as well with a solution,
in Debian we can wait because we're early in the release cycle.
Paul
|
|
At the moment, there will be no foreign language support without one or the other. Fine for the English speaking world but to suddenly lose translation on an upgrade would be bad IMHO. Do you need to maintain another packager if it's part of our sources and doesn't currently exist? |
|
Hi Mark,
I am uncomfortable asking you to do specific work here, but on the other
hand, not doing so leads to more work for me and more friction points
between how you deliver your code and the Debian/Ubuntu package. I
appreciate your openness to discuss this.
On 14-09-2019 12:17, Mark Brugnoli-Vinten wrote:
At the moment, there will be no foreign language support without a
package. Fine for the English speaking world but to suddenly lose
translation on an upgrade would be bad IMHO.
Ack. Than we probably need to fix Ubuntu too soon (or remove it from the
next release). I'll check.
Do you need to maintain another packager if it's part of our sources and
doesn't currently exist?
Embedded copies are frowned upon in Debian [1] , so in principle yes. I
am already stretching it for some of the JavaScript libraries you embed.
I don't like adding another one. But, in the end it's up to you. The
good thing of MoTranslator for me is that it is already packaged. But if
you include Gettext, I'll have to see how I proceed.
How difficult is it too make it an alternative? I.e. you include
Gettext, but the code can also work with MoTranslator if that isn't
available? Or could you give me a patch that works with MoTranslator,
maybe if you intent to use it in the 1.3 branch, I could pull it from
there? In Debian and Ubuntu, we already have a higher version of PHP, so
the restriction for you is not an issue for users of my Debian package.
Paul
[1] https://wiki.debian.org/EmbeddedCodeCopies
|
|
You help us out by not having us have to go through the Debian hoops ourselves so a small tweak from outside isn’t too much to ask for to keep it going on their environments. What I can do is make the code able to use MoTranslator but that will require two things, a minimum PHP level of 7.1 and a setting in either the database or configuration file. I’m not sure what the minimum PHP version is on your base systems so there may be a conflict there. If you look at the proposed changes so far for the i18n branch it wouldn’t take much to adjust for MoTranslator but as that also requires Symfony etc we wouldn’t package with it because it would just bloat our sizes up even more. If you are OK with that, I’ll look into it later today. |
|
Oh just read about the PHP version so that should be fine |
|
From a technical point of view, I would also recommend increasing the minimum PHP version to 7.1. But this will affect only cacti 1.3? |
|
We haven’t actually made that decision yet but based upon recent events I am tempted to ask about raising the bar. However we have had a few reports of issues recently that where from people still running PHP 5.4 |
|
If we can get RedHat to make PHP 7.x available in RHEL7, then I'm good with this approach. From the point of view of the i18n library, I would not be against taking over management of the package and embedding directly into Cacti. We would need to resolve the CVE associated with the use of the eval() command of course. I suspect that there is not much to change outside of that over time unless PHP starts deprecating or changing the behavior of some of it's commands, which of course, we have seen in the past.. @paulgevers, would that be acceptable to Debian. We would move the files out of the vendor directory and maintain the original authors copyright. |
|
I've pushed a change to allow MoTranslator as a translation provider to the i18n branch. To use this, set the l10n_language_handler to 3 (MoTranslator) in either config.php's config array or the settings table. |
|
@netniV I appreciate the i18n branch. I have several questions and remarks.
|
|
Firstly, are you making sure to use l10n (that's LIMA TEN NOVEMBER) since it's the localization handler we are trying to find, not i18n (INDIGO 18 NOVEMBER) which is the internationalisation code ? (I followed the existing coding conventions). That aside, on your list
Fixed
If you use read_config_option() with no value set, it could return false/empty, where as if you set the option off read_config_option() will return 0. So, to distinguish, the code checks if read_config_option() is not true (0/false being false, 1+ being true) and then also checks if the option isn't blank (since 0 wouldn't be blank)
The code is designed such that you can set the setting in the following priority order:
Again, double check that you are using the correct prefix as mentioned above 👍
That does sound like a bug. However, I have never noticed an issue changing my language as long as it's done via the user profile. If you change the global language, this isn't automatically populated down to users because we don't overwrite the settings already stored for them. I had previous suggested that we only store a setting if overridden thus many settings would be kept to the system defaults and potentially even allow the admin to define the user settings that can be overridden but that's a future project. So, if you want to check out what is occurring above, the simplest thing is to create /share/ with full write permissions to your web servers user account (more than likely apache). |
PHP 7.x is available for RHEL7 via RH Software Collections (SCL). But we can't require SCL packages for Fedora-EPEL. Since RHEL7 is over 5 years old, I think it's time to switch to RHEL8/CentOS 8. So my plan is to ship cacti 1.3.x only for RHEL8 and we can continue to support RHEL7 with cacti 1.2.x security updates only? |
|
1.2.x for RHEL 7 and 1.3.x for RHEL 8 ? Sounds good though 1.3 may be a while yet. We've barely started on it. |
|
I think we can close this since it's merged into the 1.2.7 now. |
|
@paulgevers has this now made it's way to debian? |
|
@netniV yes, I pulled the pieces from the branch before it was merged. It's part of 1.2.6+ds1-3, which is in |
Describe the bug
on a fresh system with Debian testing bullseye netinstall, cacti seems to be broken (install via apt... with apache)
/var/log/apache2/error.log
PHP Warning: require(/usr/share/cacti/site/include/vendor/phpgettext/streams.php): failed to open stream: No such file or directory in /usr/share/cacti/site/include/global_languages.php on line 157
PHP Fatal error: require(): Failed opening required '/usr/share/cacti/site/include/vendor/phpgettext/streams.php' (include_path='.:/usr/share/php') in /usr/share/cacti/site/include/global_languages.php on line 157
no streams.php found on this system:
root@bulls-test:~ find / -name 'streams.php'
root@bulls-test:~ (no result)
To Reproduce
Install debian testing Bullseye
install cacti via "apt install cacti"
choose apache as your web-server
connect to your cacti server http://yourcactiserver/cacti (it don't works...)
display /var/log/apache2/error.log
seems to be linked with this issue #2508
since phpgettext has been disabled
link in cacti forum
https://forums.cacti.net/viewtopic.php?f=2&t=60110
thanks
The text was updated successfully, but these errors were encountered: