Last modified: 2014-11-20 09:05:16 UTC
https://meta.wikimedia.org/wiki/Special:RecentChanges When a user visits Special:RecentChanges, they expect to see their recent changes. The "filter translations" menu can make it really difficult to see recent changes. We may want to default to "do nothing." Relatedly, the Translate extension seems to consider any MediaWiki page a translation page, when this isn't the case. This needs further thought.
You can set the default value with configuration option. What further thought is needed?
(In reply to comment #0) > Relatedly, the Translate extension seems to consider any MediaWiki page a > translation page, when this isn't the case. This behaviour is documented at [[mw:Help:Extension:Translate/Statistics_and_reporting#Recent_changes.2C_feeds_and_logging]], so it's apparently expected.
The further thought is whether Translate.php should be setting $wgTranslateRcFilterDefault to 'noaction" or 'filter' in the source repo: it is about the default default, rather than the default for a given site. In favor of the current state ('filter') is that those enabling the Translate extension may not want their RecentChanges page filled with translation reports by default (or to force all their users to take action to avoid seeing translation reports). In favor of 'noaction' is that users who install the extension may be confused after installation when their changes are not reflected in RecentChanges if they have not read the documentation completely. Alternately, the use case that causes confusion may be able to be avoided in another way, rather than just adjusting the default default.
In reply to comment 3: Many years ago, Niklas and I made the decision to make the default value that translations are filtered out by default as to not flood the default Special:RecentChanges. Because we wanted to enable anyone to have a different opinion about that, we created a setting to configure a different default behaviour on a per-wiki basis. There are no reasons to change the default in the extension code. If a certain wiki community is of the opinion it would like to use a different default, that is possible. Does this mean that thought has been given, and the reported issue can be viewed as "RESOLVED | FIXED", or should more thought be given to anything in particular?
(In reply to comment #4) > In reply to comment 3: Many years ago, Niklas and I made the decision to make > the default value that translations are filtered out by default as to not > flood > the default Special:RecentChanges. Because we wanted to enable anyone to > have a > different opinion about that, we created a setting to configure a different > default behaviour on a per-wiki basis. There are no reasons to change the > default in the extension code. If a certain wiki community is of the opinion > it > would like to use a different default, that is possible. > > Does this mean that thought has been given, and the reported issue can be > viewed as "RESOLVED | FIXED", or should more thought be given to anything in > particular? The issue for me in particular was that it hid all MediaWiki pages per default, so any update to such page wasn't shown up in RC. I had no idea the Translate extension declared all MediaWiki pages as translations and per default hid them from RC. So yes, that should be addressed instead of marking the bug as resolved.
Same than @Carl to me. A user complained about the "MediaWiki:" changes not appearing in the recent changes and it tooks me pretty much time to understand the problem...
Change 97699 had a related patch set uploaded by Nikerabbit: Remove default NS_MEDIAWIKI from $wgTranslateMessageNamespaces https://gerrit.wikimedia.org/r/97699
Change 97699 merged by jenkins-bot: Remove default NS_MEDIAWIKI from $wgTranslateMessageNamespaces https://gerrit.wikimedia.org/r/97699
If this further thought was enough, we'd have to update the docs and close this.
(In reply to comment #9) > If this further thought was enough, we'd have to update the docs and close > this. [[m:Special:Version]] currently says "Translate (Version 2013-10-28)". Any idea when the extension will be updated on Meta-Wiki? This bug is likely fixed, but without Gerrit change #97699 being deployed to a Wikimedia wiki, it's difficult for me to say for sure.
