Thank you for your contribution. Please can you review it and resolve the following

1. Comments should be in english only (not french and german)
2. Code should not be commented out
3. Please resolve the conflicting files
4. Please look at the codestyle - specifically the indentations/tabs See https://developer.joomla.org/coding-standards.html

In addition to Brian's findings:

• Option names should not be in German here: https://github.com/joomla/joomla-cms/pull/17881/files#diff-1f7598604d325c4356abf84f682138b6R30
• In Joomla core the author in the manifest xml file is "Joomla! Project" and not a person like it is here: https://github.com/joomla/joomla-cms/pull/17881/files#diff-4a2052239b149da5a477637cddec85e5R5
  (There are a few exception when things were taken from 3rd party creators like e.g. Akeeba, but these are rare exceptions).
  => Like this PR here is now it should not be accepted.

Thank u for your feedback.

I have made some changes. can u please check it again ?

Indentation issues

German comments

Conflicts

Thanks brianteeman.
Is it ok now?

My screenshots were just examples. I still see lots of the issues I first mentioned - github will show you all the issues - please review them all

And you have conflicts :)

i think, it should be ok now

@christianboulbi - No, there are still loads of code style issues. Refer to the docs: https://developer.joomla.org/coding-standards/php-code.html

and you have conflicts, so you'll need to fix them

Apart from the obvious errors I found (see above) and a lot of coding standards corrections to do (+ postgresql impossible to merge), + a few glitches (Target article Checked out after Save Approved) I am not sure this approach is the one we need.

Basically, and whatever the way the UI is displayed, I think we must always have a fixed reference language (Parent should be in the refernce language) and the possibility to filter stuff by outdated, not associated or up-to-date.

The problem is when you change languages.
Below, Article English has been modified in the Articles usual UI.
Therefore the FR icon displays as orange with NOT approved.

But, if I switch to French, I get

This is really misleading and therefore the reason why I insist on choosing always the same reference language.

I guess the new plugin is used to mark as Not approved the associated article when the "Parent" is modified. Unhappily, it is specific to articles, i.e. any other possible association (categories, menu items, contacts, etc. are not concerned.

Please read this:
#17802 (comment) to further understand my comment.

As you can see there, my feeling the only way to deal with this is dates/comparison.
The use of a new table as you do here could be the way to go.

infograf768. Thank u for your feedback.
if you change a master article, all slave-article of this article still need to be approved.

The sql CREATE TABLE has still not been updated.

@perrez

if you change a master article, all slave-articles of this article still need to be approved.

That is not my point. Obviously, whether you call it approved or up-to-date the new status should be easy to find and act accordingly, the issue is that one has to have only ONE master article (or other type of item).
IN the existng UI, switching languages will change the Master. We do not want that. We need to set a specific language as MASTER for the site in order to be able to get a usable feature (with filters, etc.). Please re-read my proposal in the other PR and both screenshots above where the problem displays perfectly.

We should not have to click on "Save Approved", but just saving the Target would make it automatically Up-to-date.

This means that if we have a new table to store correctly the modified date, and add this for every component when Assoc is on, Multilingual associations will know by date comparison if the target is Up-to-date or not.

Example:
I have an article tagged to English and the Default site Reference language is English (as proposed in the other PR).
The language filter plugin is set to use associations.
When saving this article, it will not only save it in the content table but also save its id, type and modified date in the new table (can be item_associations if you wish).
As the current Multingual Associations main page is not set for this — one can choose a reference in ANY language — we would have a new page ( the STATUS page) specially aimed at comparing THE MASTER to its SLAVES, letting filter the slaves per language used in the site or all languages (obvioulsy without the refernce language) and status.
It will then be real easy to know what is or not Up-to-date, etc.

On the Face to Face page (same one or a new one), once decided or not to change the Slave (or also maybe the Reference too), Saving Target would also Save the Reference and enter in the new Table the same Modified date, therefore updating the STATUS page where we compare MASTER to SLAVES when we go back there.

@infograf768
Thanks for the proposal of adding another Attribute to our table that will save the initial Article which has been changed and serves as Master. That is a good idea .
But our aim is to give the user the possibility to be able to manually check (approve) the Slave Article. The Master article is the article without a parent article and it can derive the children article

As a extension, we will want that the Slave Article which has already been checked should also become a master article.

Sorry to disagree. If you are not implementing a specific language as master, this will be totally confusing.

Yup, agree with @infograf768, without setting a master language and comparing modified dates, this can cause some troubles, his solution looks the most elegant for this problem

Going to close this one as after a year without update it has clearly been abandoned. It can always be reopened if updated.