Re: [Wikitech-l] Proposal: reversion collapsing in edit history
Roan Kattouw gmail.com> writes: > The only common factor between collapsing reversions and hiding minor > and/or bot edits is the fact that you're hiding things from the > history view. Yes, it is the UI which could be reused. > the other requires the minor/bot flags to be added to that table. Just checking for bot user group would be, while not ideal, still acceptable. Or is the table join required for that too costly? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: reversion collapsing in edit history
Rob Lanphier wikimedia.org> writes: > One general improvement we could make the history is to optionally > collapse long stretches of reversions. It would be nice if the system would be generic enough to be used for hiding minor bot edits (not necessarily reversions), which is a longstanding problem on all projects: automated edits with little or real content (disambiguations, interwiki maintenance, template parameter changes etc.) clutter up the page histories, often to the point where real edits take as little as 20-25% of the history, making it nearly unusable. (See also bug 11181 and 16228.) https://bugzilla.wikimedia.org/show_bug.cgi?id=11181 https://bugzilla.wikimedia.org/show_bug.cgi?id=16228 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
Roan Kattouw gmail.com> writes: > Actually, the line number would not mean a great deal because the > scripts would still be combined, comments frequently take up entire > lines and the deminifier cannot account for blank lines, statements > broken over multiple lines, or multiple statements on one line. All > this means it's impossible to map the line number to a source line and > file, although I agree it does map it to a statement: someone else can > add a breakpoint at the same line of the same combined+minified output > (provided they're also hitting the same load.php URL) and have that > break at the exact statement the reporter got their error on. It shouldn't be too hard to have the minification script create a line number translation table; just delay stripping newlines until the end, and create an index of newline positions in the original and minified versions of the code. (You would need error offsets for that to be useful, though; I don't know which browsers provide that.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to generate link to section in JavaScript?
lampak gmail.com> writes:
> I have tried encodeURIComponent before. Bażant królewski becomes
> Bażant_królewski. Diacritics are not converted. At least not under Firefox.
I don't know what you've tried, but the result of
encodeURIComponent('Bażant królewski')
is
"Ba%C5%BCant%20kr%C3%B3lewski"
in Firefox, and I'm pretty sure it works the same way on other browsers.
(encodeURI is almost the same, but leaves more characters unencoded, which in
this case is a bad thing.)
Then you need to replace %20 with _, % with ., unencoded characters ~!*()' with
their proper utf-8 sequence, and you have the section title fragment.
(It might be a good idea to include a function doing that in wikibits.js, if
there isn't one yet.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to generate link to section in JavaScript?
lampak gmail.com> writes: > Hi. I'm working on a script which edits a page, adds a section to it and > then redirects to this page. > > It would be nice if it went straight to the newly-created section. So I > need to create a link with # in it. > > The problem appears when the title of the section contains some > diacritics. For example, link to "bażant królewski" looks like > "Ba.C5.BCant_kr.C3.B3lewski". > > How can I generate in JavaScript such a link which would be identical to > the one generated by MediaWiki? Has somebody written such a function? Or > at least, do you know where it is done in MediaWiki php code? It is pretty simple as long as there is no wikitext or html in the title: convert it to urlencoded UTF-8 (encodeURIComponent does that), replace percent signs with dots, replace spaces with underscores. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Increasing default cookie expiry time
MZMcBride mzmcbride.com> writes: > What's the reason for having the cookie expire at all (or expire in any > reasonable timeframe)? I'm not sure I see what security benefits any expiry > provides (much less a 30-day one) given the rampant use of password stores > in browsers. Setting the cookie expiry to practically infinite would also solve bug 24892 [1]. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=24892 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New password hashing proposal
Aryeh Gregor gmail.com> writes: > I don't think so. I think it's completely reasonable, when talking > about Wikipedia. Hackers go after money, and there's no money in > hacking Wikipedia. We have nothing secret or valuable that's not > already readily available. We have no black-market competitors who > want to try disrupting our service. Any malicious action could be > easily reversed. The worst we have to worry about is someone with a > grudge trying to frame someone else, which has happened, but it's > hardly a pressing concern. That is true for regular accounts, but with administrator access you can run malicious javascript on a large number of machines or track the visitors of a certain article. A totalitarian government going after checkuser access is not an unimaginable scenario either. That said, the two things that would make the most difference (and are also much easier to implement) are SSL and password strength requirements. There is no point in fancy stuff like SMS or asymmetric cyphers which would be much more disruptive, a lot harder to introduce, and would have less effect. > When few enough people want a preference that more people > are likely to turn it on by mistake than deliberately, and when > there's significant harm or confusion from turning it on by mistake, > that's a sign that it's a bad preference. (See also: "Use external > editor".) Not to disagree with your general point, but that specific problem would be easy to handle by throwing a dialog with big red exclamation marks saying "WARNING! Arey you REALLY sure you know what you are doing?" when one is about to turn on such a feature. (Or only showing the controls when the user selects "expert mode".) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki] Enhancement: LaTeX image s quality (eliminate white background)
Aryeh Gregor gmail.com> writes: > As far as I know, the only thing actually blocking us from doing this > was something like IE5 on Mac printing transparent images with black > backgrounds. That's probably not relevant anymore. We're still stuck > with the fact that IE6 doesn't support alpha channels, though -- we > could make the fully-transparent parts of the background transparent, > but I don't see how we could avoid aliasing effects on sane browsers > without making things look extremely ugly on IE6. You could use PNG8 with a color palette where every color is black, with a variable level of transparency. That would be equivalent to full PNG32 alpha transparency in modern browsers (as long as the only color used in the formulas is black), while IE5.5/6 would have binary transparency without any aliasing - ugly but probably not horrible. (See http://www.v-methods.com/ji/palette_alpha.html for a demonstration.) Or you could just send different images to IE6, for example by using empty divs with background images instead of img tags, and changing the image URL for IE6 with the star-html CSS hack. (Not very accessible, but maybe the text of the formula could be written into the div with overflow:hidden?) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
