[MediaWiki-CodeReview] [MediaWiki r89393]: New comment added
User Tim Starling posted a comment on MediaWiki.r89393. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89393#c17911 Commit summary: Apply a patch adapted from the one on Bug #16794 This patch should allow you to use the $wgSharedDB [with Postgres] normally, as you would with mysql. Basically this patch creates a second connection with the shared database and when a query is made, we check on which connection we should send it. Patch from Luca Fulchir Comment: Yeah, tableName() doesn't respect $quoted anymore, so tableExists() tries to look in pg_class for a quoted identifier, and of course finds nothing. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89393]: Revision status changed
User Tim Starling changed the status of MediaWiki.r89393. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89393#c0 Commit summary: Apply a patch adapted from the one on Bug #16794 This patch should allow you to use the $wgSharedDB [with Postgres] normally, as you would with mysql. Basically this patch creates a second connection with the shared database and when a query is made, we check on which connection we should send it. Patch from Luca Fulchir ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89816]: Revision status changed
User MaxSem changed the status of MediaWiki.r89816. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89816#c0 Commit summary: Reverted r89393. A single Database object certainly should not be attempting to manage multiple database connections, that is the job of LBFactory/LoadBalancer. I would like to see $wgSharedDB managed by LBFactory instead, for all DBMSes. Then the cruft in Database::tableName() can be removed. r89393 caused tableExists() etc. to be completely broken, so PostgreSQL upgrade was broken too, see CR. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88929]: Revision status changed
User MaxSem changed the status of MediaWiki.r88929. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88929#c0 Commit summary: Commiting here, because other problems exist on trunk. This needs to be forward-ported to trunk. * Make Pg installation work for lesser privileged role in Postgres (i.e. not super user, but can create users and databases) for Bug #28845. * Switch to Pg's new “role” tables to replace the old “user” nes * Give DatabaseInstaller::openConnection() the ability to select a db since there isn't any working selectDB method for Pg yet. * If the installing role is the same as the one that the wiki will use, make sure it can see the tables in the MW schema * Remove addition of user_hidden field to the mwtable in Pg installation since it isn't referred to anywhere and breaks the installation. * Remove the word “below” from the config-connection-error message since sometimes the message is displayed where there is no login information shown at the same time. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89529]: New comment added, and revision status changed
User Tim Starling changed the status of MediaWiki.r89529.
Old Status: ok
New Status: fixme
User Tim Starling also posted a comment on MediaWiki.r89529.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89529#c17912
Commit summary:
Follow-up r89254 and r89481: re-did loading extension updates properly, now
upgrading extension tables from web interface really works, and without notices
Comment:
Not quite without notices:
bNotice/b: Undefined index: LoadExtensionSchemaUpdates in
b.../includes/installer/DatabaseUpdater.php/b on line b101/b
pre
+ if ( !isset( $vars['wgHooks'] ) !isset(
$vars['wgHooks']['LoadExtensionSchemaUpdates'] ) ) {
/pre
I suppose that was meant to be || not
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89529]: Revision status changed
User Tim Starling changed the status of MediaWiki.r89529. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89529#c0 Commit summary: Follow-up r89254 and r89481: re-did loading extension updates properly, now upgrading extension tables from web interface really works, and without notices ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89808]: New comment added
User Peachey88 posted a comment on MediaWiki.r89808. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89808#c17913 Commit summary: Initial check in, in an extension for now during development/evaluation/cross-browser testing. Comment: . ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
Google is not aware of this either. It works for certain queries like wikipedia (probably because many people misspell it in Cyrillic for fun), but try a more general query (e.g. университз оф оџфорд), and it won't return any results. r. On 10/06/11 06:46, Amir E. Aharoni wrote: There's a problem which is familiar to people who use non-Latin alphabets in computers is that they sometimes forget to switch the keyboard layout and type a whole word or even a sentence of gibberish until they notice it. For example, people who use a Cyrillic keyboard may search Google for цшлшзувшф, when they actually meant to search for wikipedia, and vice versa - dbrbgtlbz when they meant википедия (that's wikipedia in Russian). The Google search engine is aware of it for a few years now and often automatically searches for the desired term in a DWIM manner. Wikipedia's own search engine is not aware of it yet. A user in the Hebrew Wikipedia had this idea: Maybe LanguageConverter can be used for it? Common keyboard layouts can be mapped to each other, like the two Serbian alphabet are mapped to each other today, and Special:Search is already aware of LanguageConverter. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
On Fri, Jun 10, 2011 at 2:16 PM, Robert Stojnic rainma...@gmail.com wrote: Google is not aware of this either. It works for certain queries like wikipedia (probably because many people misspell it in Cyrillic for fun), but try a more general query (e.g. университз оф оџфорд), and it won't return any results. He was referring to search terms typed in a wrong keyboard layout, not transliteration, i.e. гтшмукышешуы ща щчащкв instead of what you wrote for universities of oxford. Google doesn't really handle this query either, by the way. But yes - I personally felt the need in such a feature and was thinking of doing it myself. Ideally, this should be made a backend-independent extension that hooks into Special:Search directly. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
My query wasn't a transliteration, but typed with a Serbian Cyrillic layout. r. On 10/06/11 11:58, Max Semenik wrote: He was referring to search terms typed in a wrong keyboard layout, not transliteration, i.e. гтшмукышешуы ща щчащкв instead of what you wrote for universities of oxford. Google doesn't really handle this query either, by the way. But yes - I personally felt the need in such a feature and was thinking of doing it myself. Ideally, this should be made a backend-independent extension that hooks into Special:Search directly. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
On Fri, Jun 10, 2011 at 3:07 PM, Robert Stojnic rainma...@gmail.com wrote: My query wasn't a transliteration, but typed with a Serbian Cyrillic layout. So it's phonetically equivalent to QWERTY? Neat. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89820]: Revision status changed
User Jack Phoenix changed the status of MediaWiki.r89820. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89820#c0 Commit summary: Fixed typo in comment. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89821]: New comment added
User Tim Starling posted a comment on MediaWiki.r89821. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89821#c17914 Commit summary: PostgreSQL install fixes: * Made PG throw a DBQueryError when it gets a query error, instead of DBUnexpectedError. Apparently this mistake goes back to r14625, when exceptions were first introduced. Did it by removing reportQueryError(), the DatabaseBase version works fine. * Fixed several places where there was an attempt to check for a query error by checking if the result of query() was false. This never worked. Used try/catch instead. * Made the DBConnectionError messages go on one line so that they don't mess up the formatting in the installer. * In DatabasePostgres::selectDB(), only disconnect and reconnect if the DB name is actually changing. * Made DatabasePostgres::schemaExists() less weird and scary. * Added DatabasePostgres::roleExists() for use by the installer. * Removed the PostgreSQL-specific hack to make _InstallUser have a default other than root. Made _InstallUser into a proper DBMS-specific internal variable instead, since every DBMS we support so far needs a different default. * Removed the $dbName parameters from openConnection/getConnection, and got rid of $this-useAdmin. Implemented a more sophisticated caching scheme instead. Partial revert of r89389 and r81440. * When connecting as the install user before DB creation, and when testing the web user's credentials, try a few different database names and use whichever one works. * Instead of connecting as the web user to create tables, I used SET ROLE. It seems cleaner and more like what the other DBMSes do during installation. SET ROLE wikiuser requires the same privileges as CREATE SCHEMA ... AUTHORIZATION wikiuser, so it's unlikely to break anything. * In the area of web account creation, fixed various minor logic errors and introduced more informative error messages at the submit stage, pre-install. Show a helpful error message if the web user exists already and the install user can't do the relevant SET ROLE. * Split schema creation out to a separate install step. * When creating an account as a non-superuser, add the administrative account to the new account's group. This is necessary to avoid a fatal error during installation (bug 28845). * Removed code which alters an existing web user to have appropriate search paths and permissions. This may break other apps and is not necessary. As in other DBMSes, If the web user exists, it is the responsibility of the sysadmin to ensure that it has appropriate permissions. * Rewrote setupPLpgSQL() to use the query builder functions. Comment: If you revert r89807 in 1.17 then the changes here to PostgresInstaller.php merge cleanly. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89817]: Revision status changed
User MaxSem changed the status of MediaWiki.r89817. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89817#c0 Commit summary: Fix for logic error in r89529 causing a notice. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
On Fri, Jun 10, 2011 at 6:16 AM, Robert Stojnic rainma...@gmail.com wrote: Google is not aware of this either. It works for certain queries like wikipedia (probably because many people misspell it in Cyrillic for fun), but try a more general query (e.g. университз оф оџфорд), and it won't return any results. It seems to work consistently if you type English using a Hebrew layout, even for rather uncommon search terms: http://www.google.com/search?q=%D7%A8%D7%9D%D7%A0%D7%A7%D7%A8%D7%90+%D7%93%D7%90%D7%9D%D7%97%D7%9E%D7%9F%D7%91 And the reverse: http://www.google.com/search?q=tnhr+tvrubh Maybe it just doesn't know about Serbian Cyrillic keyboard layouts, but does know about Hebrew keyboard layouts. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LanguageConverter and searching with the incorrect keyboard layout
OK, but if i understand correctly, LanguageConverter is already integrated with the search engine. 2011/6/10 Philip Tzou philip@gmail.com: strtr() is sufficient.** Current LC is based on it. 2011/6/10 Amir E. Aharoni amir.ahar...@mail.huji.ac.il There's a problem which is familiar to people who use non-Latin alphabets in computers is that they sometimes forget to switch the keyboard layout and type a whole word or even a sentence of gibberish until they notice it. For example, people who use a Cyrillic keyboard may search Google for цшлшзувшф, when they actually meant to search for wikipedia, and vice versa - dbrbgtlbz when they meant википедия (that's wikipedia in Russian). The Google search engine is aware of it for a few years now and often automatically searches for the desired term in a DWIM manner. Wikipedia's own search engine is not aware of it yet. A user in the Hebrew Wikipedia had this idea: Maybe LanguageConverter can be used for it? Common keyboard layouts can be mapped to each other, like the two Serbian alphabet are mapped to each other today, and Special:Search is already aware of LanguageConverter. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89808]: New comment added
User Krinkle posted a comment on MediaWiki.r89808. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89808#c17915 Commit summary: Initial check in, in an extension for now during development/evaluation/cross-browser testing. Comment: I could've branched the entire trunk for a few small fixes, but since is a background proccess that may take longer, I rather stay as close to trunk as possible, so I forked the one file I needed to modify and work on that (this also makes it a lot easier for people to check it out (in both meanings of to check out). When this is done (that is, all components of the [[Style guide]]] that replace browser or jquery defaults (input field, labels, forms, modal boxes, selection etc.), then it will most likely be moved back into core. However it has to be done at once. Quote part of the commit: pre +// @todo Integrate HTMLStyleForm into core HTMLForm /pre ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87975]: New comment added, and revision status changed
User Krinkle changed the status of MediaWiki.r87975.
Old Status: new
New Status: ok
User Krinkle also posted a comment on MediaWiki.r87975.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87975#c17916
Commit summary:
Fix width of live log in installer, so that it floats correctly to the right
Comment:
code#config-live-log/code isn't floated. How does this fix anything ? From
what I can see it moves the issue.
The problem is that the sidebar (code#config-page-list/code) has a width of
12em (18em including the padding margin) and the page content itself has a
fluid width, so no matter what percentage it is set to it will always misalign
with the rest of the paragraphs, and there will always be a case where it jumps
below the sidebar if it's too wide.
compare:
* code#config-live-log { width: 75%/code: narrow window
(http://toolserver.org/~krinkle/tmp/87975-narrow-75.png)
* code#config-live-log { width: 70%/code: narrow window
(http://toolserver.org/~krinkle/tmp/87975-wide-70.png)
* code#config-live-log { width: 75%/code: wide window
(http://toolserver.org/~krinkle/tmp/87975-narrow-75.png)
* code#config-live-log { width: 70%/code: wide window
(http://toolserver.org/~krinkle/tmp/87975-wide-70.png)
I think neither is better or worse, they're all misaligned. The results may
vary from browser to browser, though. But sadly it's implossible for a
{[tag|textarea|open}} to get the same width as the paragraphs or the infobox
(next to the sidebar). Reason being that those can have an codeautocode
width and/or codeoverflow:hidden/code to get the proper size, where a
textarea can't.
It's not hopeless though, it can be fixed by removing the width all together
(letting it fallback to width:100%) and wrap the {{tag|textarea|open}} in a
{{tag|div|open}} that can be adapted to the context. Done in r89835.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87975]: New comment added
User Krinkle posted a comment on MediaWiki.r87975. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87975#c17917 Commit summary: Fix width of live log in installer, so that it floats correctly to the right Comment: /code/code ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r46019]: New comment added
User Platonides posted a comment on MediaWiki.r46019. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/46019#c17918 Commit summary: Added information about myself. Comment: ''svn.madi'''a'''wiki.org'' ? Is that typed correctly? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87543]: Revision status changed
User Krinkle changed the status of MediaWiki.r87543. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87543#c0 Commit summary: Fix 2 more 1.18's from RELEASE-NOTES in r87542 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r78996]: New comment added
User Bawolff posted a comment on MediaWiki.r78996. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/78996#c17919 Commit summary: Rm useless checks which breaks if descriptionmsg is an array Comment: I'm adding the tag 1.17 to this since according to bug 29334 this fixes a regression in 1.17 with special:version breaking when descriptionmsg is an array. (I have no idea what the status of 1.17 is, and if its too late for a fix to such a minor issue). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89839]: New comment added
User Tim Starling posted a comment on MediaWiki.r89839. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89839#c17920 Commit summary: Make Pg installer work in the “common” case: follow up r89821 so that $exists can be set true if same user is the same for install and web. Comment: What's the point of testing the connection again or calling $this-canCreateObjectsForWebUser() when it's the same user? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88873]: New comment added, and revision status changed
User Bawolff changed the status of MediaWiki.r88873. Old Status: new New Status: fixme User Bawolff also posted a comment on MediaWiki.r88873. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88873#c17921 Commit summary: * (bug 29144) Move action=dublincore and action=creativecommons to extensions Moved CreativeCommonsRDF out to extension Comment: There's still references to this feature in the installer. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Testing the new php mobile extension
Greetings all. We're moving into our first testing stage for the new mobile extension and we'd love your help. You can find all the details on todays blog post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/ Come help test, develop, or just ask about our mobile efforts on irc freednode #wikimedia-mobile. For those new to the mobile projects check out http://meta.wikimedia.org/wiki/Mobile_Projects for background. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing the new php mobile extension
Tomasz Finc wrote: We're moving into our first testing stage for the new mobile extension and we'd love your help. You can find all the details on todays blog post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/ Forgive me, but I don't understand the purpose of a prototype wiki that's not really a prototype: there are no images or templates. The home page (http://nomad.tesla.usability.wikimedia.org/index.php/Main_Page) seems to indicate that this is expected, but unless the goal is to have users test how well red links render on their phone, I'm not sure what testing can be done currently. Are the images and templates going to be imported? Looking at http://nomad.tesla.usability.wikimedia.org/index.php/Trump_criticizes_media _bias_towards_Obama,_especially_during_UK_state_visit, it's insanely slow to load, mostly as the images aren't being thumbnailed. From the HTML source: img alt= src=http://upload.wikimedia.org/wikipedia/commons/f/fd/Barack_Obama_Michell e_Obama_Queen_Elizabeth_II_Buckingham_Palace_London.jpg width=180 height=120 class=thumbimage / That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. Come help test, develop, or just ask about our mobile efforts on irc freednode #wikimedia-mobile. I don't think yet another IRC channel is a good idea. Surely this could go in #wikimedia-dev or #mediawiki. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r78996]: New comment added
User Tim Starling posted a comment on MediaWiki.r78996. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/78996#c17922 Commit summary: Rm useless checks which breaks if descriptionmsg is an array Comment: Is there some user-visible consequence of this? Was it a regression? Is there some extension that hits it? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r78996]: New comment added
User Bawolff posted a comment on MediaWiki.r78996. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/78996#c17923 Commit summary: Rm useless checks which breaks if descriptionmsg is an array Comment: A quick grep suggests that [[extension:Lingo]] is the only one in Wikimedia's repository that would currently, but semantic maps did until quite recently (r83905). Presumably the reporter of bug 29334 has an extension that hits it in order to report the bug. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Testing the new php mobile extension
On Fri, Jun 10, 2011 at 3:39 PM, MZMcBride z...@mzmcbride.com wrote: Tomasz Finc wrote: We're moving into our first testing stage for the new mobile extension and we'd love your help. You can find all the details on todays blog post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/ Forgive me, but I don't understand the purpose of a prototype wiki that's not really a prototype: there are no images or templates. The home page (http://nomad.tesla.usability.wikimedia.org/index.php/Main_Page) seems to indicate that this is expected, but unless the goal is to have users test how well red links render on their phone, I'm not sure what testing can be done currently. Are the images and templates going to be imported? There's way more than red links there: there's paragraph on paragraph of text, with templates, images, category links, interlanguage links, references, etc. Some bits are indeed missing and ought to be cleaned up for further testing though -- and your feedback about that is valuable to the people setting up the tests. Just don't confuse giving feedback with blasting people into oblivion for not being perfect on the first round. [snip] That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. Awesome -- you found a bug! Apparently the system does work. :) We also have this nice bug that was reported on the RTL test, again confirming that this testing is helping to identify bugs: https://bugzilla.wikimedia.org/show_bug.cgi?id=29341 Come help test, develop, or just ask about our mobile efforts on irc freednode #wikimedia-mobile. I don't think yet another IRC channel is a good idea. Surely this could go in #wikimedia-dev or #mediawiki. That's a pre-existing channel that's been in use for a couple years. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing the new php mobile extension
On Sat, Jun 11, 2011 at 8:39 AM, MZMcBride z...@mzmcbride.com wrote: That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. MZMcBride Either the server doesn't have or the wiki wasn't setup to use the image scaling backends (GD/Imagikmagic) so it defaults to that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89831]: Revision status changed
User Krinkle changed the status of MediaWiki.r89831. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89831#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-06-10 16:30:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79867]: Revision status changed
User Krinkle changed the status of MediaWiki.r79867. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79867#c0 Commit summary: Follow-up r79845: Add rotation support to the upload preview using the canvas element. The actual rotation angle still needs to be extracted from the file using a library such as jsjpegmeta http://benno.id.au/jpegmetaexample/jpegmeta.js ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81208]: New comment added
User Krinkle posted a comment on MediaWiki.r81208. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81208#c17924 Commit summary: Follow-up r80775: Check for meta.tiff as well. Bump wgStyleVersion Comment: code$wgStyleVersion/code doesn't have to be increased by this. anything in tt/resources/tt is loaded through ResourceLoader which uses it's own timestamps and caching. wgStyleVersion is deprecated and/or unused. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r80775]: Revision status changed
User Krinkle changed the status of MediaWiki.r80775. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80775#c0 Commit summary: Follow-up r79867: Read out EXIF orientation in JavaScript and rotate accordingly. Added JsJpegMeta library by Ben Leslie under the MIT license. * Added JS variabele wgFileCanRotate. If anybody knows a way to make certain variables only available to certain modules, please tell me, could not find it. * Added JsJpegMeta as mediawiki.util.jpegmeta * Made BitmapHandler::getScaler and BitmapHandker::canRotate static * Bumped style version ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86206]: Revision status changed
User Krinkle changed the status of MediaWiki.r86206. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86206#c0 Commit summary: Move timezone preference functions to mediawiki.special.preferences.js remove their wikibits dependencies ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89853]: New comment added
User Krinkle posted a comment on MediaWiki.r89853. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89853#c17925 Commit summary: Added jquery.qunit.completenessTest.js (A jQuery/QUnit test coverage utility) * Added to /resources * Conditionally loaded (condition being that the url parameter completenesstest has a truthy value) * Fixed a test that was using === and true * Setting an added method somewhere back to undefined so it won't be listed as a potential missing test. Comment: jQuery was updated, was intended for r89866 (1 minute after). Sorry for the mixup. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Testing the new php mobile extension
Brion Vibber wrote: On Fri, Jun 10, 2011 at 3:39 PM, MZMcBride z...@mzmcbride.com wrote: Tomasz Finc wrote: We're moving into our first testing stage for the new mobile extension and we'd love your help. You can find all the details on todays blog post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/ Forgive me, but I don't understand the purpose of a prototype wiki that's not really a prototype: there are no images or templates. The home page (http://nomad.tesla.usability.wikimedia.org/index.php/Main_Page) seems to indicate that this is expected, but unless the goal is to have users test how well red links render on their phone, I'm not sure what testing can be done currently. Are the images and templates going to be imported? There's way more than red links there: there's paragraph on paragraph of text, with templates, images, category links, interlanguage links, references, etc. Some bits are indeed missing and ought to be cleaned up for further testing though -- and your feedback about that is valuable to the people setting up the tests. Just don't confuse giving feedback with blasting people into oblivion for not being perfect on the first round. I was asking if was a Friday at five issue or if it was intended. The Main Page seems to indicate that it's intended behavior, which doesn't make any sense. If you're calling on end users to participate in testing (through the Wikimedia blog), yes, the prototypes should be in reasonably working order first. Otherwise, put off the announcement until they are. I'm not trying to blast anyone anywhere, I just don't understand why you'd announce to the world that testing is ready when it isn't. I looked a bit closer at the prototype and can't really figure out which templates were and weren't imported. It also seems that importing doesn't update certain tables (e.g., Special:ListFiles is empty), which sucks. You must limit variables when testing, otherwise you'll end up with half the feedback being the page didn't render properly when it was simply a lot of known missing content. [snip] That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. Awesome -- you found a bug! Apparently the system does work. :) Well, no, the system doesn't work. That would be the bug. Most users are going to report site slow as shit or simply get frustrated and leave because they're downloading megabytes of images unknowingly. I think it's great to solicit user feedback on the mobile project, but I think if it's a muddled mess, the signal (actual problems in the extension) is going to be drowned out by the noise (endless reports of brokenness in the prototypes). Come help test, develop, or just ask about our mobile efforts on irc freednode #wikimedia-mobile. I don't think yet another IRC channel is a good idea. Surely this could go in #wikimedia-dev or #mediawiki. That's a pre-existing channel that's been in use for a couple years. Pre-existing in the sense that people have joined it before, I guess. It's not registered and I don't see why it's needed, particularly when #wikimedia-dev was supposed to encompass these types of Wikimedia-led projects. But okay. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89839]: New comment added
User MarkAHershberger posted a comment on MediaWiki.r89839. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89839#c17926 Commit summary: Make Pg installer work in the “common” case: follow up r89821 so that $exists can be set true if same user is the same for install and web. Comment: I didn't think to check that user is already tested at this point. Your fix in r89855 is better. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Testing the new php mobile extension
On Fri, Jun 10, 2011 at 7:18 PM, K. Peachey p858sn...@gmail.com wrote: On Sat, Jun 11, 2011 at 8:39 AM, MZMcBride z...@mzmcbride.com wrote: That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. MZMcBride Either the server doesn't have or the wiki wasn't setup to use the image scaling backends (GD/Imagikmagic) so it defaults to that. All the previous VMs on tesla have had GD/IM, and I believe point at commons as a ForeignApiRepo so we don't get a bazillion redlinked images. I imagine the same can be done here :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extensions template (Extensions infobox); add shortcut markers (where applicable); MediaWiki Virtual Library : 3rd book Interwiki and Interlanguage Guide
1. I modified http://www.mediawiki.org/wiki/Template:Extension
which renders the Infobox to include three instead of two links:
list open bugs - list all bugs - report a bug
This makes it easier to file a bug and avoids mistakes, as report a
bug now directly brings users to the correct bug component
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=Extensionname
If this has not been set up, Extension maintainers with their extensions
in SVN can simply add
bugzilla=componentline
e.g. add
bugzilla=LiquidThreads
to the template call on their extension page.
2. Started to make extensive use of {{shortcut | shortcutname }} on
Extension pages,
and would like to encourage you to help adding such markers for
important extensions or extensions you maintain, too.
Will find a way to make that case-insensitive. Currently, shortcutnames
are uppercase. Personally, I would prefer to have the shortcuts working
case-insensitively, and also printed the shortcutnames in lower-case,
but this is more a style and guideline question.
3. Published a third book in http://www.mediawiki.org/wiki/MVL :
MediaWiki Interwiki and Interlanguage Guide
http://en.wikipedia.org/wiki/User:Wikinaut/Books/MediaWiki_Interwiki_and_Interlanguage_Guide
( MVL = MediaWiki Virtual Library )
As I like the books very much, perhaps you can help to publish about
that MVL in other places. I will contact the SignPost Editor to write
something about the MVL.
Tom
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions template (Extensions infobox); add shortcut markers (where applicable); MediaWiki Virtual Library : 3rd book Interwiki and Interlanguage Guide
On Sat, Jun 11, 2011 at 1:23 PM, Thomas Gries m...@tgries.de wrote:
2. Started to make extensive use of {{shortcut | shortcutname }} on
Extension pages,
and would like to encourage you to help adding such markers for
important extensions or extensions you maintain, too.
Will find a way to make that case-insensitive. Currently, shortcutnames
are uppercase. Personally, I would prefer to have the shortcuts working
case-insensitively, and also printed the shortcutnames in lower-case,
but this is more a style and guideline question.
Eww no, shortcuts should be avoided where possible, they are basically
pointless for us and they don't serve any decent purpose apart from
removing extension: from the url which is not something we should be
doing (depending on what shortcuts people make), we should be
encouraging people to use the proper urls because they are more likely
to be permanent.
Also they are confusing to some newer people where the url != the page
title which is out standard convention with mediawiki.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions template (Extensions infobox); add shortcut markers (where applicable); MediaWiki Virtual Library : 3rd book Interwiki and Interlanguage Guide
On Fri, Jun 10, 2011 at 11:45 PM, K. Peachey p858sn...@gmail.com wrote:
On Sat, Jun 11, 2011 at 1:23 PM, Thomas Gries m...@tgries.de wrote:
2. Started to make extensive use of {{shortcut | shortcutname }} on
Extension pages,
and would like to encourage you to help adding such markers for
important extensions or extensions you maintain, too.
Will find a way to make that case-insensitive. Currently, shortcutnames
are uppercase. Personally, I would prefer to have the shortcuts working
case-insensitively, and also printed the shortcutnames in lower-case,
but this is more a style and guideline question.
Eww no, shortcuts should be avoided where possible, they are basically
pointless for us and they don't serve any decent purpose apart from
removing extension: from the url which is not something we should be
doing (depending on what shortcuts people make), we should be
encouraging people to use the proper urls because they are more likely
to be permanent.
Also they are confusing to some newer people where the url != the page
title which is out standard convention with mediawiki.
+1. A very very strong +1.
Really, I don't see the need for all these Wikipedia-esque templates.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions template (Extensions infobox); add shortcut markers (where applicable); MediaWiki Virtual Library : 3rd book Interwiki and Interlanguage Guide
Am 11.06.2011 05:45, schrieb K. Peachey: Eww no, shortcuts should be avoided where possible, they are basically pointless for us and they don't serve any decent purpose apart from removing extension: from the url which is not something we should be doing (depending on what shortcuts people make), we should be encouraging people to use the proper urls because they are more likely to be permanent. Also they are confusing to some newer people where the url != the page title which is out standard convention with mediawiki. This is your single view. My view is that a better management of shortcuts (shortcut repository) would help users and reserving abbreviations and namescertainlength for shortcuts would not be too difficult. With this statement I wish to close the discussion, as you came with so strong arguments, that I feel, I have no chance to convince you of the opposite. So, I respect your view, but have a dissenting opinion- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing the new php mobile extension
On Fri, Jun 10, 2011 at 6:08 PM, MZMcBride z...@mzmcbride.com wrote: Brion Vibber wrote: On Fri, Jun 10, 2011 at 3:39 PM, MZMcBride z...@mzmcbride.com wrote: Tomasz Finc wrote: We're moving into our first testing stage for the new mobile extension and we'd love your help. You can find all the details on todays blog post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/ Forgive me, but I don't understand the purpose of a prototype wiki that's not really a prototype: there are no images or templates. The home page (http://nomad.tesla.usability.wikimedia.org/index.php/Main_Page) seems to indicate that this is expected, but unless the goal is to have users test how well red links render on their phone, I'm not sure what testing can be done currently. Are the images and templates going to be imported? Plenty actually. Were already getting bug reports and feedback on the suggestions page so clearly people are able to use it. Importing more pages can easily be done. We imported all MediaWiki namespace messages and everything two levels deep from the MainPage of each Wiki mentioned. Since the prototype servers don't have as much space as the main cluster we have to balance the amount of content with the resources available. There's way more than red links there: there's paragraph on paragraph of text, with templates, images, category links, interlanguage links, references, etc. Some bits are indeed missing and ought to be cleaned up for further testing though -- and your feedback about that is valuable to the people setting up the tests. Just don't confuse giving feedback with blasting people into oblivion for not being perfect on the first round. I was asking if was a Friday at five issue or if it was intended. The Main Page seems to indicate that it's intended behavior, which doesn't make any sense. If you're calling on end users to participate in testing (through the Wikimedia blog), yes, the prototypes should be in reasonably working order first. Otherwise, put off the announcement until they are. I'm not trying to blast anyone anywhere, I just don't understand why you'd announce to the world that testing is ready when it isn't. As mentioned before, people have been happily testing and we can easily load in more content. No harm there. I looked a bit closer at the prototype and can't really figure out which templates were and weren't imported. It also seems that importing doesn't update certain tables (e.g., Special:ListFiles is empty), which sucks. You must limit variables when testing, otherwise you'll end up with half the feedback being the page didn't render properly when it was simply a lot of known missing content. [snip] That's client-side resizing, which is painful enough on a full web browser, much less a mobile device. The wikicode specifies |thumb|, which should resize the image server-side, surely. I'm not sure what's going on there. Awesome -- you found a bug! Apparently the system does work. :) Well, no, the system doesn't work. That would be the bug. Most users are going to report site slow as shit or simply get frustrated and leave because they're downloading megabytes of images unknowingly. I think it's great to solicit user feedback on the mobile project, but I think if it's a muddled mess, the signal (actual problems in the extension) is going to be drowned out by the noise (endless reports of brokenness in the prototypes). Actually people have been filing rtl, line spacing, and other issues instead of any speed issues. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89866]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89866. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89866#c17927 Commit summary: Upgrade jQuery from 1.4.4 to 1.6.1 Poke r88725, r88607, bug 28904; Comment: That was easy! Looks like you accidentally updated it in the last commit. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
