Confirmed.

In fact, the extension language name is saved a such in the db.

EDIT/NOTE: same behavior in 3.x

This comes from this code in the language adapter

->clean the manifest name takes off the parenthesis and spaces.

No idea why the "cmd" filter is used here. Maybe we should use "string"? Or "html"?

IIRC the name is parsed by JText that's the reason why spaces are not allowed, normally a extension name is com_xxx and in the component ini you have a language string com_xxx="The XXX component" I would expect the same is true for language packages.

Thanks for looking into this.

FYI - The same behavior is exhibited in 3.10 as well.

IIRC the name is parsed by JText that's the reason why spaces are not allowed, normally a extension name is com_xxx and in the component ini you have a language string com_xxx="The XXX component" I would expect the same is true for language packages.

Languages names (for clients) are an exception. Indeed they pass through Text::_() as all extensions when displayed in the Extensions Manager, but they should never be translated but always presented in English.
The best demonstration is English (en-GB) which in the db is presented in full. Package and clients.

The other languages package names are also saved in db in full. No clean there but only the manifest name. Only the client languages are not.

In the Extensions Manager,

Text::_() is not used in the Installed languages view and it is fine. (Italiano is a wrong name. Should be Italian...)

Therefore, there is no reason to install client languages with cmd.

I tested changing cmd to string and it now works fine.
$this->name = InputFilter::getInstance()->clean((string) $this->getManifest()->name, 'string');

Hmm, if we change the filter for the name and the names are stored in database after filtering, then after changing the filter to "string" the name will not match anymore to what is stored in database. So it would need to fix the values in database with values from the manifests for all extensions of whichever type when updating from a version without the change to a version with the change from a potential fix.

I do not think so.

1. It concerns only the LanguageAdapter.php i.e. languages extensions
2. We would also have to change 'cmd' to 'string' in the update method.
3. I tested.

I installed the French pack https://downloads.joomla.org/language-packs/translations-joomla4/downloads/joomla4-french/4-0-3-1

then I modified the LanguageAdapter to use 'string' and went to install languages: it proposed pack 4.0.4.1.
All went fine.

There is a good reason for that, the adapter does not check for equal names but only tag, type and client

// Update an entry to the extension table
		$row = Table::getInstance('extension');
		$eid = $row->find(array('element' => $this->tag, 'type' => 'language', 'client_id' => $clientId));

		if ($eid)
		{
			$row->load($eid);
		}
		else
		{
			// Set the defaults

			// There is no folder for language
			$row->set('folder', '');
			$row->set('enabled', 1);
			$row->set('protected', 0);
			$row->set('access', 0);
			$row->set('client_id', $clientId);
			$row->set('params', $this->parent->getParams());
		}

		$row->set('name', $this->name);

$this->name is taken from a bit above in the code. It is the new pack manifest:

// Get the language name
		// Set the extensions name
		$name = (string) $this->getManifest()->name;
		$name = InputFilter::getInstance()->clean($name, 'string'); // which I just changed to `string`
		$this->name = $name;

As for English it is already fine as English (en-GB) in the db.

Pull request for 3.10 is #35980 . Please test. Later when it has been merged, it will go into 4.0-dev with the next regular upmerge after that.

But maybe I make another PR with the same change for 4.0-dev for human testers.

Pull request for Joomla 4 is #35981 .

@imanickam Please test. If you can test with both 3.10.x and 4.0.y, test #35980 , too . Thanks in advance.

Closing as having a pull request for each 3.10 and 4.0.