Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Wikitech-lMarch 2012

wikitech-l@lists.wikimedia.org
  • 155 participants
  • 204 discussions
Start a nNew thread
Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25
Until some weeks agohttp://dumps.wikimedia.org/backup-index.html usedto show 4 dumps in progress at the same time. That meant that newdatabase dumps normally was available within about 3 weeks for alldatabases except for enwiki and maybe dewiki where the dump process dueto size took longer time.However the 4 dumps processes at one time become 3 some weeks ago. Andafter massive failures at June 4, only one dump has been in progress atthe same time. So at the current speed it will take several months tocome thru all dumps.Is it possible to speed up the process again using several dumpprocesses at the same time?Thank you,Byrial
3 2
0 0
User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25
Hi!from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites.Domas
19 61
0 0
EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25
What's the status of the project to create a grammar for Wikitext in EBNF?There are two pages:http://meta.wikimedia.org/wiki/Wikitext_Metasyntaxhttp://www.mediawiki.org/wiki/Markup_specNothing seems to have happened since January this year. Also the comments onthe latter page seem to indicate a lack of clear goal: is this just a funproject, is it to improve the existing parser, or is it to facilititate anew parser? It's obviously a lot of work, so it needs to be of clearbenefit.Brion requested the grammar IIRC (and there's a comment to that effect athttp://bugzilla.wikimedia.org/show_bug.cgi?id=7), so I'm wondering what became of it.Is there still a goal of replacing the parser? Or is there some alternativeplan?Steve
26 217
0 0
Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24
Hello,I have been a WP editor since 2006. I hope you can help me. For some reasonI no longer have Section Heading titles showing in the Articles. This istrue of all Headings including the one that carries the Article subject'sname. When there is a Table of Contents, it appears fine and, when I clickon a particular Section, it goes to that Section, but all that is there is astraight line separating the Sections. There is also no button to edit aSection. If I edit the page and remove the "== ==" markers from the SectionTitles, the Title then shows up, but not as a Section Heading. Also, I don'thave any Date separators on my Want List. This started 2 days ago. Anythoughts?Thanks,Marc Riddell[[User:Michael David]]
10 11
0 0
MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14
I'm happy to announce the availability of the second beta release of thenew MediaWiki 1.19 release series.Please try it out and let us know what you think. Don't run it on anywikis that you really care about, unless you are both very brave andvery confident in your MediaWiki administration skills.MediaWiki 1.19 is a large release that contains many new features andbug fixes. This is a summary of the major changes of interest to users.You can consult the RELEASE-NOTES-1.19 file for the full list of changesin this version.Five security issues were discovered.It was discovered that the api had a cross-site request forgery (CSRF)vulnerability in the block/unblock modules. It was possible for a useraccount with the block privileges to block or unblock another user withoutproviding a token.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=34212It was discovered that the resource loader can leak certain kinds of privatedata across domain origin boundaries, by providing the data as an executableJavaScript file. In MediaWiki 1.18 and later, this includes the leaking ofCSRFprotection tokens. This allows compromise of the wiki's user accounts, saybychanging the user's email address and then requesting a password reset.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=34907Jan Schejbal ofHatforce.com discovered a cross-site request forgery (CSRF)vulnerability in Special:Upload. Modern browsers (since at least as early asDecember 2010) are able to post file uploads without user interaction,violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead tofurthercompromise, especially on private wikis where the set of allowed file typesisbroader than on public wikis. Note that CSRF allows compromise of a wikifroman external website even if the wiki is behind a firewall.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35317George Argyros and Aggelos Kiayias reported that the method used to generatepassword reset tokens is not sufficiently secure. Instead we use variousmoresecure random number generators, depending on what is available on theplatform. Windows users are strongly advised to install either the opensslextension or the mcrypt extension for PHP so that MediaWiki can takeadvantageof the cryptographic random number facility provided by Windows.Any extension developers using mt_rand() to generate random numbers incontextswhere security is required are encouraged to instead make use of theMWCryptRand class introduced with this release.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35078A long-standing bug in the wikitext parser (bug 22555) was discovered tohavesecurity implications. In the presence of the popular CharInsert extension,itleads to cross-site scripting (XSS). XSS may be possible with otherextensionsor perhaps even the MediaWiki core alone, although this is not confirmed atthis time. A denial-of-service attack (infinite loop) is also possibleregardless of configuration.For more details, seehttps://bugzilla.wikimedia.org/show_bug.cgi?id=35315********************************************************************* What's new?*********************************************************************MediaWiki 1.19 brings the usual host of various bugfixes and new features.Comprehensive list of what's new is in the release notes.* Bumped MySQL version requirement to 5.0.2.* Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work.* New skins/common/*.css files usable by skins instead of having to copypiles of generic styles from MonoBook or Vector's css.* The default user signature now contains a talk link in addition to theuser link.* Searching blocked usernames in block log is now clearer.* Better timezone recognition in user preferences.* Extensions can now participate in the extraction of titles from URL paths.* The command-line installer supports various RDBMSes better.* The interwiki links table can now be accessed also when the interwikicache is used (used in the API and the Interwiki extension).Internationalization- --------------------* More gender support (for instance in user lists).* Add languages: Canadian English.* Language converter improved, e.g. it now works depending on the page content language.* Time and number-formatting magic words also now depend on the page content language.* Bidirectional support further improved after 1.18.Release notes- -------------Full release notes:https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RELEASE-NOTES-1.19;hb=1.19.0beta2https://www.mediawiki.org/wiki/Release_notes/1.19Co-inciding with these security releases, the MediaWiki source coderepository hasmoved from SVN (athttps://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So therelevantcommits for these releases will not be appearing in our SVN repository. Ifyou useSVN checkouts of MediaWiki for version control, you need to migrate these toGit.If you up are using tarballs, there should be no change in the process foryou.Please note that any WMF-deployed extensions have also been migrated to Gitalso, along with some other non WMF-maintained ones.Please bear with us, some of the Git related links for this release may notwork instantly,but should later on.To do a simple Git clone, the command is:git clonehttps://gerrit.wikimedia.org/r/p/mediawiki/core.gitMore information is available athttps://www.mediawiki.org/wiki/GitFor more help, please visit the #mediawiki IRC channel onfreenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing listat mediawiki-l(a)lists.wikimedia.org.**********************************************************************Download:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gzPatch to previous version (1.19.0beta1), without interface text:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gzInterface text changes:http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patch.gzGPG signatures:http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patch.gz.sigPublic keys:https://secure.wikimedia.org/keys.html
5 5
0 0
MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12
Hi everyone,I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent.I would prefer a script written in Python, but any recommendations would be very welcome.Do you know of anything suitable?Kind Regards,Hugo Vincent,Bluewater Systems.
6 13
0 0
Database dump of Bugzilla
by John Du Hart 21 May '12

21 May '12
I'm currently investigating alternative bug tracker and project managementsoftware for MediaWiki. To do that I'll be installing some differentsoftware on the Labs and importing existing bugs for evaluation by thedevelopment team and users. The following software is planned for test: - JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire - YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/>If you have any suggestions for this list I'd be glad to hear it.Of course, this goes back to the original request. To do this I need a dumpof the current Bugzilla install. Is it possible for me to get this andunder what conditions? Thank you.-- John
18 43
0 0
Report on WebFonts deployment
by Siebrand Mazeland (WMF) 08 May '12

08 May '12
Dear all,My apologies up front for the long e-mail that follows. In this e-mail youwill find a comprehensive status overview of the recent WebFonts deployment.On Monday December 12 at 18:00 UTC we deployed the extension WebFonts[1] to40 wikis in 11 Indic languages and Wikimedia Incubator -- all wikis inAssamese, Bengali, Gujarati, Hindi, Kannada, Marathi, Nepali, Oriya,(Eastern) Punjabi, Sankrit and Telugu have WebFonts now. WebFonts was notdeployed on Malayalam and Tamil projects. The reason for this was thatcommunity members had requested us not to. We are confident that in time,the communities will request that WebFonts is enabled on their projects.WebFonts aims to resolve the issue that users see incomplete web pages,because the fonts to properly render the page is not present in the localsystem by downloading the font through the browser.One of our great challenges developing this functionality is the multitudeof scripts and the low availability of freely licensed fonts that may bemodified and redistributed.Over the past few months we have tried to build out a collection of fontsin the extension mainly for Indic languages, and we have performed manytests. We have solicited community involvement through messaging in villagepumps, e-mails on mailing lists, blog posts on personal blogs as well as onthe Wikimedia Foundation blog, at developer events, through personale-mails and through our bug tracker, and gotten some feedback, althoughunfortunately not for all the languages we would like to have gotten itfor. We will of course continue our efforts in this area. Next to thecommunity involvement, we have had a two day session with the Red HatLocalisation team in Pune, India.Since the deployment, we have been criticised for not communicating enough-- or not through the right channels, not with the right people, not intime, or too soon, or not with the right messages. I'm not really sure howto respond to that, except for uttering a general "mea culpa, mea maximaculpa". We are working really hard in continuously improving the work thatwe do, and the way that we do it. We make mistakes, we are human after all,and when we become aware of our mistakes, we will do everything in ourpower to make it better.With our team we support the mission of the Wikimedia Foundation to"imagine a world in which every single human being can freely share in thesum of all knowledge." I care about that -- a lot. We all care, and I ampretty certain that we're not ignorant, dismissive or incapable. Iacknowledge that we as the Localisation team are a relatively new entitywithin the MediaWiki development community and within the WikimediaFoundation, with a very wide scope, and that we are dealing with a lot oftechnical details on which we are simply not able to assess the finalquality; there are after all 7.500 languages in this world of over 7billion people that we theoretically all cover, some 350 of those languagesare supported in MediaWiki, and 280 within Wikimedia.I accept that we cannot keep everybody happy -- doesn't keep us fromtrying, though. I want to try and work with as many people as possible in aconstructive way. With these numbers, that's not always easy to coordinate.To channel the input on languages, we have set up "Language SupportTeams"[2]. We do not yet have a language support team for every language.Please sign up if you care about the technical facilitation of yourlanguage in the Wikimedia movement. Let's use the mediawiki-i18n mailinglist[3] to have constructive discussions about language support. Let's usethe #mediawiki-i18n IRC channel[4] on Freenode to have real-timediscussions. Let's usebugzilla.wikimedia.org to report bugs[5]. Link [5]explains the bug reporting procedure. If you already know how, reportissues quickly using this link:http://ur1.ca/6ov9a .Since the deployment, we have been made aware of about 17 issues. Some veryserious in nature, others not requiring immediate attention. Yesterday anissue with web fonts not loading in Firefox was resolved in theinfrastructure. Today around 15:30 UTC, we have deployed fixes for anadditional hand full of issues[6]: functionality disabled in IE6, IE8 onWindows XP, selection buttons not working properly in IE7 and hiding theSamyak fonts in the font selector. During our current sprint, we areworking on a framework for multi-lingual and localised user documentationas well as feature based feedback functionality for WebFonts, Narayam andTranslate. In the future we will also explore what is known as "darklaunch" by some, a kind of hidden live deployment of a feature, only usablebe for example manipulating a URL. This would allow us to deploy a featurein a live environment, without having the "full deployment" impact.Thanks for reading through this. I am looking forward to working with you!Please read on for details on all the issues that were reported on WebFontsrecently.Cheers!Siebrand MazelandProduct Manager LocalisationWikimedia Foundation======================================= Links=======================================[1]https://www.mediawiki.org/wiki/Extension:WebFonts[2]https://translatewiki.net/wiki/Language_support_team[3]https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n[4]https://translatewiki.net/wiki/Special:WebChat[5]https://www.mediawiki.org/wiki/Bugzilla[6]https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106204======================================= Open issues=======================================https://bugzilla.wikimedia.org/33004 -- Old cached pages do not have webfonts enabledPriority: HIGH--------------------------------------------------------------------------------------Wikimedia is able to serve this many pages with relative few serversbecause of very aggressive caching strategies, especially for anonymoususers. WebFonts requires the addition of JavaScript for anonymous users,which is not being done for pages that are in the squid cache at the momentWebFonts was enabled. All squid cache objects for wikis on which WebFontswas deployed need to be purged. An internal RT ticket created for theWikimedia Operations team to get anonymous squid caches purged. This maytake up to a week or longer to be resolved.https://bugzilla.wikimedia.org/33018 -- Firefox 5 on Windows XP has scripttime-outsPriority: MEDIUM--------------------------------------------------------------------------------------The Localisation team has tested this report, and was not yet able toconfirm the observation. The reason for using a non-recent version ofFirefox for the report was the alleged lower memory usage. Brion noted thatMozilla has been actively working on lowering memory usage over the lastyear, so the reporter may be better off with the current versions than theold ones.https://bugzilla.wikimedia.org/33110 -- Google Crome on Windows XP dispaysgibberishPriority: LOW--------------------------------------------------------------------------------------Observed very rarely on a page on Wikimedia Incubator, and we have not beenable to reproduce this observation, let alone reproduce it reliably. Ascreenshot is present in the bug report. Except for reporting upstream, noaction is being taken on this issue at this point in time.https://bugzilla.wikimedia.org/33054 -- Hinting issues in Lohit fontsPriority: MEDIUM--------------------------------------------------------------------------------------Confirmed in Windows XP. We can do something to the font by adding hinting,but this is a lot of work if it needs to be done manually. The stem of theLohit glyphs could do with more width and darkness. This may not bedesirable for platforms (Linux) which render it perfectly, because italready has hinting and anti-aliasing on an operating system level. Samegoes got Windows 7.https://bugzilla.wikimedia.org/33100 -- Page crashes on Webkit browserswith WebFonts enabled.Priority: MEDIUM (could be HIGH if we find many occurances)--------------------------------------------------------------------------------------A page in Nepali Wikipedia makes a tab on Mac OS X 10.7.2 with Google Cromecrash. This behaviour was also reported for Mac OS X 10.7.2 (11C74) withSafari 5.1.1 (7534.51.22, r102522) [This is a webkit nightly build] bythedj. This is most probably related to the WebFonts code, because if, as alogged in user, web fonts is disabled in preferences, the page does notcrash Chrome.Developer Derk-Jan Hartman was asked to report this bug in the WebKit.Please make us aware of any additional pages that would cause thisbehaviour in any wiki.https://bugzilla.wikimedia.org/33102 -- OSX 10.7.2/Opera 11.60 has nofallback for Latin charactersPriority: MEDIUM--------------------------------------------------------------------------------------This is a bug that needs to be reported upstream. No technical measureshave been taken so far to mitigate this issue. One of the Localisation teammembers has been in contact with a high level executive of Opera, and willcontact that person again. We're going to wait for a few days for anoutcome -- if there is no expectation of a relatively quick fix, we mightdisable WebFonts for Opera completely. Opera unfortunately does not have apublic bug tracker.https://bugzilla.wikimedia.org/33027 -- Narayam and WebFonts both loadingslows down pagePriority: MEDIUM--------------------------------------------------------------------------------------The reporter claims that the functionality is quicker ontranslatewiki.netthan it is in Wikimedia wikis. A commenter statesthat more functionalityusually means more code, means more data that needs to be transferred, andwithout changing bandwidth, that causes longer load times.This currently isn't our highest priority, but eventually we will look intothis a little deeper. We're inviting volunteers to do some of the datagathering and analysis for us. What is needed in our opinion is insight inthe data volume added by WebFonts, as well as an assessment of the codequality with regards to size optimisation. All referenced properly, ofcourse :). There are alternate EOT conversion tools that have a goodcompression ratio. Needs to be explored, but EOT is not required for modernbrowsers since they started using WOFF fonts which are compressed OpenTypefonts.https://bugzilla.wikimedia.org/33085 -- Integration of updated Lohit-TamilFontPriority: MEDIUM--------------------------------------------------------------------------------------Request to update WebFonts with a font that is updated upstream. This issomething the Localisation team checks regularly. Will probably be closedthis week, pending issues the have a higher priority.https://bugzilla.wikimedia.org/32942 -- Provide help page and bug reportlink for WebFontsPriority: HIGH--------------------------------------------------------------------------------------More recently developed tools by the Wikimedia Foundation have oftenincluded feedback mechanisms. The Localisation team plans on implementingthese for the functionality of the WebFonts, Narayam and Translateextension. Besides that, we also want to provide multi-lingual andlocalised documentation. This needs some thinking and some work to providein a structured and navigable way. We'll keep you posted. It will mostprobably involve translatable *user* documentation onMediaWiki.org andhopefully it is possible to have one feedback location per feature acrossthe multiple Wikimedia wikis -- this is something we're going to contactthe ArticleFeedback and MoodBar teams for.======================================= Closed issues=======================================https://bugzilla.wikimedia.org/33025 -- When changing to a non-default webfont, the content does not--------------------------------------------------------------------------------------This issue was a side effect of a feature to allow multiple web fonts to beused using the "lang" attribute. It was resolved inhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/105980 and has beendeployed.https://bugzilla.wikimedia.org/33034 -- Web fonts not loading in Firefox--------------------------------------------------------------------------------------Duplicate reports were 33038 and 33044. This issue originated fromhttp://www.w3.org/TR/css3-fonts/#same-origin-restriction. Almost allbrowsers except for Firefox ignore that specification. A fix was designedand deployed:https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106092,https://gerrit.wikimedia.org/r/1501. Thanks to Roan, Brion and Ryan fortheir help.https://bugzilla.wikimedia.org/32775 -- Gibberish in Internet Explorer 8 onWindows XP--------------------------------------------------------------------------------------This is an unexplained phenomenon only observed in Internet Explorer onWindows XP. It is also hard to reproduce. One of the developers was able tomake something somewhat reproducible on a clean, fully patched installationof Windows XP with Internet Explorer 8. See bug report for details.Based on these observations we think it is a bad idea to keep supportingWebFonts in Internet Explorer 8 on Windows XP and we have disabled it inhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix hasbeen deployed.https://bugzilla.wikimedia.org/33096 -- Internet Explorer 6 does not havefont fallback--------------------------------------------------------------------------------------IE6 not having font fallback causes Latin characters to display as squareswhen a web font is loaded that does not contain glyphs for the Latinscript. A screenshot is available athttp://media.crossbrowsertesting.com/users/34057/screenshots/window/z669002….Based on this observation, we think it is a bad idea to keep supportingWebFonts in Internet Explorer 6 and we have disabled it inhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix hasbeen deployed.https://bugzilla.wikimedia.org/33024 -- WebFonts menu buttons not workingin IE7--------------------------------------------------------------------------------------This was caused by the JavaScript $( '<input type="radio" />' ) . attr("name" ,"font"); not working in IE6 and IE7. Updating name attributes oncethey have been created is not possible. We think there may be moreoccurances of this in our code (one occurance in jQuery has already beenidentified: resources/jquery/jquery.validate.js:59). A fix was made inhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/106175. This fix hasbeen deployed.https://bugzilla.wikimedia.org/33040 -- Overlap in Samyak font for Hindiand Sanskrit--------------------------------------------------------------------------------------This issue occurs in Windows XP and Windows 7 (possibly also in WindowsVista) when using Google Chrome. It is not observed when using Chrome withMac OS X 10.7.2 or several Linux distributions (Debian and Fedora). SamyakDevanagari is available as a non-default web font in Hindi, Marathi, andSanskrit. Samyak Gujarati is available for Gujarati as a non-default font.This font needs to be corrected. The maintainers will be notified of theobserved issues, and mean while, the fonts will be removed from theWebFonts selection list (but can still be used using the font-familyproperty. A fix was made inhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/106179. This fix hasbeen deployed.https://bugzilla.wikimedia.org/33039 -- Overlap in Madan font for Nepali--------------------------------------------------------------------------------------This report was invalid. The reporter was not aware of the correct glyphfor the Nepali script.Comments on this bug report resulted in two odd observations (Crome crash,Opera font fallback), that have been split off into separate bug reports:https://bugzilla.wikimedia.org/33100 andhttps://bugzilla.wikimedia.org/33102.https://bugzilla.wikimedia.org/33095 -- WebFonts menu can expand off thescreen--------------------------------------------------------------------------------------If the translations for "Select font" and "Login / Register" are reallyshort, like inhttp://mr.wiktionary.org, expanding the WebFonts menu foranonymous users will display a menu that is partially off the screen. Itwas resolved inhttp://www.mediawiki.org/wiki/Special:Code/MediaWiki/106186,http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106197,http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106201,http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106202. Theserevisions also depend on a few small UI changes of both WebFonts andNarayam, and will be deployed on December 19, 2011.<no bugzilla report> -- WebFonts menu expands under the control forcustomised input method in IE6 on transliteration--------------------------------------------------------------------------------------There are issues with the z index in IE6. Because ofhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172, WebFonts isno longer available in IE6, so this issue is obsolete. Observing that theHindi projects Wikipedia and Wiktionary are using an custom input methodstool, we would like to invite them to test Narayam which contains manyinput methods in a MediaWiki extension. We are very open to having theHindi input method InScript tested and add a transliteration input methodwith some community representatives, as we have done with other Indiclanguages. We hope this will eventually lead to Narayam being adopted bythe Hindi community, and the custom input method being abandoned.
13 15
0 0
OAuth
by Petr Bena 30 Apr '12

30 Apr '12
Hi, it's been almost 4 years since we came with the idea ofimplementing an OAuth to mediawiki. I think it's time to start.Question now is if it should be a part of core or extension formediawiki. I myself would rather make it as extension, since there isprobably no use for most of installations, except for large wikis.Quote:OAuth provides a standard protocol to negotiate secure access tokensand to provide third-party tools (web or client) with granular accessto private resources. This protocol does not reveal usernames orpasswords to the third-party tool. Offering OAuth based authorizationon Mediawiki wiki's will increase the reusability of its data and spurthe creation of an ecosystem of app's around Mediawiki.Is there anyone who is willing to help with this? If there is no oneinterested in this, or no comments, I would start a new extensioncalled OAuth, which only purpose would be to enable this feature inmediawiki.
12 27
0 0
Cutting MediaWiki loose from wikitext
by Daniel Kinzler 30 Apr '12

30 Apr '12
Hi all. I have a bold proposal (read: evil plan).To put it briefly: I want to remove the assumption that MediaWiki pages containalways wikitext. Instead, I propose a pluggable handler system for differenttypes of content, similar to what we have for file uploads. So, I propose toassociate a "content model" identifier with each page, and have handlers foreach model that provide serialization, rendering, an editor, etc.The background is that the Wikidata project needs a way to store structured data(JSON) on wiki pages instead of wikitext. Having a pluggable system would solvethat problem along with several others, like doing away with the special casesfor JS/CSS, the ability to maintain categories etc separate from body text,manage Gadgets sanely on a wiki page, or several other things (see the link below).I have described my plans in more detail on meta:http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandlerA very rough prototype is in a dev branch here:http://svn.wikimedia.org/svnroot/mediawiki/branches/Wikidata/phase3/Please let me know what you think (here on the list, preferably, not on the talkpage there, at least for now).Note that we *definitely* need this ability for Wikidata. We could do itdifferently, but I think this would be the cleanest solution, and would have alot of mid- and long term benefits, even if it's a short term pain. I'mpresenting my plan here to find out if I'm on the right track, and whether it isfeasible to put this on the road map for 1.20. It would be my (and the Wikidatateam's) priority to implement this and see it through before Wikimania. I'mconvinced we have the manpower to get it done.Cheers,Daniel
8 16
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp