Thanks, forgot to close this task!
While this UI is not there, I think we should simply set a maximum of how many WD items are shown (e.g. at most 3, plus add an ellipses if needed)
The problem is we don't have room for even one Wikidata item. As soon as you start adding Wikidata items to that overlay, it wraps the attribution statement. Plus it seems like it might be confusing to show some Wikidata items used in the map and not others. Honestly, I don't really understand why showing the Wikidata items in the reader interface is needed at all. The Wikidata items are listed in the Wikitext. Any editor who wants to edit the map is going to look there. I agree it might be a nice-to-have feature, but it doesn't seem strictly necessary for now.
Sat, Mar 17
Fri, Mar 16
@ovasileva: I tried to find documentation about this new API, but wasn't successful. Searching for "Page Summary API" on MediaWiki.org lead me to:
- https://www.mediawiki.org/wiki/Extension:PageSummaries, which seems to be an unrelated extension
- https://www.mediawiki.org/wiki/Page_Previews/API_Specification, which seems to be the design specification for the API, not documentation for using the finished API
Thu, Mar 15
@Huji: I pinged legal to see if they have any concerns.
Wed, Mar 14
I agree that we should have consulted with the DBAs earlier. We went through 2 TechComm RfCs early on, but didn't ask for a DBA review until the end (partially because we didn't expect there to be any significant issues). Lesson learned.
As Brad mentioned, the most straightforward way to do this across the board is changing the constant in includes/CommentStore.php:
const COMMENT_CHARACTER_LIMIT = 1000;
Tue, Mar 13
@santhosh: Unfortunately, none of us really know how IME is supposed to work. Can you compare the current functioning of IME + Codemirror on the production wikis with a local IME + CodeMirror with https://gerrit.wikimedia.org/r/#/c/399460/ and https://gerrit.wikimedia.org/r/#/c/398602/ applied and let us know if it's an improvement?
Where does the GeoIP2 data come from? Is that included in the WMF's current GeoIP service?
Mon, Mar 12
@Huji: How are you planning on addressing the localization issue? i.e. localizing the place names?
I was under the impression it was going to be optional to restore your edit, like in James's mockup: T57370#2548772.
Sat, Mar 10
Fri, Mar 9
It seems like there are 2 related issues in this bug. One is the Wikitext editor converting formatting into the Wikitext (which might be helpful, if unexpected). The other is putting <nowiki> tags around any Wikitext (which really doesn't make any sense to me). I copy and paste Wikitext into Wikipedia articles all the time. The <nowiki> behavior is basically a blocker for me using the new Wikitext editor.
Here's the user script prototype:
I totally agree that we should allow long edit summaries, but none of the examples you cite are longer than 255 characters. If we look at recent edit summaries that are longer than 500 characters, we have: cut and paste of article text, SEO spamming, and excessive wall-of-text arguments. Unlike Gerrit, Wikipedia has talk pages, which are probably the best place to engage in lengthy discussions, explanations, and arguments. That said, I do think that 255 is too short, and that we should truncate aggressively in the UI (with links or hover for full text).
Hey Tim, I'm curious what your thoughts are on this. While I think everyone agrees that the summaries need to be truncated in the UI, the current community consensus (on English Wikipedia at least) seems to support reducing the maximum to 500 characters. Personally, I haven't seen any compelling use cases for summaries longer than 500 characters. Most of them so far are just from folks who copy and paste their entire edits into the summary. For reference, this comment is exactly 499 characters.
I'm probably not going to have time to help with this. I wonder if maybe @dchan would be interested in helping to troubleshoot this. It's related to both language input and editing :)
@Doc_James: How do you think speedy deletions should be handled? Is it worth notifying folks about those?
Thu, Mar 8
Also note that we don't have Legal/Privacy sign-off for doing Geolocation (but we do for IP address).
That would be great to post in the discussion.
Wed, Mar 7
@Esanders - The other two WYSIWYG features in CodeMirror are italic and headers. We should check both of those as well.
Is part of this ticket to setup translatewiki.net to push translations to the repo?
I'll make a separate task for that...
@jcrespo: One thing that hasn't been mentioned is that GlobalPreferences will almost certainly reduce the growth of the user_properties tables in the long run. Instead of users having to duplicate all of their preference selections across all the wikis they use, they will only have to set them once on their home wiki and declare them to be global. So the net effect on db storage should actually be positive in the long run.
I don't think this is the right UI for showing the data source of every item in the map. Ideally that information should be associated with the items themselves, for example, when you click on a pin and it shows you the place information, it could include the Wikidata link there (either as a text link or an icon). Trying to overlay all that information on the map itself just doesn't work, IMO.
Should part of this be done in TemplateData? e.g. a new class mediaWiki.TemplateData.TemplateFormatter that would handle the actual generation of the template text, including the formatting.
Seems like an awkward fit for TemplateData. I like keeping TemplateData as a pure data input layer. Generating the output should be handled completely by TemplateWizard, IMO.
I think writing any custom workflow code for a particular wiki is going to lead to a maintenance nightmare (assuming that CommTech is in charge of maintaining it). I would rather that we write something that is simple and generic, as suggested by Niharika. Of course the big risk is that it will be so simple and generic that no one will use it. My suggestion would be that we find one smallish wiki that would greatly benefit from an Article Alert system (even a very simple one) and wants to work with us. Then we build a completely generic workflow alert system with that wiki in mind and help them get started using it (but we keep it 100% generic). That way, we can be sure that our work won't be a total waste (it will be used on at least 1 wiki) and we'll have a nice example set up for other wikis to learn from. The only workflows it would support would be the ones listed by Niharika: a category or template is added or removed from a page. If people want something more complicated, they would have to folk their own version. Thoughts?
Tue, Mar 6
Let's just use "all wikis" instead of "all Wikimedia wikis" so we don't have to override it with WikimediaMessages.
Yeah, I think just removing the Wikidata info would be best. There's already a lot of attribution info competing for space.
The impact of this feature on the user_properties table should be less than introducing a single new preference. We're talking about an edge case of a power-user feature (overriding a global preference). As confident as I am that the impact will be small, I realize that words are cheap. Unfortunately, I can't commit CommTech to refactoring prefs storage, as the GlobalPrefs project is already a quarter overdue (mainly due to other prefs refactoring we decided to do while we were in there). I can, however, propose budget for an additional s7 db server as part of this project if you think that would be helpful (as the FY2018-19 budget is not yet finalized). How much would such a server cost? (Feel free to move this discussion to email if that would be more appropriate.)
I protected all the goats from being moved further.
Message or not, it should be explained somewhere how it works.. even if it is on the tool's wiki page.
Actually this was fixed as part of T141154.
I think we're overthinking this. IMO, the only change that is needed is:
- If no start date is supplied by the user, have the API query begin at the user registration date of the newer user.
Otherwise, you end up getting results like: https://tools.wmflabs.org/interaction-timeline/?wiki=enwiki&user=Kaldari&user=Funcrunch, i.e. you have to scroll through hundreds of edits by me before you see any actual interactions.
So this has several concerns, mostly related to "dead rows"- basically data on the database that is not live (it will never -or likely never- be read or written again):
- Local preferences overriden by global preferences (I am assuming that in most cases, people will want to setup global preferences once and forget -long term- about local ones)
We need to always give the user the option to stop overriding the local preferences, thus we have to keep storing the local prefs.
- [Implementation assumption]All setup global preferences will be recorded to the database, even if they are mediawiki defaults
I believe that's correct, but needed to avoid the pref changing if the default changes.
- Deleted global preferences will also be kept, in case they are reenabled
This should probably be handled by a maintenance script. We'll look into it.
@Tbayer: Nice sleuthing! BTW, now that the WikiVoyage Edit-a-thon is over, the pageviews have gone back to normal.
If we're just using the first revision date, there's no point in updating the UI to reflect this. It should just be an internal optimization. Setting the start date while the user is filling out the form is just overkill and potentially will cause problems. Clearly users can't "interact" prior to one of them first editing, so it should be fine just to leave the start date blank for those cases.
@TBolliger: I don't really understand this task. When someone loads the Interaction Timeline, there are no users specified, so there's no way to know the date of registration or first edit. That's why I proposed setting the default to today - 1 year. The alternative would be to wait until the user has entered 2 users and try to fill in the start date then, but having the page alter the form data at the same time that the user is filling out the form is weird and unexpected behavior (and could potentially overwrite the user's input if it takes a second or so).
Mon, Mar 5
Sorry, I was on vacation... Maybe we could change the error message to something like: "Multiple translation unit markers for one translation unit. Make sure that translation units are separated by empty lines."
It looks like we're going to have to implement some sort of long term fix for the UI issues at least. In the meantime, I would favor limiting the problem with a short-term front-end limit that we then remove once the UI issues have be resolved. Hard-coding wgCommentCodePointLimit to 255 in mediawiki.action.edit.js seems like it would take care of 90% of the problem (without negatively affecting non-Latin projects). (Note that wgCommentCodePointLimit isn't an actual server-side config variable, it's only in JS.) This would allow wikis to use 255 characters in the edit summary field, but still allow up to 1000 bytes. It would not affect API users, but from the examples cited in the discussions, that doesn't seem to be where the super-long edit summaries are coming from.
Sat, Feb 24
Feb 15 2018
Feb 14 2018
Oh, your right :) Maybe it's an example of something that's happening on a lot of pages though. The desktop vs. mobile percentage looks very suspicious (<1% mobile) and the increase seems to have started around the same time.
Seems to mostly be caused by a sustained spike in desktop-only views to the Zimbabwe page. Strange.
Feb 13 2018
Feb 12 2018
It's not worth maintaining an entire extension (which takes developer time away from other projects) just to support an uncommon edge case.
Feb 10 2018
- Add the thanks link to the end of log entries on Special:Log, but only for log entries that have an associated revision and make this like just do a normal revision-thank.
- Add log-thanks support to the API (action=thanks, type=(rev|log), id=123, source=blah; with the current rev=123 being deprecated). T186855: Add support for log-thanks to the Thanks API
- Update Special:Thanks to support log-thanks.
- Update ext.thanks.revthank module to support log-thanks.
Feb 9 2018
I reported @Fomafix's bug upstream: https://github.com/codemirror/CodeMirror/issues/5253, although it probably belongs even further upstream (at the browser level).
Interestingly, it looks like the blurry text may actually be two different bugs. In OSX Firefox in the new WikiText editor, it's probably caused by https://gerrit.wikimedia.org/r/#/c/394337/2/resources/modules/ve-cm/ve.ui.CodeMirrorAction.js, and in Windows and Linux Firefox, it's probably caused by https://gerrit.wikimedia.org/r/#/c/382023/4/resources/ext.CodeMirror.js, both of which are related to T95104. Needs some further investigation to confirm this hypothesis.
After doing some archeology, it looks like we actually turned off contenteditable in Firefox to deal with @Fomafix's keyboard shortcut bug (T95104#3634230). Considering all the Firefox-specific CodeMirror problems we now have, I'm beginning to think that Fomafix's bug might be worth breaking again in order to turn back on contenteditable in Firefox. Hopefully, we could find a better way to deal with Fomafix's bug (although it seems to actually be a browser bug as there is no JS involved).
Actually, I think this was caused by 29f6b48eebc0 (turning off inputStyle: enableContentEditable in Firefox). It seems we did that in order to disable CodeMirror's spellchecking, but the way we disabled it is probably overkill. We could actually just disable the spellchecking specifically and not all of contentEditable. Something like...
inputStyle: 'contenteditable', spellcheck: enableSpellcheck,
in ext.CodeMirror.js. Let's try that before we mess with ve.ui.CodeMirrorAction.js.
Feb 8 2018
@daniel: That's a great question. I'm hoping maybe the Collab team could squeeze it into Q1 if nobody can work on it sooner.
@MGChecker: Good point. We should support any types of links that are supported by the limited edit summary parsing, i.e. piped links, but not templates. Otherwise the behavior will seem inconsistent and confusing.
@daniel: It seems that this task is basically blocked by T49415 (other than some kind of partial roll-out). Eventually, lots of things are going to be blocked by T49415. I think having an IRC meeting about T49415 would be more useful.
Feb 7 2018
@TBolliger: Apparently the plan for the future is to limit edit summaries to a maximum of 1000 Unicode characters.
I made it a subtask since it is designed to mitigate the effects of T179259, but doesn't entirely solve the issue.
I wonder if this was caused by the fix for T175223.
Feb 6 2018
@TBolliger, @Samwilson : I imagine we'll need to put a big switch statement in the notification formatter class and have a customized message for most of the log types if we aren't linking to anything. Otherwise, people are likely to get confused. We could have a generic fall-back though, as Sam suggests. This means we'll probably want to make the log types that are supported opt-in rather than opt-out (as proposed by Sam above). Making them opt-out seems dangerous anyway. I doubt people who create new log types (like the upcoming page creation log) are going to remember to remove their logs from the Thanks feature if it doesn't make sense for them.
Yeah, I don't think we need to do anything special for now. Like you said, the LogEventsListLineEnding hook should have everything we need for adding Thanks on Special:Log, which is all we're doing for version 1. Declining for now. We may want to re-open when/if the scope expands.
@TBolliger: Just to clarify, this initial proof-of concept task doesn't include actually inserting Wikitext into the editor, correct? I think it would be better to implement that part in a separate task as it involves handling different template format options, which is a bit tricky.
As a side note, I have to admit I kinda like my idea of adding a "start a discussion about this" button/link in history that opens up a new topic in the talk page with a link to the relevant diff -- but that seems to be a different product altogether. Maybe I should suggest it in the next wishlist ;)