Not sure about this one, except if we have a new Language policy to not accept Language packs containing only the site part.
If the policy has not changed, we have to keep both files in sync (as we do for lib.joomla.ini)

If the component doesnt use the site language file it is silly to include it. It is not a language pack - it is part of a language pack

When in frontend, the code should check for the presence of a specific xx-XX.com_media.ini language in back-end and use the frontend one if not present. This is not very hard to implement.
Otherwise the language policy has to be modified.

It already uses the language file that is in the admin - thats why the front end file is not needed as it is NEVER used as stated by @puneeth2001 . But hey if you want to have translators wasting their time translating something that is never used then go for it. Seems stupid to me but what do I know.

PS Where is this language policy documented as I am pretty sure this is nothing to do with that policy

It is never used because the code is not there to let it be used.
It would not need to be translated because it would be the same file as the backend one. Copy/paste.

It would not need to be translated because it would be the same file as the backend one. Copy/paste.

That is still extra maintenance time keeping two files up-to-date versus only one. It might not be a time tedious task but the point is it is extra work that could potentially be avoided.

Go ahead and waste everyone's time 😊 doesn't effect me. But if you want to know why we don't have completed languages things like this explain why. Oh and you can't just copy paste a file with crowding ;)

"Potentially" means that site-only packs would not get the ini.
If this is what you want, fine.
At this time both files are loaded in frontend

We can, evidently, ask tts to translate the admin file if they want it in frontend (who would not want it...). This is what we already suggest to them for some plugins.
doc: https://docs.joomla.org/J3.x:Making_a_Language_Pack_for_Joomla#The_Site-only_pack

In any case, we should not load the frontend com_media.ini any more. This is missing apparently in this patch.

Since Crowdin was mentioned, there the string is automatically translated for the other file. No copy/paste is needed.

Also please alpha order all strings in the ini.

I don't really care about people's personal feuds or whether one person thinks the other is always wrong or anything like that, but my two cents here. I tried going through Crowdin a couple years ago and getting en-US up-to-snuff (and at one point would've been OK with maintaining it), even on an English-to-English translation it was still a lot of time spent on what felt like duplicated/wasted efforts and fighting to understand where strings are used or why they exist in the first place (anyone remember #14555 ?). So as someone who has tried to put in time in the translation workflow, my opinion is if there is a true technical need for core to have both admin and frontend com_media files then PLEASE document it so it is understood why you are translating two files that should be pretty much in-sync 100% of the time (same goes for everything that looks close to duplicated effort, here's looking at you en-GB.ini and en-GB.lib_joomla.ini). If there isn't a technical reason in core then removing the duplicated effort by default is the better approach (and the "if the file doesn't exist on Crowdin then it can't be translated" argument really sucks to me, I still maintain the project should have built its own translation platform instead of using a third party tool because of the uniqueness in the project's workflows, and said platform could have also helped with some of the administrative work such as packaging and publishing updates without the need for local tools, even if that tool is just right clicking a bunch of files and creating a ZIP package).

In any case, we should not load the frontend com_media.ini any more. This is missing apparently in this patch.
@puneeth2001 said it was not being used

Without looking deeper into this PR, I would try it the other way around. Remove the backend one and use the frontend also in the backend.
This way it works also for language packs that contain only the site languages but still doesn't need a duplicated file.
The same could be done for the library one.

@Bakual
Alas, deleting site or admin inis which are normally used in admin AND site would still create issues when creating overrides, except if the code there is heavily modified and inform the user of what is loaded and where.
At it is now, when creating an override and you do not know the Constant, and even if you know the value, the search would not return anything in their respective client as it depends on the existence of the file in that client.

closing as ini files have been modified and was decided to leave the frontend ini.
It will still be necessary to clean up both files of unused strings in 4.0