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 2011

wikitech-l@lists.wikimedia.org
  • 119 participants
  • 99 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 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
About to commit improved DB2 database support
by Leons Petrazickis 21 Dec '11

21 Dec '11
I've been informally mentoring André, Tiago, Diego, and César. Theyare four students at Minho University who are currently working on aproject to improve DB2 database support in MediaWiki.So far, they've:- Fixed several outstanding issues with DB2 support involvingcharacter encoding, Windows vs Linux, etc- Added DB2 support to the new MediaWiki 1.17 Installer and Updater- Put in the appropriate Updater sql patches to reflect databaseschema changes since 1.14MediaWiki already had some DB2 support, but it's been broken since1.15 and never complete. As a result of their work, it's now possibleto successfully install MediaWiki on DB2 out of the box and to use thecore wiki features.I'll shortly commit their first patch using my SVN account (leonsp).I've taken some care to look over the code and make sure it abides bythe MediaWiki code guidelines.Regards,Leons Petrazickishttp://lpetr.org/blog/
7 9
0 0

29 Jul '11
(CC'd inez @ wikia)In the process of getting a better feel for the current state of Wikia,Wikihow, & a few others' rich text editor tools, I'm going through Wikia'sCKEditor-based RTE extension and seeing if I can get it working on MediaWikitrunk.I've got a fork from Wikia's SVN in this gitorious project:http://www.gitorious.org/mediawiki-wikia-rteThe 'master' branch is a straight git-svn clone of the subtree; 'tweaks'branch has some extra doc comments and some initial tweaks to get it loading(if not actually working right yet ;) on stock MediaWiki 1.18-SVN.Current state:* most stuff won't work yet!* the editor can be loaded if forced with &useeditor=wysiwyg* load/save results in some corruption, probably mostly due to the parserannotations not all being present (need to customize a few bits)* the editor is loaded through ResourceLoader, using a quick stub to workaround the lack of removal of certain lines* it's almost certain that the CSS and some JS is broken :D* there are various Wikia-specific PHP-side and JS-side extensions, many ofwhich still need to be switched to the stock MW equivalent or copied over.Note that definitions for such things can usually be found in the modifiedMediaWiki core in Wikia's SVN tree --https://svn.wikia-code.com/wikia/trunk/At a minimum I'd like to end up with something that works on stock MediaWiki1.18 (and if it can be made to work on stock or lightly-patched 1.17, evenbetter!). It should be a more stable option for 1.17 users than the oldFCKEditor extension.I'm still a bit leery of the internal annotations & edge-case checks for theround-tripping and whether this structure would work for us in the longterm, but there's some good stuff in here that's going to be useful to learnfrom whatever we do, and it's a useful tool for many cases in the shortterm.If anybody feels like trying it out / pitching in on the fixes, do feel freeto give a shout. I can set a few folks up with commit access on the git repoor take some pulls for now, and will merge it into our SVN extensions whenit's a bit more stable.-- brion vibber (brion @pobox.com / brion @wikimedia.org)
6 11
0 0
On Tue, May 31, 2011 at 10:35 AM, Neil Kandalgaonkar<neilk(a)wikimedia.org> wrote:> Are we all in deadlock or something? Are the users who can push waiting> from some proposals/work from the rest of the community?We had a hallway conversation about this just now (Neil, Trevor, Brionand I, and then just Brion and I), which I think was pretty useful.Here's where we went with it:1. We rehashed the pre-commit review proposal that Neil suggested afew months ago, and agreed that pre-commit would be helpful in keepingthe backlog down2. Given our current tools/process, we agreed that insisting onpre-commit review would be a pain in the butt.3. Brion and I further discussed review process, trying to come upwith a system that give us the benefits of pre-commit review, withoutactually switching to pre-commit reviewHere's where things I think got interesting. Brion pointed out thatin ye olden days, he was much more aggressive about reverting thingshe didn't understand. I pointed out that, as we broaden the pool ofcommitters, "I don't understand"-based reversions lead to a lot ofugliness, since very few people claim to have a broad understanding ofthe system and therefore an expectation of understanding every change. Most reviewers, faced with a commit they don't understand, will leaveit for others to comment on. There's been a lot of unnecessary dramaand churn over reversions because of misunderstandings about what areversion means.So, there's a number of possible solutions to this problem. These areindependent suggestions, but any of these might help:1. We say that a commit has some fixed window (e.g. 72 hours) to getreviewed, or else it is subject to automatic reversion. This willmotivate committers to make sure they have a reviewer lined up, andmake it clear that, if their code gets reverted, it's nothingpersonal...it's just our process.2. We encourage committers to identify who will be reviewing theircode as part of their commit comment. That way, we have an identifiedperson who has license to revert if they don't understand the code.I coulda swore there are other ideas that came out of thatconversation, but alas, I wasn't taking notes. Anyway, I'm surethey'll come up in this thread.Rob
21 55
0 0
Alternate/remote editor API?
by Brion Vibber 18 Jun '11

18 Jun '11
Neil spent some time yesterday hacking with the Hackpad guys (https://hackpad.com/ -- an Etherpad fork) experimenting with embedding thecollaborative editor via an <iframe> into MediaWiki's edit page in order touse it to do multiuser editing.Apparently it's pretty cool so far and I'm looking forward to seeing itstabilized! -- but more forward-looking we're tossing the idea around theoffice of having a common protocol for such editor embedding, which we canthen use for other things:* the contentEditable mode for WikiEditor* the Ace syntax-highlighter in CodeEditor gadget* experimental rich text editors etcSome of Neil & my initial notes:http://www.mediawiki.org/wiki/Future/Hackpad/SpecThe API between the host window and the (potentially offsite) iframe wouldneed to handle loading initial text, saving it, and some state checks at aminimum; depending on how much we want to integrate the WikiEditor's toolbarportion as a standard we may need to be able to let the toolbar controlthings like selection and text insertion, or each editor variant couldmanage its own toolbar and that could be a WikiEditor-specific protocolpart.Thoughts?-- brion
4 5
0 0
Mediawiki Development IDE
by Tod 12 Jun '11

12 Jun '11
Is there an IDE that the MW developer community has settled on and can recommend?tip-toeing softly away from the list....Thanks - Tod
11 13
0 0
Results per page:

[8]ページ先頭

©2009-2025 Movatter.jp