Hi,

This package is in the dependency chain of tt-rss, currently not in
testing, thus opening this bug as RC to see this package also removed
from testing.

Using “Restrictions: allow-stderr” in debian/tests/control is probably
enough to fix the issue, but I don’t really see the point of fixing it
while tt-rss is not ready for Trixie.

Regards,

taffit

Hi,

I'm trying to understand the context of this bug, as my current take on
this is that php-gettext is at risk of being removed from Trixie purely
on account that:

- There exists a *downstream* package (tt-rss, i.e. not an actual
dependency of php-gettext) that is posing a problem.
- The PHPUnit text fails merely on account that php-gettext outputs some
data to stderr, and newer PHPUnit, which didn't care about that in the
past, no longer does by default.

If that is the case, then I hardly see how the above is enough to
warrant the removal of what I assert is a *critical* package for anyone
who wants to serve localised PHP content using Debian, and I would urge
the maintainers of the package to re-evaluate their assessment to fix
the issue and reinstate php-gettext as part of Trixie.

For reference, I am using php-gettext on a Debian Apache/PHP server as a
means to (indirectly) generate localised pages for my website at
https://rufus.ie (where, ironically, one can download a popular Windows
application that can help folks install Debian). So not having
php-gettext being part of Trixie is a complete dealbreaker for me in
terms of being able to use the next version of Debian as a web server,
and I suspect that I am far from being the only Debian user in this case...

Therefore, I hope that the current removal of php-gettext from Trixie is
being treated as a transient issue, that is being looked into and that
is going to be addressed before release, rather than a hint that the
Debian maintainers do plans to drop the whole package altogether.

Thank you,

/Pete

Hi Pete,

Thank you for your interest in ensuring Trixie will contain all relevant
and useful packages.

On 20/03/2025 13:31, Pete Batard wrote:
[…]
Can you please elaborate? Are you actually using the php-php-gettext
binary package, that provides a Gettext emulation in PHP, and hasn’t
seen any activity [upstream] for more than ten years? Maybe are you
rather referring to the proper gettext functions, that are provided by
the gettext module, shipped by the php8.4-common package and I think is
enabled by default.

	upstream: https://launchpad.net/php-gettext
	gettext: https://www.php.net/manual/en/book.gettext.php

This bug report is about the php-gettext source package, used to build
the php-php-gettext binary package. It provides some classes written in
PHP to workaround the lack of proper gettext support. It dates from a
time when the gettext module may have not been available by default, and
I don’t believe such code is actually useful today when one can use the
way more efficient gettext module.

Regards,

taffit

Hi David,

Thanks for clarifying the evolution of the php-gettext package. I have
indeed been using it more more than 10 years, so I wasn't aware that, in
that time, gettext had been formally integrated into PHP without
requiring a separate dependencies, and that the package also had gone
through a (somewhat confusing) name change (though I recall that I had
to figure some of it during the Bullseye or Bookworm dist upgrade).

It turns out that, as you suspected, my issue was not with
(php-)php-gettext itself, but with not having php-intl installed.

For the record, the PHP content I was trying to render is found at
https://github.com/pbatard/rufus-web/blob/gh-pages/index.php and you can
see that it includes a call to locale_accept_from_http(). And the reason
I thought there was an issue with not having a PHP gettext candidate
package available is that, when I tried to serve that PHP on Trixie, I
got the error :

[php:error] [pid 166476:tid 166476] [client ###.###.###.###:54940] PHP
Fatal error:  Uncaught Error: Call to undefined function
locale_accept_from_http() in /home/rufus/public_html/index.php:85\nStack
trace:\n#0 {main}\n  thrown in /home/rufus/public_html/index.php on line 85

Now, I logically assumed that, since I was getting a localisation error,
and I hadn't been able to install PHP gettext (and wasn't aware of the
gettext integration into the PHP engine), the missing function call was
part of the missing package, so I didn't bother trying with just
php-intl on its own (since I always historically installed php-intl
alongside (php-)php-gettext). However, as you will be happy to hear,
installing php-intl on its own was all it took to fix my issue.

As such, I no longer have reservations about php-gettext/php-php-gettext
not being available in Trixie, since I have confirmed that the
functionality it provided (at least for my usage) should be available by
default, and that the php-intl package, which is part of Trixie, does
work as expected for the corollary function call.

You can therefore disregard my previous concerns, with my thanks for
helping me figure out that I didn't actually need a separate gettext
package.

Regards,

/Pete

Hi Pete,

On 23/03/2025 22:06, Pete Batard wrote:
[…]

Thank you for the quick feedback, and glad you manage to find a way to
keep the feature you actually need (with probably a more efficient result).

Regards,

taffit