@Amire80 @ppelberg Regarding "recycling" messages, the new mobile interface is in fact going to use the same messages that are already used in two places, on desktop and in the old mobile interface. I think this is fine (the text represents the same concepts and the same actions in all of these interfaces), and even desirable (I think it's useful for mobile and desktop users to see the same language: to make it easier for a person to switch between the two interfaces, and to avoid miscommunications when discussing between people using different interfaces). We've had some issues in the past with translated messages not fitting, but we usually solved that with changes to the interface (e.g. allowing line-wrapping).
I would like us to change the "Unlink" label to "Remove link", because:
- It feels like a jargon word, appropriate for us to use internally (e.g. in the name of the icon :) ), but not in the interface intended for people with varying degrees of experience
- We do not use "link" as a verb elsewhere in the interface, only as a noun, e.g. "Add a link" not "Link"
- I think it would encourage poor translations that feel even more jargony
- We have more than enough space in the interface, so we do not need the brevity
- I am not sure if "unlink" in this meaning is a real word in English. I checked a few dictionaries online and if they defined "unlink" at all, the definition is only about detaching physical things, not about hyperlinks (while the "link" verb has a separate definition for hyperlinks on the web)
Thu, Jun 20
This would allow for posting messages cross-wiki from wikis that do not have Flow installed to those that do. Example use case is VisualEditor's "Leave feedback" dialog.
Sorry about the mess, I didn't realize that.
And it's live! (with help from @Jdforrester-WMF)
We deployed the patch, but when testing, I realized that the production wikis are still running software version wmf.8 (from ~two weeks ago) rather than wmf.10 (from this week), and so the new code for mobile contexts is not deployed. Apparently there have been some issues with it, see T220735: 1.34.0-wmf.10 deployment blockers (not related to VisualEditor).
So, we fixed one use of this message: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GuidedTour/+/516270 but apparently there are others…
We removed the message from VE in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/516266, it's supposed to be unused.
Scheduled for deployment today: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190620T1800
@Ryasmeen Ed's fix for the Android issue should be available for testing on Beta soon (I'm not sure how long it takes to update itself).
Wed, Jun 19
Scheduled for tomorrow: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190620T1800
I believe this should be tracked separately from T225354, because I was just able to get the patch for that issue to merge, while the patch here is still failing.
Tue, Jun 18
VisualEditor is already enabled on your wiki and it's the default editor. Can you clarify what exactly you're requesting?
"format": "block" in templatedata instructs Parsoid to reformat the template, and that's why the initial spaces are removed. This is the expected behavior. To avoid this, you can define a custom format if the spaces are always desirable (https://www.mediawiki.org/wiki/Help:TemplateData#Custom_formats), or you can remove the "format": "block" so that existing formatting will be preserved.
Yes, probably the same thing.
@ppelberg This happens very inconsistently for me, like 1 in 20 tries or even less often. I was able to capture it after trying for some time:
It also seems to be a recent regression in our code, I randomly picked a commit from February and this doesn't happen in that version. I'm bisecting now.
This only happens in Chrome. It works correctly in Firefox and Edge.
- Scroll all the way to the top of the page (exact location on the page seems to matter)
- Click next result (">") lots of times....
- #16 and #17 are barely on the screen (see screenshot)
I can't reproduce.
@Reedy Removing reviewers and reviews definitely has been possible for a while, but I am pretty sure it used to only be available on open changes.
(oh sorry, I didn't notice the backport)
I agree that this would be pretty cool.
Back to the main issue at hand – I am not sure if it would be good to do it.
Actually, make that a major correction. append(), as far as I can tell, does not call remove(), and therefore does not remove event handlers from the element being appended. You can see it in your demo, by noticing that the 'input' event handler continues working after being called for the first time and calling append() on the element.
As I was testing the new patch, I noticed another issue on iOS. When VE scrolls the page to make space for the native context menu below the toolbar, the native context menu itself remains in place – it neither scrolls with the selection, as it ideally would, nor does it disappear, as it apparently used to do a few months ago (T202723#4983015).
@Esanders The submodule update patch is failing due to some mysterious problems in ContentTranslation, can you have a look at it?
The problem continues to happen for me intermittently as well.
Mon, Jun 17
I'm sorry if I came off as rude, it wasn't my intention.
For the record, I think this issue should have remained an "Unbreak Now". It's an extremely glaring issue that makes the demos nearly unusable. And the doc.wikimedia.org site is the closest thing to production for the OOUI tag. It is disappointing to me if we really consider issues on it so unimportant (and yet we go to great lenghts to add annoying analytics code…).
@Milimetric That is incorrect. The original snippet was already wrong. See my patch https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/517548 for detailed explanation.
This is extremely silly.
If anyone wants to test the hack outside of VE, here's a simplified version I was initially testing with.
I can reproduce this on my iPhone SE as well. It only happens when tapping inside the editor for the first time after opening it, or after you dismissed the keyboard using the tick button on our toolbar (not the "Done" button on the keyboard). Although on my device it happens a lot faster (you can miss it if you're not looking for it).
Unfortunately the VisualEditor repo is unwisely configured in a very restrictive way so that no one other than Jenkins-bot can merge changes.
Fri, Jun 14
(QA is happening on T221311)
(oops, was already marked as Verified)
You can now use the config variable $wgVisualEditorEnableNewMobileContext = true; to enable the new version of mobile contexts.
Actually I will split this change into a separate commit. It is not really related to the other context changes, and it seems to be the only functional change in that commit that affects both old and new contexts.
(still has patches for review, I assume this was accidentally closed)
@Esanders rediscovered this issue while working on changes to contexts on mobile:
Thu, Jun 13
No need to backport anything.
Ed reviewed and merged the changaes, and the new loading indicator can now be seen on Beta, e.g. https://en.m.wikipedia.beta.wmflabs.org/wiki/Digital_object_identifier. It will go live on production sites next week, 18-20 June, per the usual train deployment schedule.