still not happy polluting the view class with a none meaningful function name '_'

Then please come up with a better name.

Our framework language class uses translate as function name

Our framework language class uses translate as function name

or simply text

I like text! This never popped up in my mind as I did #40614.

to me it makes more sense than translate as that will confuse some people who say "but i only want one language" - its also shorter and easier to type

Here we go #41079.

I find all these changes actively harmful, impractical, and beyond reason.

They break a long standing convention of 17 years for translating strings. It breaks existing tooling which was based on the unambiguous use of Text::_() to detect language strings. It makes it harder for site integrators, especially given that there will be a mix of methods during Joomla 5's lifetime at the very least i.e. until the end of 2027. It encourages 3PDs to create their own abstraction frameworks, like I had done with FOF, to isolate themselves from the constant nonsensical changes in Joomla, promoting further fragmentation.

In the end of the day, having Text as a static helper class is a good thing. There is only one language, and it's global throughout the CMS. You can call Text::_() no matter if you are in a view template of a component, module, or plugin, in a Model, Controller, or View Controller (what Joomla! calls "View"), or any other kind of code.

Having to think about how to get the global language in each place is an unnecessary burden on the developer. There's not a single framework or CMS out there, from Laravel to WordPress, which asks you to solve a puzzle as to how to get the language object to output a translated string.

i keep asking the same question - why?

I also notice other changes which are pointless, and have unintended consequences.

For example, the signature of the CMSPlugin constructor changed from public function __construct(&$subject, $config = []) to public function __construct(DispatcherInterface $dispatcher, array $config = []) which breaks PHP 8 calling conventions e.g. $plugin = new MyPluginClass(subject: $dispatcher, config: $pluginParams). There was no practical reason to make this change.

All these are pointless changes which create an artificial burden for developers and site integrators. It would make perfect business sense for 3PDs to not support Joomla 5 until they absolutely have to, around the time Joomla 5.3 or 5.4 is released in two years. Then core maintainers will complain that 3PDs don't support new Joomla versions, overlooking the fact that this is a problem caused by their own pointless and undocumented changes which make supporting a new major version not make any business sense for 3PDs.

I do not agree here with the arguments. Declaring a namespace in a layout file is not intuitive and requires more PHP knowledge for a site integrator as it should be. It is much better to be able to just write $this->text everywhere. The developer doesn't have to think about to put the language in place, on normal execution of the flow this should work out of the box in core. So there is nothing a developer has to think about. But the layout files do actually look much more like a template file as when it starts with a block of namespaces.

Another benefit is that the layout files, regardless of their location can easy be reused in different locations with a different environment. It is time to break up the hardcoded, static connection we have in Joomla to be more flexible and adaptable. And it is much more extendable, especially with #41384 which unifies the rendering amongst different places.

And going directly to the language object is faster than using Text which needs to load the language from the Factory and does some additional checks for every string out there.

And you have pointed out the biggest issue which was leading to this change. We are still using code which was written 17 years ago. Because of this we should recap if it is still the right what we do nowadays. I mean, we give plenty of time to adapt, there is no rush for 3rd party extension developers here. As long as Text is widely used in the eco system, it makes no sense to remove it. Even when it is Joomla 6,7 or 8. We learned from the mistakes in the past and do give the developers enough time for adoption.

We will come up with another solution which is less context aware.