PSR-16 standard compliance

[PowerKiKi]

Closes #49

Q	A
Documentation	no
Bugfix	no
BC Break	yes
New Feature	yes
RFC	no
QA	no

Description

This is a revival of #50, to bring support for PSR-16, and with the goal to release as a major version.

I think the decorator pattern suggested in #50 is a bit too cumbersome for a feature that is supposed to be used very often. Keeping things well-integrated in the Translator class keep it simple to use, and dropping support for CacheStorage makes maintenance easier. Both of those decisions seems to be the best for the long term, even though it requires a major version.

[froschdesign]

@PowerKiKi

I think the decorator pattern suggested in #50 is a bit too cumbersome for a feature that is supposed to be used very often.

To be clear, the suggestion for the decorator is the fact that a support for PSR-16 can be released with a minor version. This means faster availability.
A new major version will not be created just for this one change. See the other open pull requests and issue reports.

[PowerKiKi]

new major version will not be created just for this one change

Fair enough, I am in no hurry. Especially because in the meantime the decorator technique can be implemented in projects that require PSR-16 support.

Would you mind explaining the reasoning behind putting this PR back to draft status ? IMHO this is ready for review and, if the review is ok, should be merged into whatever branch will end up as the next major.

[froschdesign]

@PowerKiKi

Fair enough, I am in no hurry.

👍🏻

Would you mind explaining the reasoning behind putting this PR back to draft status ?

I simply want to avoid merging this pull request too early.
You have correctly noticed that it is the wrong branch. And in addition, the entire Translator class is too bloated, it simply does too much instead of just translating.

The interface defines only to methods:

laminas-i18n/src/Translator/TranslatorInterface.php

Lines 8 to 37 in a09c577

	interface TranslatorInterface
	{
	/**
	* Translate a message.
	*
	* @param string $message
	* @param string $textDomain
	* @param string $locale
	* @return string
	*/
	public function translate($message, $textDomain = 'default', $locale = null);
	/**
	* Translate a plural message.
	*
	* @param string $singular
	* @param string $plural
	* @param int $number
	* @param string $textDomain
	* @param string|null $locale
	* @return string
	*/
	public function translatePlural(
	$singular,
	$plural,
	$number,
	$textDomain = 'default',
	$locale = null
	);
	}

But the Translator class has so many more public methods and does too much:

• provides a factory method for itself
• loads messages from different sources (files, remotes, file patterns)
• supports caching
• triggers events

Therefore, a fundamental redesign must be considered for the next major version. This does not mean that the features cache, the events or the factory should be removed, but whether they all belong in this one class. And if it would not be better to focus only on the essential in this class and in this way considerably extend the extension / reuse.

[froschdesign]

@PowerKiKi
By the way: Thank you for pushing this topic! 👍🏻