Yes, they should. Translation Teams need them in core for their language packs.

Then I have two questions:
1) Why include translation to Joomla localization package for the component that is not included into Joomla package anymore? Maybe it's logical to have some sort of separate localization for weblinks component so that to leave the basic Joomla distributive as clean as possible.

2) Who is going to update these weblinks localization files here (I checked, these files are not updated), if there is another repo specially for this weblinks component?
https://github.com/joomla-extensions/weblinks

Why include translation to Joomla localization package for the component that is not included into Joomla package anymore?

This component is a bit special as it is core supported, although not shipped in new installs.
So the answer is: Because we have not set yet a specific way for TTs to create and upload their files in a specific place where these would be automatically available for updating, etc. The weblinks package should not include 65 x 7 ini files.
Basically, it is not as simple as it looks... Much simpler to include them in core and therefore core lang packs.

Who is going to update these weblinks localization files here (I checked, these files are not updated)

Some one has to port any change in the weblinks github repo to core. Volunteers are welcome to do a PR.

Why include translation to Joomla localization package for the component that is not included into Joomla package anymore?

Back when Weblinks was decoupled, it was decided to leave the language files in core to make life easier.
With Crowdin, it would be possible to update the files from the Weblinks GitHub repo. But for the translators working with other tools (com_localise, text editor, whatever) that doesn't work.

And as said by JM already for the users it's much easier to just take care of one language pack instead of having to install a separate one for Weblinks.

Who is going to update these weblinks localization files here

I think if there is a release for Weblinks, the language files should be ported over. But not sure if that was done.

crowdin already supports 3 joomla extensions https://crowdin.com/project/joomla-patchtester
so imho it should support weblinks too

@andrepereiradasilva
The situation is not the same at all. + look at which languages are really translated in the list of 34 languages which I guess are installed with the following plugin.
Example: https://github.com/joomla-projects/plg_content_joomlarrssb/blob/master/language/pl-PL/pl-PL.plg_content_joomlarrssb.ini
https://github.com/joomla-projects/plg_content_joomlarrssb/blob/master/language/pt-PT/pt-PT.plg_content_joomlarrssb.ini

etc., etc.

There is no way to get these language files automatically proposed to update or install in function of the languages present on the site. If someone is installing this plugin as it is now, that is adding 68 files for one plugin, most of them untranslated.

There is no way to get these language files automatically proposed to update or install in function of the languages present on the site. If someone is installing this plugin as it is now, that is adding 68 files for one plugin, most of them untranslated.

I guess that it requires some modifications to the installer. Some extensions already act in this way... AcyMailing, after the installation of the extensions, the correct language is installed.

And what if you add a language to your site?

didn't try it. But it's not good to install all the languages at once.

i honestly don't know how crowdin / github repositories integration work (is it manual? it's automatic?) so i really can't comment on that.

@mbabker and @Bakual are the two who created sync scripts between Crowdin and the repos

I'm not getting involved in this discussion. It is ineffective to mandate separate language packages be created for every language an extension can be installed in, and it is ineffective to mandate that all Joomla supported extensions must have their language files as part of the CMS (even when their code is not) to be included in the "official" translation packages. I have made a decision with all of the extensions I manage (personal projects and Joomla tools) that no extension will place its files in the global language directories, therefore not requiring the need for separate language extension packages, and this comes at the expense of adding a few extra folders and INIs to a site.

FWIW, the RRSSB plugin is a terrible example to use to justify your reasoning. It really isn't intended for translation; as the plugin adding our sharing buttons on pages (i.e. https://www.joomla.org/announcements/release-news/5692-road-to-joomla-3-7.html ) only its backend configuration really needs translation and we are not "officially" distributing it. If you want to play "fair", patch tester if I'm not mistaken has the most active translations for a non-core extension.

I follow the same approach as Michael with my extension. They include the language files in the component specific language subfolder.

And what if you add a language to your site?

If the files are in the component folders (eg component/weblinks/language), then that is no issue at all. You can add or remove languages to your site and they will remain untouched. As soon as you add a language to the system, the translation is present.
From a user perspective it's the best solution as he needs to do nothing. It comes with the tiny cost of having a bigger package with more files in it.
From a translator perspective it's not so ideal since you need to have the translations ready when the extension is released. Similar to what we have with our core installation language files. If your language files are updated, you need to issue a new release of the extension to get it to the users. Here a language pack approach is better since the translation teams can just release a new version of their pack independant from the extension.

Now there is a possibility to get the best of both worlds: You can include the languages with the extension in its component specific folders AND offer language packs which install into the global language folders. Since the global language folders take precedence over the component ones, they allow "overriding" the extension files. That's what I personally do with my SermonSpeaker. When releasing I pull the latest translations from Transifex, and there is a possibility to install "nightly" language packages which are generated automatically when new translations are done.
There is a drawback here as well: If you have an outdated language pack, you never see the newer files from the extension. Uninstalling the language pack will fix that.

i honestly don't know how crowdin / github repositories integration work (is it manual? it's automatic?) so i really can't comment on that.

I have a cron job which runs each night. It first triggers the generation of the zipfiles on Crowdin and afterwards uploads the latest source strings from GitHub to Crowdin.
I don't know how Michael does the syncing of the other projects.

I have a cron job which runs each night. It first triggers the generation of the zipfiles on Crowdin and afterwards uploads the latest source strings from GitHub to Crowdin.

I was meening the opposite, ie, what is the process of updting the translation files in the repositories via the crowdin translation. It's manual right?

I was meening the opposite, ie, what is the process of updting the translation files in the repositories via the crowdin translation. It's manual right?

Yes. I'm using https://github.com/joomla-projects/crowdin-sync for all of my Joomla "official" projects except the issue tracker.

Yes, that is done by the translation teams as they still have to put those up on JoomlaCode (as far as I know).
The package itself can be downloaded directly from Crowdin for the most languages. However some of them need manual replacing of the localise.php file before they create the zip package.

oh no ... didn't notice JoomlaCode still existed ?

I am closing this. As stated it is the intended behaviour.