Pull Request for New Issue (see also #12308).

Summary of Changes

In a multilingual install with associations, there are several issues with the item language and associations:

1. You cannot add associations when creating an item. Currently you need to:

   • Create and save the item
   • Add the associations and save again

2. You cannot change a content language when editing an item. Currently you need to:

   • Edit the item and remove the associations first and save the item
   • Edit the item again, change the content language and save again
   • Finnaly, Edit the item again, change the associations and save again

3. You cannot add associations for unpublished content languages (but you have them across the backoffice)

Clearly, IMHO, this is not a very usable workflow and it comes with issues.

This PR should make that workflow a lot more easy, just add associations, and change the language whenever you need and save (one time).
Also allows to add associations for unpublished content languages.

Note: the only exception is the create/edit modals that will continue to not have Associations tab.

Testing Instructions

1, Do a code review (hint: use https://github.com/joomla/joomla-cms/pull/12344/files?w=1 to ignore whitespace changes)
2. Use latest 3.7.x, multilingual with associations enabled
3. Apply patch
4. For article, category, contact, menu item and newsfeed items check:

• When creating an item (try changing the languages, adding associations)
• When editing an item (try changing the languages, adding associations)

Documentation Changes Required

None.

Notes

Introduced two new methods: JLanguageHelper::getContentLanguages (get the content languages from #__languages) and JLanguageHelper::getInstalledLanguages (get the installed languages from #__extensions table).

Why this methods and not using JLanguageHelper::getLanguages()?

• because JLanguageHelper::getLanguages() always return the published languages ... there are several cases we need the unpublisehd ones too ...
• JLanguageHelper::getLanguages() does not check if the content languages are installed which, of course, can, and will, lead to errors if you, for instance, uninstall a language package without removing the content language.
• because JLanguageHelper::getLanguages() is not IMHO totally semantic correct: get what languages? installed languages? content languages?
• among more things

This two methods will allow to do all languages related stuff across the core in the future (replacing several hardcoded queries, etc). I intend to do that step by step is this accepted.

@infograf768 as talked