Talk:Synchronizer

Edit summaries
@Sophivorus: I tested this out a few times and it seems like it is not always creating edit summaries correctly. MediaWiki:Synchronizer.js appears to be trying to create a link with an interwiki prefix (with things like ) however it looks like it sometimes bases this off of Wikidata sitelinks which use database names and not interwiki prefixes. I do not think you want to attempt to maintain a complete mapping. You would be better off linking through Wikidata since it already knows how to link to each page via its sitelinks, e.g.,: Notice how the database name  is now useful when used in conjunction with   at Wikidata.
 * Edit a summary that seems good: 1144856459
 * Edits with problematic summaries: 71665579 13075854 24722031 5827927
 * Should have had more useful summaries like: Update from master using Synchronizer
 * Edits with problematic summaries: 71665579 13075854 24722031 5827927
 * Should have had more useful summaries like: Update from master using Synchronizer

You should do away with hackery like  (luckily it seems this is only used to create the "master" wikitext link in the summary). Instead, use master wiki database id combined with the Wikidata item id to create the "master" wikitext link for the summary by going through d:Special:GoToLinkedPage (using something like  and   if I am reading the code correctly).

I would attempt to edit it myself but I do not have access as I am not an interface/UI editor like you are (at least for the next few months anyway). —Uzume (talk) 00:51, 16 March 2023 (UTC)


 * You might want to consider adding a hashtag to these edits too. See Hashtags. Even better (but much more difficult) would be figuring out how to add a revision/change tag. See Manual:Tags and Help:Tags. —Uzume (talk) 01:15, 16 March 2023 (UTC)
 * The definition of which site is "master" also seems fragile (and perhaps flawed), e.g., contains text   and yet "master" seems to be defined for that at User:Sophivorus/sync by master on the template and module at the button creation site (which can be different from page to page across different wikis). Perhaps you should consider a more centralized method of defining that like a sitelink badge. —Uzume (talk) 12:42, 16 March 2023 (UTC)
 * Another problem with this tool is lack of attribution since you are not importing changes (likely due to permission issues). This makes me wonder if this tool would not be better implemented as a bot at toolforge or similar. —Uzume (talk) 12:42, 16 March 2023 (UTC)
 * @Uzume Thanks so much! I was unaware of d:Special:GoToLinkedPage and it was just what was needed. I just updated the code to get rid of that ugly getInterwikiPrefix method.
 * I was also unaware of Hashtags! I just added #synchronizer to the edit summary.
 * As to change tags, I agree they are much more difficult. Adding them to the API edit request is trivial, but as you probably know, the tag needs to be proposed and approved independently in each wiki for it to work in that wiki. I did that for Proveit on several wikis, and it's just not worth the effort. However, if you're interested in tracking edits in a specific wiki, feel free to request the tag there and I'll be happy to add it to the API edit request.
 * As to the inconsistent master with Module:Transcluder, you're right, I was transitioning to enwiki as the master version and you caught me mid-way. I just started updating the comments to point to enwiki as the master version. As to sitelink badges, I didn't know about those! They sound great, but I wonder if the benefits they promise are worth the added complexity for new users of Synchronzier. Perhaps by having a fallback system in which if no sitebadge is set, the "master" parameter is checked, and else the current wiki is considered the master? I'll give it some thought and would be happy to hear yours!
 * As to lack of attribution, perhaps the tool could check the usernames of the revisions being copied and write an edit summary like "Updating from master via Synchronizer, contributions by Foo, Bar and Baz"?
 * Thanks for all the help and new info I was unaware of! I've been editing and hacking wikis for 10+ years and I'm always amazed to keep finding new stuff! I'm looking forward to your thoughts and replies, and please let me know of any more issues you find or features you'd like to see. Cheers! Sophivorus (talk) 13:01, 16 March 2023 (UTC)
 * @Sophivorus: Cool, that looks much better:
 * 741359519
 * And it will work with any sitelinks at Wikidata even the more esoteric ones like wikimania and it is future proof too.
 * As for sitelink badges, I believe it would make sense to get a badge made for Wikimedia multi-site master page. They are just flags on the sitelinks. As such they do not enforce that only one sitelink for a Wikidata item has such, so yes, some methodology would be need to manage that. You mentioned a "fallback system" for ensuring such but I would rather the script instead provide a means to edit the Wikidata item (not unlike how its sends edits to the other sites for for synchronization) specifying such when an item does not adhere to "exactly one sitelink needs to have the master badge". It could also provide a small button at the top of the synchronization table to allow one to respecify such later affecting the ability to "rehome" like you are doing with (from   to  ).
 * Another thing you might want to consider is having the button generation be more error proof. This only works with Wikidata but the button generator does nothing to ensure such (the Scribunto Lua module could check Wikidata at page render time instead of the script failing at button press time). I would much prefer the interface to the script be the Wikidata item ID and not sitelink and database siteid. The button generator could allow specification of the Wikidata item via either its QID or sitelink with optional siteid (defaulting to local; see ). The latter provides for ease and backwards compatibility and it makes sense for the button generator to provide an error when it is unable to come up with a valid QID. I believe the button label should default to the Wikidata item label instead of the provided master sitelink (as it currently does).
 * And on that note, if the script has a Wikidata item edit capability it could ensure other things like the language labels be synchronized to the sitelink values (somehow; that might get tricky) and it could add claims of or  to its  statements or something too.
 * —Uzume (talk) 15:16, 16 March 2023 (UTC)