php-translation / translator

Services to translate strings, Like GoogleTranslate and BingTranslate
MIT License
25 stars 16 forks source link

Version 2: Drop PHP 7, update all libraries #28

Open tacman opened 1 year ago

tacman commented 1 year ago

Since PHP 7 is past EOL, how about dropping it altogether?

Symfony 6 requires PHP 8, it'll just make going forward easier to not continue to support outdated tools.

We can use rector to refactor, and update the underlying libraries. We should drop http-plug, and use PSR-18 directly.

New client implementations and consumers should use the PSR-18 interfaces directly. In the long term, we expect PSR-18 to completely replace the need for HTTPlug.

https://github.com/php-http/httplug#intro

Thoughts?

welcoMattic commented 1 year ago

The plan for this collection of packages (under php-translation) is to lead a transition to Symfony Translation Providers.

However, as some features in the bundle are not in the Symfony Translation package, we could keep thèse feature here in a new major version (like Profiler panel to add translation via UI, or Content Editable features).

For the specific case of the PHP-translation/translator package, I'm ok to upgrade it to a up to date stack 👍 feel free to contribute some PR

tacman commented 9 months ago

With Symfony 7 coming up, I thought I'd revive this issue, in particular what best practices we could use for a new version.

Dropping httpplug seems like a step in the right direction.

It's probably not essential, maybe just documenting some http clients is enough. I need the Symfony HttpClient (which already integrates with the profiler).

Really what I want is to be able to cache the translation calls, since they're slow and in some cases expensive. I'm not sure where that cache should be, though -- in this library, or in a Symfony bundle, or even the application level.