Would we can do something similar for the CLI app ?

I guess. Personally, though, I'm not a fan of this duplicate file approach.

Note: change in language packs format

The new J4 packs format will be (example with sub-zips fr-FR)
pkg_fr-FR.xml

	<files>
		<file type="language" client="site" id="fr-FR">site_fr-FR.zip</file>
		<file type="language" client="administrator" id="fr-FR">admin_fr-FR.zip</file>
		<file type="language" client="api" id="fr-FR">api_fr-FR.zip</file>
	</files>

The api_fr-FR.zip unzipped gives:
for the install.xml

	<files>
		<filename>fr-FR.ini</filename>
		<filename>fr-FR.lib_joomla.ini</filename>
		<filename>fr-FR.localise.php</filename>
		<filename file="meta">install.xml</filename>
		<filename file="meta">fr-FR.xml</filename>
		<filename>index.html</filename>
	</files>

index.html is no use, just a remaining of com_localise

The lang files will be modified in the future to not include the prefix.
fr-FR.xml = langmetadata.xml
fr-FR. ini => joomla.ini
fr-FR.foo.ini => foo.ini

@infograf768 Actually I don't know if this is the correct format or what files should be included for API. This is just for testing purposes.

Understood that. It could be it's only joomla.ini (former fr-FR.ini).
The important is the new pack format which have to be used by TTs

Language class doesn't support API's localise.php yet. We should either add it there or remove from the language pack. Whatever George decides.

com_languages also needs adjustments.

Is there ever any difference between localise.php in the different envs? @infograf768 would you prefer to have it duplicated per application or have 1 per env to allow separate packs per application?

I don't see why we would need separate packs per application. It would be a regression to not use a single pkg but single extension install as we did in 1.5 (see http://joomlacode.org/gf/project/jtranslation/frs/ )
The only reason we have 2 localise.php files was to allow some TTs to propose at least site translations in their package (plus some plugins lang files in the admin part as they are used in front.)
When included in both admin and site app, they should be exactly the same.
Similar reasons and behavior for the lib_joomla.ini

No idea if they should or not be present in api as I have no idea what that is for...

@infograf768 Shall we test this PR as it is? Or does it need some changes?

@richard67 please test

@SharkyKZ We also need to fix this part

@wilsonge What now? Shall he fix that in a future PR and I shall test this? Or shall he fix that in this PR so I shall wait?

Needs fixes :) realised this after I posted. I mean this will fix discover but we may as well fix these other small things whilst we are at it

Well it deals with discover, maybe that's why you discover things ?

@richard67 ready for testing

I have tested this item ✅ successfully on 6b1ef87

Tested as following:

1. Made a new, clean installation.
2. Installed the 2 language packs from testing instructions.
3. Deleted configuration.php and database tables and made again a new installation.
4. Checked "Discover": Result: Of both language only admin and site were discovered.
5. Applied the patch of this PR.
6. Went again to discover view and used button "Discover" to force a new run. Result: Of both language admin, api and site were discovered.

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/27711.}

@wilsonge Done.

Thanks!