Example German language pack:
pkg_de-DE.zip

A more complex language like Persian would have to be a bit more creative since it also has media files which shouldn't end up in the language folder. Have a look at the site folder to see how it's done:
pkg_fa-IR.zip

Makes a lot of good sense to me

I have tested this item ✅ successfully on f2f6f62

Any reason why this is not merged yet?

@horus68 you can use that in your language pack. As no core change is needed that this work.

Any reason why this is not merged yet?

@horus68 Mainly only one person which tested it. We usually want to have two people.

Also i think for the core supplyed version we can still use the current way this makes it clear which files has been added using the history ?

@zero-24 I don't see the point to have such list. There is no other place in the Project with a list of added files for any other part of the code, just for languages. If redundant, remove.
The main reason to remove its the way Crowdin works: every time a file is added all the XML translations are messed up, and we need to delete previous and translate again (every file needs to have our language code) and it take me 5 to 15 minutes each time there is a change in XML from Git.

• If I do not translate all XML files (if my translations is not 100% ) I'm not able to download it from Crwodin.
• So there is no use on creating a local version of the XML.
  Actually I create my language zip pack directly from Crowdin, no other edits are required.

All I want is to work the minimum required to have a great translation.

Than @Bakual needs to fix the conflicts and you need to test this PR ?

Rebased the PR and fixed the conflicts.

@zero-24 tested: installed and uninstalled ok. All working, all files installed, no files or folder left behind after uninstall.
Joomla 3.7.rc3 / Firefox latest on Windows 10 / Wampserver apache 2.4.18
PHP 5.6.18 and 7.0.11 / MYSQL 5.6.17

@horus68 can i set this as succesfully Test?

@franz-wohlkoenig yes indeed!

@horus68 thanks, done in Tracker.

I have tested this item ✅ successfully on 4130212

Works perfectly on J3.7 RC-3

RTC after two successful tests.

I am still concerned about this change:
We may get extraneous files installed in the language folders if a TT is negligent (simple example are .bak files, not a big deal, but can be worse).
Please do not reply that a TT should not be negligent...
For Persian and Dari using specific calendars, I guess it would not be a problem if their specific js is also present in the language xx-XX folder.

For Persian and Dari using specific calendars, I guess it would not be a problem if their specific js is also present in the language xx-XX folder.

That shouldn't be the case with the new calendar, all files are already shipped by Joomla at media/system/js/fields/calendar-lacales

That shouldn't be the case with the new calendar, all files are already shipped by Joomla at media/system/js/fields/calendar-lacales

Nope. They still need their own js for the dates displayed in the columns and wherever dates are displayed (Created,etc.) as the new calendar only concerns the date fields.

I am still concerned about this change:
We may get extraneous files installed in the language folders if a TT is negligent (simple example are .bak files, not a big deal, but can be worse).
I agree with JM

We may get extraneous files installed in the language folders

By that logic we should deprecate the <folder> tag for all extension adapters because this is an issue for all extension types and the only person able to do something about it is whomever is creating the package. So yes, it does mean that the packager has an additional responsibility to get things right.

For Persian and Dari using specific calendars, I guess it would not be a problem if their specific js is also present in the language xx-XX folder.

They could use a slightly different package structure and XML file to prevent that.
Or of course still create the list of files as it is currently (com_localise does that automatically), that will always work.

Tested successfully on Joomla 3.7, all files installed and uninstalled correctly.

We may get extraneous files installed in the language folders

As stated by others this is not any valid reason for not doing it. If translators is unable to make a language pack themselves, they should really start using tools who can automate this for them, or else someone has to do it for them. It's a bigger concern to me that people are still struggling with getting the darn install.xml right, no mater how they make their packs. It's just a pain in the ...