Mon, Nov 20
Another note here: The exception triggered in T176871, that occurs in the middle of the import seems to lead to an automatic "rollback" of the changes imported so far. Though I did not manage to figure yet how that works exactly.
@Legoktm Is it possible to remove a version tag? Or do we just remove the code and tag 1.5.3?
Ok totally makes sense, a bit bad luck that the changes to wikidiff2 moved really quickly this time and we have the placeholder in there already - but nothing set in stone yet we will just revert the patch and I will use the classes as hooks for the title.
@Krinkle yeah the info is already there form the CSS that's true and I also could have used these to sneak in the title attributes. But I thought it might be better to separate things here so and avoid bounding... sure, thinking of it, with JS I just would have don the same depending on the classes to set the title tags, and I really did that in a first attempt but got the remark, that it would be nicer to have this in PHP so it does not depend on JS. ..... hmmm :-)
Fri, Nov 17
Looked a bit into it and it always seems to fail when trying to import
"Update for current state of tool labs"
Also tested and fixed the timeless skin. see T180663
Thu, Nov 16
> Also the RSS feeds just show the dots since no styles are applied: https://www.mediawiki.org/w/api.php?hidebots=1&days=14&limit=50&target=Category%3AOpen_requests_for_comment&translations=filter&action=feedrecentchanges&feedformat=atom&hidecategorization=1 though I think that's probably OK, it's just a limitation of the RSS format.
I'm not sure if it's actually possible for this feature, but it might be avoidable if you can add appropriate replacements to FeedUtils::applyDiffStyle().
Wed, Nov 15
Looked into random mobile diffs on test.wikipedia.org and created some new changes and looked at the diffs. Got no error pages.
Tested ( Vector ):
- Firefox 56 LTR / RTL
- Chrome 62 LTR / RTL
- Internet Explorer 9 / 10 / 11 LTR / RTL
- Edge 14 LTR / RTL
- Safari 11 LTR / RTL
Tue, Nov 14
While working on this and starting a first approach with calling the API of the source wiki via CentralAuth token, we decided that the proper/better to do this is would be submitting a job on the sourcewiki that does the edit. We will work on that in another sprint and postpone the issue for now.
Looking at Special:Import and the connected classes, there seems to be no special handling for failed imports. It just failes and stops the import where it is. E.g.: When importing a huge dump via Special:Import and it times out, the import will be done until some revision and nothing else will happen.
So some findings from our yesterdays discussion ( feel free to add more ):
Mon, Nov 13
Anyone with gerrit account and git / gerrit skills can do that. But also for a dev its a 1min task. So also feel free to add it to qwerty board.
Thanks for all the example diffs, it's really important to see a bunch of variants in diffs to further improve the algorithm there.
I am adding screenshots for the last examples. I think we got the idea now and will write something to that in the next post.
Fri, Nov 10
Next example from the post: https://de.wikipedia.org/wiki/Spezial:Diff/170818650
I imported an example from the thread to my local wiki and opened the diff with an older version of wikidiff2 and the current version. Results:
Hmm tried it about 30-40 times and it always worked for me. ... There is an error in the JS console showing each time. But it's not coming from any AdvSearch code. :-/
Thu, Nov 9
Wed, Nov 8
Then I guess we can cherry pick that to the wmf branch? :)
Tue, Nov 7
If I remember it right from month back when we already discussed this once, this was more an architecture/coupling question to do it or not to do it: "Putting out HTML via C++ makes it hard to change and hard to reason where this comes from, so it > should be kept to a minimum" would be one hypothesis that spoke against need-to-be-translated tooltips in HTML.
Sat, Nov 4
D'oh! Yeah your right, we do not necessarily need JS for that. Somehow I thought "parsing" HTML the output of wikidiff2 and doing things there is kind of ugly.
Wed, Nov 1
Paragraph was moved. Click to jump to new location
Hey, the last weeks a major refactoring of the EditPage and TwoColConflict took place to change the way it hooks into the EditPage. TwoColConflict now does not override the EditPage and so it should work with ProofreadPage when it's deployed.
Mon, Oct 30
Fri, Oct 27
Also for clarification: The plan here is to have a default message hardcoded (without i18n) but with the option to be customized via a config var ($wgFileImporter....) - see T160182#3714953
So after a quick talk with @Lea_WMDE : The plan here is to have a default message hardcoded (without i18n) but with the option to be customized via a config var ($wgFileImporter....)
So my current idea to solve this would be:
- Adding some JS that looks out for the classes indicating a move paragraph in the wikidiff2 output.
- The JS runs wherever a diff is present and then dynamically adds a translatable title attribute to the tags there.
Thu, Oct 26
Wed, Oct 25
Ok found a way to reproduce it. A patch is underway :-).
Tue, Oct 24
Ok it's me again. I just tried to reproduce it by looking at the steps in the ticket linked ( T176104 ). I adjusted the steps to use the conflict simulation page