Re: [Wikitech-l] Selenium tests (was: New committers)
2010/3/10 Aryeh Gregor : > On Wed, Mar 10, 2010 at 8:20 AM, Roan Kattouw wrote: >> On the other hand, we intend on setting up a server that runs these >> tests automatically. Instead of having to pull these tests from a >> million different places, it'd be nice if this server could just >> update from one dir and be done with it, which is exactly why I set it >> up the way I did. > > The way parser tests work is you do $wgParserTestFiles[] = 'foo' in > the extension setup file. That seems like a much tidier and more > self-contained way of doing it. You'll need a full MediaWiki checkout > with the extensions enabled in LocalSettings.php to run the tests to > begin with, I assume. > Good point. Since we're trying to make these things mirror the parser tests (see other thread), it's a good idea to make the directory structure the same as well. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium tests
2010/3/10 Aryeh Gregor : > I'm a little surprised by this altogether, actually. I had seen some > mention of Selenium adoption, but nothing concrete. Was this > discussed publicly anywhere, or has this kind of project started to > migrate behind closed doors now that there are so many paid people? > I'm subscribed to all major MediaWiki development discussion fora, as > far as I know, but I've felt increasingly out of the loop lately. > Having more paid developers is great (and so is a good testing > framework!), but that shouldn't mean that decisions are made where > volunteers can't weigh in. > We're initially setting up Selenium for use by the usability initiative, with the idea of extending it to the rest of the software when we have time/resources for that. You're right that this should probably have been communicated earlier, but until a few weeks ago the status was "Ryan's patiently waiting for the Selenium servers to arrive and get set up". Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committer
2010/3/10 Ævar Arnfjörð Bjarmason : > Are new commiters being sent a link to [1] when they get their commit access? > > 1. http://www.mediawiki.org/wiki/Commit_access#Getting_started_and_set_up > Not by default, although most people requesting it will read that page before putting in their request. You're right that we should explicitly bring this page under new committers' attention. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium tests
2010/3/10 Platonides : > Shouldn't that server have the extensions checked out and installed on a > local mediawiki before running them ? > (I am assuming it's a single server testing against localhost) > The point is it's not a single server testing them against localhost: it's a virtual machine testing against a number other VMs, each running a different OS/browser. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committer
2010/3/10 Chad : > I see he already has his account linked on-wiki and committed a > USERINFO file. Can the recently added people for Calcey and LQT > (bhagya, janesh, ishimatsu) be notified of these two things as well? > Have no clue if they're on this list. > > Having an account with e-mail linked in CR is especially important. > I forwarded this e-mail to Bhagya and Janesh; I don't have ishimatsu's contact details. Andrew, do you? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium tests (was: New committers)
2010/3/10 Conrad Irwin : > This should work the same way as extension parser-tests, with the tests > in the extension's directory, included using a config variable. > Otherwise, extensions are split over two places, so there's not such an > easy way to just tarball them, and it's less clear from the SVN commit > paths that all work was just to the extension, it also provides more > flexibility if people want it. > On the other hand, we intend on setting up a server that runs these tests automatically. Instead of having to pull these tests from a million different places, it'd be nice if this server could just update from one dir and be done with it, which is exactly why I set it up the way I did. I agree that this is kind of the enemy of nice bundling of tests with extensions, but I think having an automatic test setup that tests stuff /before/ it's released is more important and more frequently used than providing easy access to tests to those .3% of downloaders that are actually gonna run them. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committers
2010/3/10 K. Peachey : > Perhaps "/testing/extensions//" since not all extensions will > ever have tests so it would make it easier and cleaner to sort the > directory. > Yes, I've actually already created /trunk/testing/UsabilityIntiative for usability tests, but that could easily be renamed to /trunk/testing/extensions/UsabilityInitiative of course. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New committers
bhagya - QA engineer for Calcey Technologies, will be committing Selenium tests to /trunk/testing/selenium janesh - same Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] modernizing mediawiki
2010/3/5 Chris Lewis : > I agree 100%, especially the part I bolded. Also god bless the developers and > extension writers for doing this out of their own free time, I guess I > misunderstood the process and thought wikimedia had a code team that was paid. > Some developers are paid employees/contractors, some are not. Obviously the paid developers do what WMF wants them to do (which generally means doing stuff that benefits WMF primarily, not 3rd party users per se) and volunteer developers do whatever the hell they want (and in Chad's case that means overhauling the installer specifically for 3rd party users, > Also I saw on a news site: > "The foundation has snared an $890,000 grant from the Stanton Foundation for > the project and plans to assemble a five-person team to identify what exactly > is turning some users off." > $890,000 for only a 5 man team? It would be great if this money went into > some of the common changes people need. > As you quoted, it's a grant, so it's money with strings attached: WMF either gets $890k that they have to spend on what Stanton wants them to do (the usability project), or they don't get the money at all. Also, while $890k sounds like a lot of money, software developers in the San Francisco Bay Area cost a lot of money (cost of living is high there, and there's plenty of big for-profit companies around trying to hire the same people), and there's more costs than just those 5 people's salaries. >>They were not back in 2005 =) > In case you haven't heard, it's 2010 lol. A lot has changed since then. > We have heard. It's just that no one has cared since 2005 apart from the aforementioned Stanton-funded usability team, which developed the Vector skin. Like I said before, if WMF can't or won't dedicate one of their few developers' time to something and no one in the volunteer community cares, it doesn't happen. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] External editor with merge capability?
2010/3/5 Jani Patokallio : > Right, this was also my understanding of how it worked internally, the > question is how to work around this? Eg. the API offers "basetimestamp" > and "starttimestamp" fields that can be sent along with the edit > submission, but is there any way to send these or otherwise specify the > last revision with a direct submit POST to MediaWiki? > You /can/ fake the values of wpStarttimestamp and wpBasetimestamp in the edit form submission, but using the API is recommended. For clarity: starttimestamp: Used to detect whether the page was deleted since you started editing. Should be the time at which you clicked the edit button basetimestamp: Used to detect edit conflicts. Should be *exactly equal* to the timestamp of the most recent revision of the page at the time you started editing Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] External editor with merge capability?
2010/3/4 Jani Patokallio : > Greetings, > > There are a whole bunch of external editors for Mediawiki, but are any of > them capable of merging/diffing changes instead of simply overwriting *if* > the session is closed in the meantime? That is, if: > > 1) I open an article externally (v1) > 2) Somebody else changes the article (v2a) > 3) I save the article back to the Wiki (v2b) > > Ideal behavior would be that, assuming no conflicts, v2a and v2b are > silently merged into a new version 3. MediaWiki does not appear to > support this -- by design? > MediaWiki does exactly this. If there are no conflicts between v2a and v2b, they will be merged silently. > Acceptable behavior would be that I am warned of the difference between > v2a and v2b and allowed to manually resolve them. This works _if_ my > original MediaWiki edit session is still open, but if I have closed and > reopened it (or simply gone away for long enough for the session to end, > so I need to reload the edit page), MW considers v2b newer than v2a and > simply silently overwrites it. > > Any ideas for how to fix and/or work around this? > To decide whether you've "seen" a certain change, MediaWiki uses the time at which you loaded the edit form: any edits made before this time will appear in the edit box, and any made after will be considered for potential conflicts. However, in certain cases (like restoring your browser session when you restart your browser), your browser may reload the edit page but substitute the old content (containing your work in progress) in the edit box. MediaWiki doesn't know about this, so it records the so-called starttimestamp "wrongly". Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop! :)
2010/2/27 David Gerard : > The parser typically takes 2-10 seconds on an uncached en:wp page, so > speeding that process up 1000x is, um, HOLY CRAP! > You're comparing apples with oranges. Domas was testing a simple API page info query, which is much more lightweight than a full-blown parse involving enwiki's crazy templates. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Newbie questions
2010/2/25 Huib Laurens : > Hi, > > I don't know if there is a FAQ but the Wikimedia tech staff is on this > list for sure :-) > This list is mostly for two things: 1) discussing technical details of MediaWiki (proposing changes to get feedback, announcing high-impact changes, etc.). This is mostly communication between experienced developers 2) relatively difficult and/or technical questions about MediaWiki (usually posed by less experienced developers and answered by experienced ones, but even the most experienced of us ask questions sometimes). Easy questions go to mediawiki-l Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] is there some extension for user do a checklist feedback function?
2010/2/25 Evel liu : > but I dont know how to use in my wiki, could you give me a link or usage > instruction? http://www.mediawiki.org/wiki/Extension:Quiz#Installation_Instructions Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] is there some extension for user do a checklist feedback function?
2010/2/24 Evel liu : > Hi all, > > and I find a extension of Extension:Quiz > > but I dont know how to use it in the Mediawiki because the extension is for > Wikiversity only > It's not for Wikiversity only. It was developed to be used on Wikiversity, but it should run fine on any MediaWiki install. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Only 132 / 252 SVN users have valid USERINFO data
2010/2/21 Aryeh Gregor : > On Fri, Feb 19, 2010 at 6:45 PM, Ævar Arnfjörð Bjarmason > wrote: >> If you're one of the guilty or know the contact info for them please >> add it to USERINFO/ > > Probably some people don't want to publish their real name or e-mail > address publicly. > A significant number of the users on the list are WMF staff or contractors, who should definitely have this info available (and are listed on the staff page on foundationwiki anyway, if they're staff). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions in SVN looking for a maintainer
2010/2/15 Ævar Arnfjörð Bjarmason :
> Domas has also complained that it eats up resources. Is this something
> that can conceivably be fixed in it or is it just inherent in anything
> that calls the parser from an extension tag and will thus need parser
> fixups to get anywhere?
>
IIRC Domas was complaining about {{cite}} *templates* and their
complexity. Their inefficiency was unrelated to the Cite extension
AFAIK.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin system rewrite
2010/2/10 Aryeh Gregor : > I'm also concerned by the fact that at least some (I haven't looked > closely) of the Usability Initiative stuff seems to work only in > Vector. For instance, apparently EditWarning doesn't work at all in > non-Vector skins, although it's surely just as applicable. Skins > should *only* be used to provide different visual appearance -- they > should not be creating functional differences. Users should be able > to choose which skin they prefer based on aesthetics alone, without > having to sacrifice features to use their preferred skin. > EditWarning only working in Vector is a weird quirk that is indeed unnecessary. The other Vector-only modules, however, do stuff that's rather Vector-specific and need skin support (like collapsing tabs, enhancing Vector's search box, etc.). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin system rewrite
2010/2/8 Jack Phoenix : > Hi all, > > MediaWiki's skin system has been quite a mess for some while. I decided to > try rewriting it AWESOME! Someone finally took up this task :D > and you can see the end result on [1]. It's quite a big > patch, which is why I want to encourage all developers to test it and report > (or maybe even fix? :) any and all issues they stumble across. Why didn't you do this in a branch in SVN? That seems more convenient. > I haven't ported Vector skin to use this new system because it's currently > under development. Not any more, the Vector skin itself has been stable for months. All the usability work is currently done in the UsabilityInitiative extension. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flattening a wikimedia category
2010/2/7 David Gerard : > The problem is that doing this before the feature that uses it is in > place renders categorisation on Commons even more useless. What this > will mean is that you will be requiring a direct reduction in the > usability of the wiki content before *possibly* implementing a > feature. > > In practice, the difference between this and saying "No, never" is > telling people to do work that you know can't happen. > There's no reason why it couldn't be the other way around: an intersection feature could be written and deployed *first*, *then* the category trees on Commons would be gradually migrated to the new system. Issues like nonsense results for automatic flattening could be migitated by disabling features or making them less visible. > Please leave commons-l in the cc: this time, thanks. > I did on my earlier reply, and I got a bounce from commons-l-owner saying my message was rejected because I'm not subscribed to commons-l. I'm not going to subscribe to that list, so I left the Cc: commons-l out this time. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flattening a wikimedia category
2010/2/7 David Gerard : > Could the developers please outline, point by point, the precise hoops > we need to jump through to get category intersections on Commons? New > hoops seem to have been introduced during the currently discussion. > > Please make an unambiguous list of the hoops Commons will be required > to jump through before this feature can happen, so it's actually clear > to all and we're all working from the same page, rather than trying to > guess what shrubbery you'll be demanding next. > Different implementations have different hoops associated with them. As long as there's no concrete implementation, there's no definitive list of these hoops, only vague generic hoops that apply to any kind of category intersection and hypothetical hoops based on hypothetical implementations. Like Aryeh said, Neil is currently working on a concrete implementation of category intersections. Only when that implementation is complete (or at least close) will it be possible to provide the definitive, specific and unambiguous list of requirements you asked for. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developer Meet-Up in Berlin, April 14-16
2010/2/5 Trevor Parscal : > Do we know what location of the conference? I'm sure most of us want to > book hotels as early on as possible, and as close to the venue as possible. > WMDE let people book their lodging through them last year, and Daniel seems to imply this'll be done again this year, so I guess folks can always go that route. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] help about the extension about the URL's argument's value transfer to content's area.
2010/2/2 Evel liu : > Dear all, > > my new problem: I have the format csv files. now I need a extension to > import them and then create the new fix template's page. > which extension I should use? > thanks for you kindly help or reply. > You haven't provided any specific information about what's in these CSV files or what you want the import to do with them. Writing a shell script that converts them to pages and adds them to the wiki shouldn't be hard though. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] help about the extension about the URL's argument's value transfer to content's area.
2010/2/2 Evel liu : > help about the extension about the URL's argument's value transfer to > content's area: > > 1, the URL is > http://localhost/wiki/index.php?title=ProjectSpin:your_project_name&action=edit&redlink=1 > and I want to make the project name auto add into the editor project > template's area (your project name) .so how should I do and > and which extension I should use? > You can use a hook for that: http://www.mediawiki.org/wiki/Manual:Hooks/EditFormPreloadText Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search article error (Inner error)
2010/1/29 李琴 : > > Hi all, > I search an article in my localwiki,sometimes it shows the error: > Inner error > > Preprocessor_DOM::preprocessToObj generated invalid XML > This is probably caused by an extension. Try turning off extensions to see if that fixes the problem. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] enwiki database dump schedule
2010/1/29 Anthony : > And the history dump, which had run for a month and a half and looked like > it was going to actually complete for the first time in years, is now > broken. Thanks a lot. Obviously this wasn't sabotaged on purpose. Please assume good faith and refrain from sarcastic comments such as the above. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] checking understanding of file uploading
2010/1/29 Christensen, Courtney : > Does anyone have any clues for me on either: > -how to start figuring out the wiki image upload code? > OR > -another way to get around Windows permissions and create this file for our > users? > Have you tried the importImages.php maintenance script? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
2010/1/23 李琴 : > hi all, > I built a local wiki, and I want to set the recentchange limit to > 500|1000|5000|1. > I changed the $wgRCLinkLimits = array( 50, 100, 250, 500 ); > to $wgRCLinkLimits = array( 500, 1000, 5000, 1 ); and 'rclimit' => > 1. > > Is this right? Or is there something more to do? > Looks OK. Have you tried to see if it works yet? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feedback for Bugzilla3.4.4
2010/1/19 Chad : > This means you're still looking at the old Bugzilla. DNS entries > are propagating around the world. Works fine once it's switched. Yeah it's switched around for me in San Francisco, might take a while to propagate all the way down to New Zealand. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Upgrade tomorrow (01-19-2010)! -Service will be unavailable
2010/1/18 Sam Reed : > Awesome, thanks! > > Are we going to 3.4.4 then? > I think so, yes, with a new skin. > And whose dinner time? ;) > Lunch time in the office I assume, so that'd be around 20:00-21:00 UTC. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Upgrade tomorrow (01-19-2010)! -Service will be unavailable-
2010/1/18 Gerard Meijssen : > Hoi, > I had my evening meal ... Lunch is in how much time (approximately) ? I'm assuming this is lunchtime in San Francisco, which is between 9 and 10 PM CET. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some suggestions about the edit page.
2010/1/13 Aryeh Gregor : > We have this in the Drafts extension, don't we? I don't know what its > status is. > We at the usability initiative have the intention to integrate that at some point, but no concrete plans yet AFAICT. >> %% Un-cruft mode %% >> >> There seems to be a lot of "META" information on the wiki, all this >> metainformation like "stub", etc.. sould be optional. There must be >> a single checkbox option to disable it all. I don't want to read even >> 1 more "citation needed" or "this is a stub" bloat. Maybe default >> sould be to "show cruft". > > You mean when viewing articles, or editing them? Cutting out cruft > when editing is something the usability project is looking into, > AFAIK. We're working on that now, yes. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] svn switch for wmf-deployment
2010/1/12 Domas Mituzas : > OK! I was just wondering if there'd be any practice that would be helping you. > The right way to do this is by committing your live hack to trunk first, then merging it to wmf-deployment-whatever, and run svn up on the server (to no effect other than removing the modified flag on the file). Committing stuff to wmf-deployment-something and merging it back is a lot trickier and should ideally be avoided. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] svn switch for wmf-deployment
2010/1/12 Tim Starling : > Another advantage is that we'd have a major version number that we can > say Wikimedia is running on. We had three deployments of 1.16 and > there may be a fourth before we branch it and start on 1.17, but these > branch points are unnamed. Instead we could call them 1.16wmf1, > 1.16wmf2 and 1.16wmf3 in Special:Version, and we could keep track of > when those updates were deployed, so that users would have a better > idea of how to talk about the software that we're running. > This part is what gets me excited most (sane version numbering), but not messing up the logs is also very nice. > I've used svn switch a few times in other situations, and haven't > encountered any problems with it. As long as there are no uncommitted > patches in the live working copy, it should go ahead without a hitch. > That's my experience yes. However, there are currently 11 locally modified files in wmf-deployment, so that'd need to be cleaned up first. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
2010/1/11 Praveen Prakash : > May I know why some bugs (like this > https://bugzilla.wikimedia.org/show_bug.cgi?id=21497) still remain not > resolved even after months? > It's an extension bug, and the extension in question may not be maintained very well any more. I think EasyTimeline was written by Erik Zachte but is hardly maintained any more. More generally, bugs can be ignored and left to rot, that happens. You may need to poke developers or whoever maintains EasyTimeline these days to get them to do something about it. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] search updates
2010/1/10 Robert Stojnic : > Additionally, I've switched mwsuggest to lucene backend, so now the AJAX > suggestions are no longer alphabetical but ranked according to number of > links to them (and some CamelCase and such redirects are not shown). > This has been active on en.wp for a while, but now it's on all wikis. > Did you do this by changing the backend API action=opensearch uses, i.e. without (significant) changes to the actual AJAX code? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The future of action=ajax
2010/1/10 Angela : > On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor > wrote: >> No. At this point we should remove $wgEnableAPI and set it to true >> unconditionally. Other things already randomly depend on it, like >> watchlist RSS feeds. > > Enabling it has caused data to be leaked from private wikis in the > past. Has that been fixed? > Actually, the API is now overly restrictive on private wikis, disallowing all actions except login from users without read rights. This means they can't get certain data that they could get through the UI (like the content of whitelisted pages such as the main page, the /name/ of the main page, the wiki's name and content language, etc.). For most users this is annoying and should be fixed, but for operators of private wikis it's probably a comforting thought that, for now, even the most innocent requests to do anything but log in will be denied to users without read rights. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The future of action=ajax
2010/1/9 Daniel Kinzler : > Oh, also: action=ajax supports http cache control. can this be done with the > api > yet? > Yes, with the maxage and smaxage parameters. AFAIK those are currently broken on Wikimedia, however, because Squid overrides the caching headers set by the API. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Vs other trackers.
2010/1/7 Trevor Parscal : > Hmmm... Not being able to distinguish the difference between a bug > tracker and a wiki based on the skins being similar is a point of view I > have a hard time understanding. Having read quite a few bug reports written in wikitext (which mostly doesn't work in Bugzilla, except for [[links]]), I would encourage a clearer distinction between the wikis and the bug tracker. I don't want to give people the impression that what they're reporting bugs on is really a quirky wiki variant: the bug tracker not only uses different syntax, but also has different policies, procedures and protocols. I like the Launchpad design, its use of less jargon-like language and how it lists status changes amid the comments and provides a full activity log on a separate page. > Having a consistent style across our > tool-chain would by most people's thinking be an improvement in the way > that each tool is more connected feeling... > That's a nice idea in principle, but as outlined above I'd like to keep the similarities limited. Our bug tracker should actively communicate it's Wikimedia's (name and logo in prominent places) but shouldn't feel /too/ familiar to people that are used to wikis. > Besides, we would be styling it with Vector not Monobook. Monobook is so > last decade! > I do agree that if we restyle anything, we should at least improve its looks :) Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Production machine config
2009/12/9 Roan Kattouw : > 2009/12/9 William Pietri : >> >> Somone recently suggested this to me: >> >>> In terms of configuration this lists most of whats public: >>> http://noc.wikimedia.org/conf/ >>> >> >> I just went back to look at these again, and I see that link is now a >> 404. I take it the configs have moved. Does anybody know the best place >> to get that now? >> > Right now, noc is broken and the config files are nowhere. I've been > prodding sysadmins to fix this, will continue doing this more > aggressively. > Fred fixed this yesterday. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Production machine config
2009/12/9 William Pietri : > > Somone recently suggested this to me: > >> In terms of configuration this lists most of whats public: >> http://noc.wikimedia.org/conf/ >> > > I just went back to look at these again, and I see that link is now a > 404. I take it the configs have moved. Does anybody know the best place > to get that now? > Right now, noc is broken and the config files are nowhere. I've been prodding sysadmins to fix this, will continue doing this more aggressively. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of global file usage?
2009/12/2 Magnus Manske : > I'm lazy; could someone please point me to the /new/ database schema, > so I can plan to adjust my tool if necessary? > If I'm not mistaken, the new schema is the one currently in SVN: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/GlobalUsage/GlobalUsage.sql?view=markup Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unicode equivalence
2009/12/1 Marcus Buck : > If there are performance problems with the conversion on serving or > anything like that, of course storing the data in 5.0 is still good > enough. You're answering your own question here: converting the data once and storing it in 5.0 so it's ready-to-serve is of course faster and easier than juggling between 5.0 and 5.1 all the time. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2
2009/11/27 Tim Starling :
> Roan has re-added js2/js2stopgap.js. I would prefer to see the JS2
> functions in that file deprecated, and for extensions targeting 1.16
> to use interfaces which we can more easily continue to support into
> the future.
>
I'm all for it, as long as the existing feature set provided by
js2stopgap remains.
> loadGM(), gM(): misnamed, neither should be global, excessively
> abbreviated and unintelligible function names. I suggest adding
> mw.getMsg() and mw.addMessages() to wikibits.js.
>
> $j: idiosyncratic, what's wrong with calling jQuery jQuery like
> everyone else?
>
I have no idea why that was done. Note that the 'normal' alias for
jQuery (the one it also defines itself) is $ .
> function js2AddOnloadHook( func ) {
> $j(document).ready( func );
> }
>
> The "js2" prefix will disappear from all interfaces in a future
> version. Callers can just use jQuery(document).ready() directly.
>
> mvJsLoader = { doLoad: function( deps, callback ) { callback(); } };
>
> Note that mv is an abbreviation for Metavid, nothing that starts with
> mv belongs in the core. Calls to this should just be removed for now,
> since it doesn't do anything. There will eventually be a function
> called mw.load() which does a similar thing.
>
> The filename, js2/js2stopgap.js, has the problem of containing js2 not
> once but twice. I have previously suggested adding an
> OutputPage::addJQuery() interface, which removes the need to specify
> the filename in the extension and can be designed to avoid the
> possibility of duplicate script tags. I still think that this is a
> good idea.
I agree; I must've missed this the first time you suggested it.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SQL
2009/11/26 李琴 :
> hi.sorry to borther again
>
> I want to ask how to rewrite those statement ,too.
>
> Like '>,<,LIMIT '.
>
> And when I use 'order by ' how to change the order of 'ASC,DESC'?
>
LIMIT and ORDER BY are similar to GROUP BY, which Tim already
demonstrated. ASC and DESC can just be appended to the order by
column, like 'ORDER BY' => 'rc_id DESC' . Note that ASC is the default
and never has to be specified explicitly. Tim also demonstrated how to
do equalities (like 'rc_namespace' => 0 ); other conditions go in the
same array, but as one string (like 'rc_namespace != 0', 'rc_namespace
< 2' and 'rc_namespace=page_namespace' ).
There's also lots of examples in the MediaWiki codebase, just grep for
'select('.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SQL
2009/11/26 Tim Starling : > Don't use subselects, they're not supported by MySQL 4.0 which is what > we target. > > $dbr = wfGetDB( DB_SLAVE ); > > $max = $dbr->selectField( > 'recentchanges', > 'max(rc_id)', > false, > __METHOD__, > array( 'GROUP BY' => 'rc_title' ); > > $res = $dbr->select( > 'recentchanges', > '*', > array( > 'rc_id' => $max, > 'rc_namespace' => 0, > 'rc_title' => 'Wiki', > ), > __METHOD__ ); > Note that the GROUP BY condition in the first query is unnecessary, and that the whole thing could be rewritten to SELECT * FROM recentchanges WHERE rc_namespace=0 AND rc_title='Wiki' ORDER BY rc_id DESC LIMIT 1; Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia database
2009/11/23 : > Thanks. but is that page_latest is unique in page table? > Yes. Every revision belongs to one page only (rev_page). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] skins
2009/11/23 李琴 :
> I followed the guidelines and made a special page.But I can't see it
> anywhere.
>
> Where can I see it?
>
> Or maybe I didn't add the special page to special list? :)
>
If you followed the instructions in
http://www.mediawiki.org/wiki/Manual:Special_pages#The_Setup_File and
put require_once("$IP/extensions/MyExtension/MyExtension.php"); in
your LocalSettings.php , your special page should show up in
Special:Specialpages.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] skins
2009/11/23 李琴 : > > Hi > > I add a page to the wiki which I write by myself . And I want to use the > wiki's skins .What can I do to resolve this problm. > > Use getSkin() ? Or something others? > You don't need to do anything special if you follow the guidelines at http://www.mediawiki.org/wiki/Manual:Special_pages (provided making a special page is what you want). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia database
2009/11/21 : > I need use rev_user and page_namespace to do crossing-analysis. How i can > put them in the one table? thanks again. > You don't need to put them in one table, just use a query with a JOIN. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia database
2009/11/19 : > Greeting, > > May I ask the question about wikipedia database. I downloaded the Wikipedia > revision current data. and found there are some records have the exactly > same rev_id, rev_user and same timestamp. What does it mean? are they the > same edit or different? > If they belong to the same wiki, they're very likely to be the same edit. Of course such duplicates should theoretically not occur. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] {{Encyclopédie recherche}}
2009/11/18 Bilal Abdul Kader : > Greetings, > This template is not being parsed on my french local wiki. Any hints on > that. I did several search on google but I could not find the problem. > Exactly what does happen? Do you see raw template code? Red links? Nothing at all? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Questions about fields in wiki dumps
2009/11/10 Jeff Kubina :
> I am working with some enwiki-{MMDD}-stub-meta-history.xml dumps and
> wanted to get clarification on how certain fields of the articles can
> change:
>
> 1. What action will make an article get a new pageId? Is it
> only move/rename, a redirect, or a deletion and recreation, or are there
> other ways this could happen? Can any of these changes be detected from the
> stub-meta-history.xml files?
>
When a page is moved, it'll change its name but keep its pageid. A
redirect will be created at the old name with a new pageid.
> 2. Is it possible for just one particular revision of an article to be
> deleted, maybe due to a copyright violation? If so, is just the content of
> the revision deleted or would this include all the data associated with it,
> so that the revision would not even appear in the stub-meta-history.xml
> file?
>
Yes. In this case, any trace of the revision ever having existed is
gone from the dumps, AFAIK.
> 3. Are pageIds recycled? If a page is deleted, could its id number be used
> for a completely new page in the future?
>
No, pageids are never recycled.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] editpage error
2009/11/9 李琴 : > id="updateform"> * Replace the backslashes by forward slashes * Verify that ../includes/update/update.php is the correct relative path to update.php * Verify that Apache isn't configured to deny access to the includes/ directory Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Mediawiki-api] API (query action) ( mediawiki - 1.12 )
2009/11/3 Jan Luca : > "unknown_action: Unrecognised value for parameter 'action'" > > I don't kinow if I am doing anything wrong. > The wiki you're querying doesn't allow anonymous users to read, you need to log in for that. In MW 1.12, the API simply pretends action=query doesn't exist in that case. Later versions of MW give a clearer error message. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] strategy discussion
2009/11/2 Benjamin Lees : > On Mon, Nov 2, 2009 at 2:07 AM, Eugene Eric Kim wrote: > >> Our first session will be on Monday, November 2 at 21:00 UTC (8am EDT; 1pm >> PST; >> 10pm CET). We'll be talking on #wikimedia-strategy on freenode. >> > > I don't think the American times are correct. 21:00 UTC is indeed 10pm CET and 1pm PST, but it's 4pm EST (note that EDT is Eastern Daylight Time). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Add record to database
2009/10/26 李琴 :
> I'm working inside mediawiki php,but I just beginning. Can you tell me when
> I finished editing a article and clicked the save button,which variable
> takes the content of the edit box?
> Or which function handles the rawText?
>
It's in $wgRequest->getVal('wpTextbox1'); I'm not sure you want to be
messing with EditPage's internals, though, because even most MediaWiki
developers think EditPage is scary.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Datamining infoboxes
2009/10/23 Robert Rohde : > Given the fairly obvious utility for data mining, it might make sense > for someone to extend the Mediawiki API to generate a list of template > calls and the parameters sent in each case. > We had a discussion about this Tuesday in the tech staff meeting, and decided that we want to put this data mining possibility in core at some point (using a table like pagelinks to store these key/value pairs and modifying the parser). As you may understand this is not a very high priority project, and I don't know if any of the paid developers are gonna do it any time soon. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Questions: parser functions, article caching
2009/10/23 Dmitriy Sintsov : > 2. My extension generates dynamical content. Because of that, I use > $parser->disableCache() in my tag parser hook. But, the dynamical > content is being changed only in two cases: > > a) The user edits the page. In such case, disableCache() is not > required, because Article cache should be properly flushed by core. > > b) The user submits the poll. After the processing of POST data I > redirect with 302. In such case, which is the best way to conditionally > flush the cache - will parser->disableCache() work after the POST and > before the 302? To me it looks that it won't have an effect on the next > GET after the redirect. Or, I'd better use Article::doPurge() (or, that > is too slow?). I think purging after the submission of the poll would probably be good enough, so you wouldn't need disableCache(). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Datamining infoboxes
2009/10/23 Andrew Dunbar : > But my attempts to find such pages using either the Toolserver's > Wikipedia database or the Mediawiki API have not been fruitful. In > particular, SQL queries on the templatelinks table are intractably > slow. Why are there no keys on tl_from or tl_title? > There are: CREATE UNIQUE INDEX /*i*/tl_from ON /*_*/templatelinks (tl_from,tl_namespace,tl_title); CREATE UNIQUE INDEX /*i*/tl_namespace ON /*_*/templatelinks (tl_namespace,tl_title,tl_from); It's just that tl_title is always coupled with tl_namespace because that's how you should be using it (tl_namespace=10 for the template namespace). Note that the former index can be used as an index on (tl_from) as well. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problem with Upload API
2009/10/21 Russell Blau : > So, basically, the API for action=upload is (a) not compliant with RFC 2388, > and (b) failing with a misleading error message when the client fails to > supply a parameter that isn't used at all? > Neither of these is true. The filename parameter specifies the name of the file ON THE WIKI, like the second textbox in Special:Upload does. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Add record to database
2009/10/21 Platonides : > If you're working inside mediawiki php. > > $wgTitle = Title::newFromText( "MyArticle" ); > $wgArticle = new Article( $wgTitle ); > $wgArticle->insertNewArticle( "Some text", '', false, false ); > > > If you don't want to work with php, use maintenance/importTextFile.php > Please use other variable names than $wgTitle and $wgArticle to reduce confusion with the global variables by the same name. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] File Compare Tool
2009/10/19 Arjun Priyananth : > Hi, > Can anyone tell me what is the tool which wikipedia uses for file compare. > (in the wikipedia website it compares two history) what is that tool please > It's the standard GNU diff utility, which is available on most Linux/UNIX systems. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data Processing
2009/10/12 Christensen, Courtney : > Is there a size range at which it is accepted to be advantageous to move your > text out of the standard text table? > It's not so much about size as it is about load. Wikipedia uses ES because it's a heavy-load wiki. More specific directions about when ES makes sense and when it doesn't are probably better given by people more familiar with databases than me. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Squid status codes, please advice
2009/10/12 Robert Rohde : >> B >> For action=submit the difference between preview and save is in the result >> codes right ? >> I understood earlier that TCP_MISS/302 is a successful save, right ? > Upon a successful save, action=submit uses a 302 to redirect to the page view of the newly updated/created article. So typically, a successful request to /w/index.php?title=Example&action=submit will redirect to /wiki/Example using a 302. >> For action=edit how to interpret /200 vs /302 ? > > I don't know when action=edit would give a 302. It is obviously very > common, but my attempts to guess where it would come up have failed. > If you can grab some examples of URLs generating the 302 response it > might become clear quickly. > URLs with &redlink=1 redirect to the page view with a 302. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data Processing
2009/10/11 李琴 : > Sorry,I can't get this sentence's exact meaning. 'External storage stores > page text on a separate DB server to the main wiki database.' > > What 's separate DB server ? > Or I just want to know where can I get the page content? > On Wikipedia, we use one set of DB servers for the wiki database, and a second set for text; this second set is called the external storage. You don't need to worry about this too much, as small wikis typically don't use external storage, but use the text table instead. The difference view in recent changes is produced by comparing two texts using an external program like diff; it's not stored anywhere (other than possibly in the objectcache table, for caching purposes). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Image view statistics?
2009/10/10 Michael Peel : > Ideally, I'd like to know how many times an image is viewed by all > sites that use Commons as their image repository, preferably using > the API. I see that there is a "counter" option in the API, but that > doesn't seem to be working [2]. > The counter field in the prop=info output provides the number of pageviews for the image description page, not for the image itself. Also, the page view counter is disabled on Wikipedia because of performance reasons and because Squid caching would cause it to miss a lot of views and report a ridiculously low number. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] C++ implementation of the MediaWiki API
2009/10/10 Brian : >> Or, does anyone else know of a C++ implementation of the MediaWiki API? [snip] > Sorry but it is tied to our software. At any rate it's a piece of cake, > especially with Qt. I believe the post of mine that you are quoting was > with respect to the lack of upload support in the api which has since been > fixed. To be clear: implementing the API /itself/ in C++ is not really possible as the API is closely integrated with MediaWiki. Writing a /client library/ for the API in C++ is very much possible, and as Bryan mentions quite easy if you're already using Qt. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Has anyone heard of a "file download" issue with Mediawiki / Wikipedia?
2009/10/8 Aude : > That will happen when the "Use external editor by default" option is checked > in editing preferences. In order to get external editors to work, the > browser needs to be configured. > > http://www.mediawiki.org/wiki/Manual:External_editors > > If that's not the problem, then I'm not sure what the problem is. > Alternatively, it could be that a blank page somehow got stuck in Squid. If that's the problem, it should go away when the page is edited or purged. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Google Earth layer
2009/10/2 Tei : > On Fri, Oct 2, 2009 at 3:37 PM, Strainu wrote: > ... >> I'm not sure if Wikimedia has anything to do with it, but I think I >> have a better chance of getting an answer here than by asking Google >> (the company) directly. Google (the search engine) was not really >> helpful on the matter. > > you could always install Ethereal, and spy the trafic from your > computer to the network. It probably include some HTTP servers, and > GET / POST request you can read. > The LiveHTTPHeaders extension for Firefox will also do this job for you, and is a bit easier to install and use. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation while editing
2009/10/1 Brion Vibber : > I'm pretty sure the usability kids have something to this effect up > their sleeves, hiding somewhere. > Sort of. We have a link insertion dialog that shows title suggestions and page existence status as you type in our Babaco release, which should be deployed very soon, and we have ideas about adding a link preview to that dialog. We originally envisaged "link preview" to mean a preview of what the actual link looks like, but having a preview of the linked-to page, if it exists, sounds like an interesting idea. I've forwarded the original post to the rest of our team, and I'll point them to the rest of this thread as well. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template editing
2009/9/27 Steve Bennett : > *falls to the ground and starts kissing your feet* > *refers praise to other people; I'm mostly just a code monkey there* > Awesome. Timeframe? Screenshots? > Nothing just yet. Right now we're focusing on getting the Babaco release deployed shortly. When that's done and the inevitable post-deployment problems have settled down, we're gonna get cracking at Citron features. We do have some mockups for Citron features at http://usability.wikimedia.org/wiki/Babaco_Designs#BEYOND_BABACO ; for a list of features per release see http://usability.wikimedia.org/wiki/Releases . > (Also, you're not actually calling them "stubs" are you? Confusing...) > No, fortunately not; I was just trying to come up with a shorter word for "visual placeholder for table/template/ref syntax that's much shorter than the actual syntax and that can be expanded and collapsed". They probably won't be called anything at all: we don't really need a name for them. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/26 Dmitriy Sintsov : > I am very much supporting you! Both code colorizing and AJAX editing > preview. The usability initiative intends to do both, in addition to code folding (compressing long and complicated things such as templates, table calls and references into a small placeholder than can be expanded at wish). > And maybe a links "code completion" - when yuu press [[ it will > open an JS-generated dialog with drop-down title search list. We've done something similar to this idea, and hope to deploy it on Wikipedia soon. Basically it's a toolbar button that launches a link dialog with title suggestions for internal links. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)
2009/9/26 Michael Dale : > Performance wise I attached a quick test.. seems pretty fast on my machine > with a recent firefox build .. but older browsers / machines might be > slower...at any rate we should read for both for speed and readability and > "security review" ;) > This mailing list scrubs attachments. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/26 Brian :
> Roan, sorry that the idea is pretty hard to convey, I'll try again.
> The basic idea is that you can create templates using templates
> (just using current
> tech). It's easy, you just pass parameters to a template that control
> its output, and this
> output is a new template. The parameters that you passed determine what the
> new template looks like, and what it's output will be.
>
Right, so basically this is just templates calling other templates,
right? This already happens to some degree already.
> We can imagine a master template on Wikipedia that is used to generate all
> infoboxes. It could work in arbitrary ways, but suppose it works this way:
> The master infobox template creates a template for each wikiproject. The
> template that it creates for each wikiproject further creates templates
> representing every kind of infobox that this wikiproject uses. So you have a
> master template that creates baby templates that create infobox templates.
>
> Using current tech this isn't exactly feasible, only advanced users will do
> it since you have to directly interact with the templates and it would be
> tough to code up. But if you make such a feature highly usable, by, for
> example, tacking an easy to use interface on top of it, the usage of such
> techniques will proliferate.
>
To use the master infobox example: such a template would have about a
dozen usage modes, each with dozens of parameters. Such constructs are
actually /easier/ to call by hand than with a form, because you'd
either have to store all the relationships between the parameters and
usage modes in the XML file and let the form handle all that (which is
a degree of complexity I personally would not like to see in a
template forms implementation) or just throw a couple hundred
parameters in the user's face.
Also, this being tough to code up would not change: again, we're not
simplifying the *writing* of templates *themselves* in any way. The
fact that these templates include template calls doesn't change that,
because 1) you're gonna be using #if constructs all over the place
anyway, 2) you'd need to use stuff like {{{2|{{{1|}} as arguments
to template calls, which the GUI doesn't simplify and 3) if you're
skilled enough to do 1 and 2 and familiar enough with the templates
you're calling to be writing a master templates, you don't need an
editor or form to build the template calls for you.
> More general kinds of interface builders that build all imaginable kinds of
> interfaces are conceivable.
>
> Is this not possible within the scope of the suggested system?
>
Yes, but it's also possible within the scope of the current system.
You don't /need/ a template editor to be doing this kind of monkey
business. In fact, I think a template editor would actually discourage
these practices, because relatively unexperienced users must be able
to build a reasonable template call using the template editor. For the
latter to work out, templates need to be simpler rather than more
complex.
In short, I don't think introducing a template editor would encourage
master templates and similar complexification of templates; in fact, I
believe it will actually encourage simplification, because a
nice-looking GUI for a big incomprehensible parameter soup is worth
the soup.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Platonides : > Those descriptions will have to be edited by the same user base that > edit all other pages. Even if they are power users, it's not easy to > write correct XML on the wiki textarea. We would need to create an > editor for the language being created so a template editor can be made. > Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML. > I advocate for a simpler syntax for form definition (but we shouldn't on > the way reinvent wikitext). > Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian : > * This will fundamentally change mediawiki and the consequences of this > feature have not been considered > * It will support the creation of new interfaces from interfaces, simply by > creating templates that create new templates and using the interface to that > template to create the new interface. Is this correct? Wait, what? Can you explain this better or provide an example? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian : > However powerful it is, I'm not sure we can really rule out future > incompatibility as you suggest by simply stating that we can easily > forwardport. This feature is intended to hack a fix on top of the usability > issues inherent in templates. Every time we have a discussion about the > pitfalls of wikitext the center of this discussion is templates. Even > without parser functions they are turing complete - with them it is a > complete usability disaster. So it seems that when we finally get around to > developing a consensus about the changes we want in wikitext, there will be > widespread agreement that we need to change templates. But so far, without > any clear strategy on that front, we have no idea what those changes will > be. > It's important to separate template *calls* from template *implementation*: only the latter involves ParserFunctions and all that other ugliness. Even if and when we do completely redo the way templates are *written* on the inside, the way they're *called* from the outside would probably not change significantly, nor would the concepts of parameters and types. This means redoing template syntax does not require any changes to the XML format. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian : > I am not here saying that it is a bad feature, not a bit. In fact I have > previously advocated on this list for the ability for users to specify > form-like interfaces. What I am saying is that I think it's premature. There > is a tradeoff that needs to be balanced here. It's easy to add new features > and hard to fix the old one. As we add new features however we diverse > farther and farther from the possibility of fixing wikitext. This is > especially when efforts to add new features are done entirely out of the > context of a clear strategy for eventually fixing wikitext. > > So before a feature such as this is implemented, or any new substantial > language is added to MediaWiki (such as ParserFunctions, or this interface > specification language), I would like to see work done on the Strategy wiki. > I don't think new work such as this should be done outside of the context of > a very clear vision of how we will eventually fix the whole problem. And I'm > entirely willing to help. You seem to be missing my point (or at least are not refuting it): if implemented properly, with the minimal assumptions I mentioned, subsequent reworking of wikitext *wouldn't* *matter*, because the template call editor could easily be ported to the 'new language' or whatever we end up with. It wouldn't put us any further away from fixing wikitext; the trade-off you mentioned does not exist IMO. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian : > Also, I am quite serious about my point that an entirely > new language interface specification will be added to MediaWiki and that it > will be widely adopted and propagate throughout the wikisphere, much like > parser functions, and in the end will make the job of fixing MediaWiki much, > much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. > From what I have > heard, there was a meeting about how to solve this problem among core devs > and a few others at wikimedia headquarters, they decided what the solution > would be That's news to me; I'd very much like to hear from these people what their proposed solution is. > , and now you guys are moving forward on implementing it, totally > ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template editing
2009/9/25 Magnus Manske :
> As to the issue of getting possible template variable names: Why not
> * load the wikitext of the template in the background
> * remove all nowiki, noinclude, etc
> * get everything that looks like "{{{NAME|" or "{{{NAME}}}"
> * remove known magic words
> * Profit!
>
We (the usability team) do intend to get 'content folding' (folding
template calls and tables into stubs that can be expanded at will)
done in the Citron (third) release.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data Processing
2009/9/25 李琴 : > OK, I see. And the other questions? > > If I edit a page,Whether the page_id change or not? > No, the page_id stays the same when pages are edited, and even when they're moved (in the latter case, page_namespace and/or page_title will change, of course). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Dmitriy Sintsov : > Let's assume an odd occurence of ''' will be converted to and > an even occurence ''' to (begin/end of the node)? Non-paired > occurence will simply cause XML parsing error - there should not be > uneven number of '' or '''. > The point is that wikitext doesn't *have* parsing errors. The parser is very tolerant in that it tries to resolve 'invalid' and ambiguous constructs by some combination of guessing what was probably intended and trying not to mess up the rest of the article (the newline thing mentioned earlier fall in the latter category). I agree that this probably causes the weird quirks that make wikitext such a horribly complex language to define and parse, so I think a good way to continue this discussion would be to talk about how invalid, ambiguous and otherwise unexpected input should be handled. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Beta edit toolbar disabled temporarily
2009/9/17 Brion Vibber : > Due to compatibility problems on Internet Explorer after yesterday’s > code update, I’ve temporarily disabled the Usability Initiative’s beta > advanced toolbar. If you’ve had it enabled, you’ll just get the regular > old edit toolbar until we re-enable it. > > Hopefully we should have this resolved within a day or so, and it’ll be > back on for all our happy testers! > > If you want to follow the fix: > https://bugzilla.wikimedia.org/show_bug.cgi?id=20668 > RockMFR identified the source of the bug, I fixed it, Andrew pushed the fix live and iDangerMouse confirmed the issue as fixed. Thanks all! Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usability initiative
2009/9/17 Steve Bennett : > But honestly, the Usability people > seem to be doing a pretty good and know what they're doing. Do they > need more ideas from us? > We /always/ welcome more ideas, we just can't guarantee we'll agree with you, or that we'll have the time or resources to implement it :) Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Speed of parsing messages (was: how to chang {{SITENAME}})
2009/9/16 Tisza Gergő :
> Some of them may be rephrased, and some localizations do not really need them
> at
> all. Foe example, in Hungarian " " constructs the noun is always
> in singular, so we've been using "{{PLURAL:$1|one|$1}} thingy" because the
> automated checks complain if they see no PLURAL, but on hu.wikipedia it could
> be
> replaced with "$1 thingy" without trouble. (I'm not sure there are actually
> frequently loading messages which have PLURAL, but it's worth checking.)
>
Ideally there'd be a better way to mark a message as "yes, I know this
usually uses PLURAL, but this language doesn't need it here", that'd
also save useless efforts by the parser in expanding PLURAL.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usability initiative
2009/9/15 Robert Rohde : > Is there a road map somewhere for features you plan to include but > haven't gotten to yet? > http://usability.wikimedia.org/wiki/Releases Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usability initiative
2009/9/15 Lane, Ryan : >> Are these releases in any way connected to MediaWiki releases though? >> >> I understand that all that gets release on Wikimedia >> projects, but it'll be >> great to have the rest of MW user base benefit from these as >> well (I have >> personal interest here as you can imagine ;)). >> > > AFAIK the releases are not connected to MediaWiki releases, but instead are > phases of the usability initiative. > That is correct. However, all of the features we code are in the UsabilityInitiative extension, which is available from SVN just like any other extension, so other MW users will benefit (and, in fact, they can already do so). It's not compatible with MW 1.15, however. The Vector skin is in MW core, and will be part of the 1.16 release. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Foundation-l] Security holes in Mediawiki
2009/9/15 Chad : > On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs wrote: >> I was sort of surprised to learn today that Mediawiki software has had 37 >> security holes identified: >> >> http://akahele.org/2009/09/false-sense-of-security/ >> >> Are most of these patched now, or are they still open? If still open, is >> the Foundation making site & user security more of a priority in 2010? >> >> -- >> Gregory Kohs >> ___ >> foundation-l mailing list >> foundatio...@lists.wikimedia.org >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >> > > I'm pretty sure a lot of this has been fixed (I vaguely remember Tim doing > some cleanup to the installer for XSS issues), but I can't say for sure. > Forwarding to wikitech-l, this is more of a tech issue than Foundation > one. > This has been addressed on foundation-l already, but I'll make it extra clear here: all these vulnerabilities reported by these database are only in there because we discovered, fixed and reported them first. The affected versions of MediaWiki range from old to stone-age. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usability initiative
2009/9/15 Dmitriy Sintsov : > * Roan Kattouw [Tue, 15 Sep 2009 13:34:07 > +0200]: >> We're planning to do exactly that in our third release (Citron). Right >> now, we're working on bugfixing and deploying our second release >> (Babaco). >> > What do these codenames mean? Citron is v1.16 and Babaco is v1.17 or > it's something else? No. Acai, Babaco and Citron are names used by the usability initiative, and these "releases" aren't related to MediaWiki versions or releases. Basically, each is a set of new features that we're deploying. Acai is already live, Babaco will hopefully go live in a few weeks, and Citron has yet to be developed. For details as to what's in each release, see http://usability.wikimedia.org/wiki/Releases . > Will these improvements be announced, when available? > Absolutely. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usability initiative
2009/9/15 Dmitriy Sintsov : > Hi! > I've read that usability is important for MediaWiki. Why don't integrate > wikitext syntax highlighting then? We're planning to do exactly that in our third release (Citron). Right now, we're working on bugfixing and deploying our second release (Babaco). > That will greatly improve editing of > the pages. There is Extension:WikEd which has most of the work > implemented already. > http://www.mediawiki.org/wiki/File:WikEd_screenshot.png Yeah, we knew about wikEd, and we'll definitely be looking at it. > I know that it should be possible to install the extension separately. > But I remember that important extensions are sometimes integrated into > MediaWiki. > There's also FCKeditor, but it cannot perform diffs, and visual editing > is not always desirable (non-technical users like it, but I personally > prefer to edit wikitext). > There's still quite a few issues with FCKeditor, and as far as I know it's been decided that the usability project is not gonna cover WYSIWYG; I'm not entirely sure of the official stance here, you'd have to ask Naoko. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] api.php cache-control (was: LanguageSelector bla bla bla)
2009/9/11 Domas Mituzas : > Hi! >> Speaking of which, could we exempt api.php from this? > > We could, we may, I just did it, though... > Yay, thanks! > can anyone explain the C-C header logic to me? For now I see it is > mostly: > > Cache-Control: s-maxage=0, must-revalidate, max-age=0 > Expires: Thu, 01 Jan 1970 00:00:01 GMT > > Also, opensearch has this: > Cache-Control: s-maxage=1200, must-revalidate, max-age=1200 > > what is the 'must-revalidate' doing here? why is there no 'public', etc? > > "It sets sane Cache-Control: headers on its own," - does it? :) > I guess we need public instead of must-revalidate in some places. Someone asked if we shouldn't add must-revalidate conditionally [1], but when I asked on what condition (hey, I don't know all that much about C-C headers, I'm just the code monkey here :P ) I got no response. If someone tells me what the correct behavior is, I'll happily implement it. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LanguageSelector on strategy wiki
2009/9/10 Domas Mituzas : > Squid is overriding at the edge all text content CC headers into: > > Cache-Control: private, s-maxage=0, max-age=0, must-revalidate > > MediaWiki Cache-Control is used internally though. This allows us full > control on lifetime of object with application only, no need to tweak > any squid stuff. > Speaking of which, could we exempt api.php from this? It sets sane Cache-Control: headers on its own, which should not be overwritten. See also https://bugzilla.wikimedia.org/show_bug.cgi?id=14402#c11 and downwards. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Language variants
2009/9/10 Trevor Parscal : > On 9/10/09 10:06 AM, Aryeh Gregor wrote: >> On Wed, Sep 9, 2009 at 6:50 PM, Tim Starling wrote: >> >>> I don't know why you're writing this nonsense, you obviously haven't >>> looked at the code at all. >>> >> This paragraph is unnecessary. >> > Seriously! Please read things aloud before clicking send. You will > hopefully then be able to better detect when it's time to take a break, > eat some fruit and take it down a notch. In Tim's defense: I had indeed not looked at the code at all, and what I wrote was incorrect, so what he wrote was completely true. I also mentioned that my understanding of the variant conversion system was limited, and that I might be completely wrong. Turns out I was, and Tim corrected me. It's true that he probably didn't use the most friendly tone in the world, but I've seen much worse, so I don't really care. Let's just drop this before it turns into a flame war; I'd like to keep those off wikitech-l. > The variant system seems poorly understood by most people (including me) > which often tends to cause something (like it for instance) to also be > under-utilized... > Seems I'm not the only one who had a completely wrong idea about how variants work. We definitely need more documentation and fame for this system, so its potential doesn't go to waste. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Language variants
2009/9/9 Helder Geovane Gomes de Lima :
> Hello!
>
> I noticed at sr.wikipedia there is an option "Variant" under
> "Internationalization" at the preferences. How is that different from
> the 'sr', 'sr-ec' and 'sr-el' which are shown at "Language" option
> (also under "Internationalization")?
>
> I'm interested in this because there are some differences between
> "Brazilian Portuguese" ('pt-br') and "Portuguese of Portugal" ('pt')
> which usually cause troubles for the admins at the Portuguese
> projects, who needs to warn the users not to change the wording of the
> texts from one variant to another (this usually happens, mainly from
> anonymous contributions), because some differences between the
> variants seems to be [at a first glance] a typo, and they want to
> "correct" it...
>
sr-ec and sr-el refer to the Latin and Cyrillic variants of Serbian
(not sure which is which), and AFAIK the software can convert
everything, even article text, because the conversion rules are so
simple that a computer can execute them. Basically, sr-ec and sr-el
have the same text in the same language, but in different alphabets.
(This is my understanding, which may be completely wrong; in that
case, please correct me.)
The difference between pt and pt-br are more delicate than that, and
the two can't be autoconverted between by a computer, because of
differences in spelling word usage and grammar(?).
> So, I would like to know if there is currently any feature which could
> help us to avoid the problem of having a divided community of users
> ('pt' x 'pt-br') "fighting" with each other ad infinitum... (and to
> avoid proposals like that [1] of a new "Brazilian Wikipedia", which
> IMHO will not have any good result, and is not the better way of
> solving the problem...)
>
No. We already offer users the choice between having the interface in
pt or pt-br (or any other language, really), but such a choice doesn't
exist for the content.
> I found
> [http://strategy.wikimedia.org/w/index.php?title=Proposal_talk%3AA_Brazilian_Portuguese_Wikipedia&diff=14163&oldid=13621
> a comment] about the existence of "on-the-fly translation" for some
> languages (Chinese and Serbian), but I don't know how it works, and if
> it solves or improve the situation.
>
That's the alphabet variant thing I mentioned earlier. If the majority
of the differences between pt and pt-br can be summed up with simple
rules that a computer can handle, we might be able to work something
out. However, that's usually not the case; I don't know Portugese, but
I do know that handling even simple differences between en-us and
en-gb is too complex already: a system that would successfully convert
'realise' to 'realize' may also try to wrongfully convert 'disguise'.
> And before this I was also thinking of use (a possible enhanced
> version of) a procedure like this: considering that currently it is
> possible to show a system message using {{int:MESSAGE}} in the
> wikitext in a way that the result changes according to the user's
> language, would it be possible to create new messages at "MediaWiki:"
> Namespace just for defining language variants of words which usually
> appears at the content of the projects? For example, would it be
> possible to create "MediaWiki:WORD/pt-br" and "MediaWiki:WORD/pt", and
> use them (with {{int:WORD}}) instead of the actual word variant in
> wikitext? This isn't likely to be the better solution, but it could be
> a first step towards a solution...
>
This sounds like it could work, but only if the /langcode trick
actually works (I don't know what that depends on) and if there's a
relatively small set of words that makes a relatively big difference
(otherwise it'd be more trouble than it's worth IMO; but that's up to
the community).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SQL
2009/9/5 Helder Geovane Gomes de Lima : > But I don't know what to use in the SQL instead of the "WHAT?". > Does anybody knows what should it be? > You should probably use "ORDER BY page_namespace, page_title" there, which will sort by namespace, then by title. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any news to update static HTML Wikipedia?
2009/9/2 Gerard Meijssen : > Hoi, > Why do you say that it is proprietary and why do you state that there is a > GPL violation ? Making accusations like this without providing evidence is > not what I expect. [snip] > 2009/9/2 Manuel Schneider >> I want to add that Okawix uses code from the pre-ZIM GPL'ed ZenoReader and >> ZenoWriter which has been developed by the openZIM team before we started >> ZIM, but they changed it to be incompatible with Zeno and ZIM. >> Taking code from a GPLed project and putting it in a non-GPLed (or non-GPL-compatible) project is a violation of the GPL. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How we can speed up double brace substitution, Was: how to chang {{SITENAME}}
Duplicate thread of http://lists.wikimedia.org/pipermail/wikitech-l/2009-September/044984.html ? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Constant-folding magic words in messages (was: how to chang {{SITENAME}})
2009/9/1 Ilmari Karonen :
> Domas Mituzas wrote:
>>
>> Performance-wise it is even better, if all main messages which have
>> {{SITENAME}} get replacements with literals. Otherwise you're adding
>> up 5ms of page load time to each page. :)
>
> I'm not very familiar at all with the new LocalisationCache system, but
> it seems to me that it might be possible (and useful, from a performance
> viewpoint) to pre-substitute some essentially constant expressions
> (which only depend on things like configuration variables in
> LocalSettings) in advance when the cache is populated.
>
> I can think of at least the following magic words that probably could be
> so substituted:
>
> * {{SITENAME}}
> * {{CONTENTLANGUAGE}}, {{DIRMARK}}
> * {{SERVER}}, {{SERVERNAME}}, {{SCRIPTPATH}}
>
Magic words have cache expiry times defined in MagicWord.php (for
stuff like {{CURRENTDAY}}) ; we could simply honor them and let
messages containing other magic words such as these never expire.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
2009/9/1 Domas Mituzas :
> Enwiki will be really really sad by not have pagetitle constantly
> translated by translatewiki :)
That's not the point. If a message is customized by replacing
{{SITENAME}} with Wikipedia, updates to *that message* (not to the
site name) from TranslateWiki (or changes to the message in
MessagesEn.php , in the case of English) will not get through because
the local customization containing the old version overrides it.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
