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-lMay 2013

wikitech-l@lists.wikimedia.org
  • 158 participants
  • 196 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
Hey,The new version of git-review released today (1.22) includes a patch Iwrote that makes it possible to work against a single 'origin' remote. Thisamounts to a workaround for git-review's tendency to frighten you intothinking you're about to submit more patches than the ones you are workingon. It makes git-review more pleasant to work with, in my opinion.To enable this behavior, you first need to upgrade to the latest version ofgit-review, by running "pip install -U git-review". Then you need to createa configuration file: either /etc/git-review/git-review.conf (system-wide)or ~/.config/git-review/git-review.conf (user-specific).The file should contain these two lines:[gerrit]defaultremote = originOnce you've made the change, any new Gerrit repos you clone using anauthenticated URI will just work.You'll need to perform an additional step to migrate existing repositories.In each repository, run the following commands: git remote set-url origin $(git config --get remote.gerrit.url) git remote rm gerrit git review -sHope you find this useful.
13 15
0 0
Can we help Tor users make legitimate edits?
by Sumana Harihareswara 28 Sep '13

28 Sep '13
TL;DR: A few ideas follow on how we could possibly help legit editorscontribute from behind Tor proxies. I am just conversant enough withthe security problems to make unworkable suggestions ;-), so pleasecorrect me, critique & suggest solutions, and perhaps volunteer to help.The current situation:https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor_to_bypass…We generally don't let anyone edit or upload from behind Tor; theTorBlock extension stops them. One exception: a person can create anaccount, accumulate lots of good edits, and then ask for an IP blockexemption, and then use that account to edit from behind Tor. This isunappealing because then there's still a bunch of in-the-clear editingthat has to happen first, and because then site functionaries know thatthe account is going to be making controversial edits (and couldpossibly connect it to IPs in the future, right?). And right nowthere's no way to truly *anonymously* contribute from behind Torproxies; you have to log in. However, since JavaScript delivery is hardfor Tor users, I'm not sure how much editing from Tor -- vandalism orlegit -- is actually happening. (I hope for analytics on this and thusadded it tohttps://www.mediawiki.org/wiki/Analytics/Dreams .) We knowat least that there are legitimate editors who would prefer to use Torand can't.People have been talking about how to improve the situation for sometime -- seehttp://cryptome.info/wiki-no-tor.htm andhttps://lists.torproject.org/pipermail/tor-dev/2012-October/004116.html. It'd be nice if it could actually move forward.I've floated this problem past Tor and privacy people, and here are afew ideas:1) Just use the existing mechanisms more leniently. Encourage thecommunities (Wikimedia & Tor) to usehttps://en.wikipedia.org/wiki/Wikipedia:Request_an_account (to get anaccount from behind Tor) and to let more people get IP block exemptionseven before they've made any edits (< 30 people have gotten exemptionson en.wp in 2012). Add encouraging "get an exempt account" language tothe "you're blocked because you're using Tor" messaging. Then ifthere's an uptick in vandalism from Tor then they can just tighten up again.2) Encourage people with closed proxies to re-vitalizehttps://en.wikipedia.org/wiki/Wikipedia:WOCP . Problem: using closedproxies is okay for people with some threat models but not others.3) Look at Nymble -http://freehaven.net/anonbib/#oakland11-formalizingandhttp://cgi.soic.indiana.edu/~kapadia/nymble/overview.php . It wouldallow Wikimedia to distance itself from knowing people's identities, butstill allow admins to revoke permissions if people acted up. The usershows a real identity, gets a token, and exchanges that token over torfor an account. If the user abuses the site, Wikimedia site admins canblacklist the user without ever being able to learn who they were orwhat other edits they did. More:https://cs.uwaterloo.ca/~iang/ IanGolberg's, Nick Hopper's, and Apu Kapadia's groups are all working onNymble or its derivatives. It's not ready for production yet, I bet,but if someone wanted a Big Project....3a) A token authorization system (perhaps a MediaWiki extension) wherethe server blindly signs a token, and then the user can use that tokento bypass the Tor blocks. (Tyler mentioned he saw this somewhere in aBugzilla suggestion; I haven't found it.)4) Allow more users the IP block exemption, possibly even automaticallyafter a certain number of unreverted edits, but with some kind ofFlaggedRevs integration; Tor users can edit but their changes have to bereviewed before going live. We could combine this with (3); Nymbleadministrators or token-issuers could pledge to review edits coming fromTor. But that latter idea sounds like a lot of social infrastructure toset up and maintain.Thoughts? Are any of you interested in working on this problem? #tor onthe OFTC IRC server is full of people who'd be interested in talkingabout this.-- Sumana HarihareswaraEngineering Community ManagerWikimedia Foundation
16 25
0 0
Making inter-language links shorter
by Pau Giner 04 Sep '13

04 Sep '13
As multilingual content grows, interlanguage links become longer onWikipedia articles. Articles such as "Barak Obama" or "Sun" have more than200 links, and that becomes a problem for users that often switch amongseveral languages.As part of the future plans for the Universal Language Selector, we wereconsidering to: - Show only a short list of the relevant languages for the user based on geo-IP, previous choices and browser settings of the current user. The language the users are looking for will be there most of the times. - Include a "more" option to access the rest of the languages for which the content exists with an indicator of the number of languages. - Provide a list of the rest of the languages that users can easily scan (grouped by script and region ao that alphabetical ordering is possible), and search (allowing users to search a language name in another language, using ISO codes or even making typos).I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> toillustrate the idea. Since this is not connected to the MediaWiki backend,it lacks the advanced capabilities commented above but you can get the idea.If you are interested in the missing parts, you can check the flexiblesearch and the list of likely languages ("common languages" section) on thelanguage selector used athttp://translatewiki.net/ which is connected toMediaWiki backend.As part of the testing process for the ULS language settings, I included atask to test also the compact interlanguage designs. Users seem tounderstand their use (viewrecording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),but I wanted to get some feedback for changes affecting such an importantelement.Please let me know if you see any possible concern with this approach.Thanks-- Pau GinerInteraction DesignerWikimedia Foundation
9 16
0 0

03 Aug '13
All,The developer team at Wikimedia is making some changes to how accountswork, as part of our on-going efforts to provide new and better toolsfor our users (like cross-wiki notifications). These changes will meanusers have the same account name everywhere, will let us give you newfeatures that will help you edit & discuss better, and will allow moreflexible user permissions for tools. One of the pre-conditions forthis is that user accounts will now have to be unique across all 900Wikimedia wikis.[0]Unfortunately, some accounts are currently not unique across all ourwikis, but instead clash with other users who have the same accountname. To make sure that all of these users can use Wikimedia's wikisin future, we will be renaming a number of accounts to have "~” andthe name of their wiki added to the end of their accounts' name. Thischange will take place on or around 27 May. For example, a user called“Example” on the Swedish Wiktionary who will be renamed would become“Example~svwiktionary”.All accounts will still work as before, and will continue to becredited for all their edits made so far. However, users with renamedaccounts (whom we will be contacting individually) will have to usethe new account name when they log in.It will now only be possible for accounts to be renamed globally; theRenameUser tool will no longer work on a local basis - since allaccounts must be globally unique - therefore it will be withdrawn frombureaucrats' tool sets. It will still be possible for users to ask onMeta for their account to be renamed further, if they do not liketheir new user name, once this takes place.A copy of this note is posted to meta [1] for translation. Pleaseforward this to your local communities, and help get it translated.Individuals who are affected will be notified via talk page and e-mailnotices nearer the time.[0] -https://meta.wikimedia.org/wiki/Help:Unified_login[1] -https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcementYours,--James D. ForresterProduct Manager, VisualEditorWikimedia Foundation, Inc.jforrester(a)wikimedia.org | @jdforrester
3 6
0 0
Quo Vadis, Vagrant
by Ori Livneh 12 Jul '13

12 Jul '13
I'm writing to report on progress with Mediawiki-Vagrant, and to tellyou a bit about how it could be useful to you. If you've looked atMediaWiki-Vagrant in the past and thought, 'big deal -- I know how toconfigure MediaWiki', this e-mail is for you.But first, a small snippet to whet your appetite: # == Class: role::mobilefrontend # Configures MobileFrontend, the MediaWiki extension which powers # Wikimedia mobile sites. class role::mobilefrontend { include role::mediawiki include role::eventlogging mediawiki::extension { 'MobileFrontend': settings => { wgMFForceSecureLogin => false, wgMFLogEvents => true, } } }MW-V has evolved to become a highly organized and consistent Puppetcode base for describing MediaWiki development environments. Puppet,you'll recall, is the same configuration management and softwareautomation tool that TechOps uses to run the cluster. Puppet providesa domain-specific language for articulating software configuration ina declarative way. You tell Puppet what resources are configured onyour machine and what relationships inhere among them, and Puppettakes your description and executes it.MW-V uses Puppet to automate the configuration of MediaWiki & relatedbits of software. But MW-V goes a bit further, too: it exploits theflexibility of Puppet's syntax and semantics to give MediaWikidevelopers a set of affordances for describing their own developmentsetup. The description takes the concrete form of a Puppet 'role'.These can be submitted as patches against the MW-V repo and thusshared with others. The combination of Vagrant / Puppet / VirtualBoxmake it quite easy to select and swap machine roles.Roles can be toggled by adding or removing a line, 'includerole::<name>', from puppet/manifests/site.pp. The current set of rolesare listed here:https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/vagrant.git;a=blob;f=pupp…They include a VisualEditor role that is powered by a local Parsoidinstance, and roles for Selenium testing, Echo, MobileFrontend,GettingStarted, and EventLogging.If you're interested in checking it out:0. Delete any old instances.1. Download & install VirtualBox:https://www.virtualbox.org/wiki/Downloads2. Download & instal Vagrant:http://downloads.vagrantup.com/tags/v1.2.23. git clonehttps://gerrit.wikimedia.org/r/p/mediawiki/vagrant.git4. Edit puppet/manifests/site.pp and uncomment the role you want to check out.5. Run 'vagrant up' from the repository's root directory.Finally: wait! The first run takes an obnoxiously long time (15-20minutes). Subsequent runs are much faster (~5 seconds if there are nomajor configuration changes.)The documentation onMediaWiki.org is still meager, but it isconcentrated here:http://www.mediawiki.org/wiki/Mediawiki-VagrantIf you're interested in using MW-V to document and automate yourdevelopment setup, get in touch -- I'd be happy to help. I'm 'ori-l'on IRC, and I'll be at the Amsterdam Hackathon later this month too.Finally, if you're interested in how this relates to Labs (shortanswer: the use-cases are largely complementary), Andrew Bogott and Ihave an open submission for a Wikimania talk on this subject:https://wikimania2013.wikimedia.org/wiki/Submissions/Turnkey_Mediawiki_Test…
5 11
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp