Context
After T430178: 🧹 [Epic] Measure diffs in a small sample of Wikidata-injected recent changes, we already know that a large proportion of RC logs come from site link activity (mostly additions, but also removals and edits). LLL represents Language Link Logs in this ticket.

We assume that these logs are low-value notifications since they do not affect the content of their associated Wikipedia articles. We also assume that editors will not miss them. We assume that displaying them differently (either silencing them by default or adding a filter to display them) will improve the editor's workflow T430849: [EPIC] (LL) Understand impact to users/editor-sentiment on language-link-added Watchlist notifications and Recent Changes entries.

In order to validate our assumptions, we will proceed by:

• Drawing a data flow diagram from where the edit in Wikidata is made up till the RC log is displayed on Wikipedia T435902: 🍂 Draw data flow diagram from edit in Wikidata is made and till RC log is displayed on Wikipedia (😾)
• UX decision on filter structure . Consider LL sub-categories and their importance (LLs to other languages vs LL to this language) T435904: Identify options and workflows for filtering RC logs coming from wikidata (😾) - DONE: for now we are just suppressing them without adding a filter, in a new epic
• Engineering: Adding filter(s) based on already existing log categories in client code, one of them is already sitelink - TBC exact categories of filter

After the filter is ready:

• Make LLL filter false default for some pilot wikis. (to-do: decide on the pilot wikis and communicate with them). See this approach taken by the language community team to test main page customisation kits and how it could be interesting to us: T420075: Test main page customization feature with selected new communities
• Put stats in the filter so we can monitor whether anyone is turning this filter on or whether people find these logs helpful.

Further follow-up for after this epic:

• If we conclude LLL are not useful for the great majority, it might make sense not to store them in the DB,
• Explore edge cases for editors who use these logs, a promising alternative proposed here: T435460: 🧹Can Language Link logs be observed through an API call