So instead of having a script that just has to run basic unix commands in
order to manage vhosts you now need something to parse an http.conf file.
I'm pretty sure I know what I'd choose.
On Nov 20, 2011 1:25 AM, "Dmitriy Sintsov" <questpc(a)rambler.ru> wrote:
On 19.11.2011 22:59, Happy Melon wrote:
> "Better" here is clearly in the eye of the beholder. The ...
My method does not require creation of symlinks and numeric prefixes,
that's why it's better. Ancient languages used numeric labels for lines
of code. Cut / paste of single text line is faster than renaming
symlinks. Commenting line with # is better as well. These points are
objective, not subjective. I would stop talking about that yesterday if
you weren't insisting that it's a personal preference (it's not).
Dmitriy
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia...
The three processes we had going for "largish" wikis had been restarted
from a particilar step, since I had to interrupt them earlier for kernel
upgrade and reboot. These stop at the end of the run. Three regular
jobs are now running; these cycle through the list of the ten largish
wikis in the usual way.
While we're on the subject of de wiki, I have been considering starting
to produce smaller output files much as we do for en wikipedia. 100GB
is pretty large for someone to download and process, and it takes a
while to produce as well. Any thoughts? CC-ing wikitech-l since some
people on that list may be users of the dump that don't subscribe to
xmldatadumps-l (but they should!)
Ariel
Στις 19-11-2011, ημέρα Σαβ, και ώρα 18:03 +0100, ο/η Andreas Meier
έγραψε:
> Hello,
> today we ja-dump was finished, so a new de-dump should start.
>
> Best regards
> Andreas
I had an idea for a feature to allow any language user to go to any other
language wiki and be able to use the namespaces they recognize.
The idea would be that a user from it.wp could go to fr.wp and when
visiting Utente:... (Utente is User in Italian) whether via search or
direct address linking and end up on Utilisateur:... (French's User
namespace)
This would be done by considering every possible localization of a
namespace as an alias in all languages. So on fr.wp Utente, User, etc...
would all be aliases for Utilisateur. Additionally since namespaces are
dependent on the user rather than the content for logged in users we could
start displaying localized namespace names to help the user around and not
have to worry about issues that if they copy&paste or whatever it wouldn't
be valid.
We've got a massive localization cache, and it's possible we might find a
way to make a feature like this possible, so that wasn't an issue to stop
this idea. But there was a slim possibility that words used for namespaces
might conflict with what other languages use. That sounded so unlikely
that I wrote a script to scan every language we have for all available
namespace names and what they map to and see if the same text is used for
different namespaces in any languages.
And the dooming news, there are some conflicts.
"Stampa" is NS_TEMPLATE in Aln (Gheg Albanian) and Sq (Albanian) and
NS_FILE in Mt (Maltese). And Datoteka is NS_FILE in Bs (Bosnian), Hr
(Croatian), and Sh (Serbocroatian), but NS_MEDIA in Sl (Slovenian).
So our only options are (probably in order of simplicity/likelihood first
;) ):
A) Drop this feature idea.
B) Find a way to deal with collisions and accept there may be some bugs an
confusing behavior for users.
C) Implement this while making use of lots of language heuristics like
Accepts-Language, Geolocation, and other things that will hurt caching.
D.a) Drop support for either Maltese or Albanian languages and Slovenian
or Croatian languages.
D.b) Convince everyone who speaks these languages to use a different word.
D.c) Commit genocide and wipe those languages off the face of the earth
and erase them from the history books.
E) Implement a brain-neural interface and require use of it while browsing
Wikipedia so that we can extract what the user 'actually' means and
understands directly from their mind.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
> Hi everyone,
>
> I just posted a
> note<http://blog.wikimedia.org/2011/11/18/nobody-notices-when-its-not-broken-new…>on
> the blog about our new external store but wanted to add a few details
> here. The deploy went smoothly, and I'm very happy with how the project
> progressed overall. There are plenty more details on the project itself on
> the project wiki
> page<http://wikitech.wikimedia.org/view/External_storage/Update_2011-08>and
> hiding in RT. there were a few followup things to come out of it, and
> I want to talk through those in hopes that someone either picks them up or
> has suggestions on what to do.
>
>From what I've read on the blog, that sounds like a "Good Work
everyone" is in order :)
>
> During the deploy there was a brief (about 10 minute) period during which
> article saves failed due to the external store databases being in read-only
> mode. As expected, some folks showed up in IRC telling us of the
> 'problem'. After the migration was complete we brainstormed a bit in IRC
> about good ways of informing editors of planned maintenance such as this
> migration. The regular databases (s3, etc.) have a read-only mode flag so
> that the affected wikis show a reasonable error, but the external store
> databases are a little different. Because of the way they're spread out,
> the outage of a specific database cluster does not affect specific language
> projects, but instead affects a specific time range for all wikis.
> Additionally, the currently writable external store database affects
> article edits on all wikis.
>
> There were a few suggestions thrown around:
> 1) use central notice. This would certainly have the effect of alerting
> all wikis that there was some maintenance, but it has the disadvantage of
> telling all *readers* about the outage, rather than only the people that
> would actually be interested (those editing pages).
--^ Seems to be the most reasonable thing to do. Readers who don't
care, probably don't read sitenotices that don't involve giant
pictures of everyone's favourite Wikipedia founder, and even if they
do read it, I'm sure they'd ignore it. A small maintenance notice is
not likely to annoy people. Saves not working is likely to annoy
people. Saves not working after you spent an hour revising whatever
article you're writing will definitely frustrate people.
> 2) make mediawiki cache the change to conceal the outage from editors. The
> idea here is that mediawiki would notice that the backend database is
> currently in read-only mode and would cache the change and write it to the
> DB when it returns to read-write mode. There are a number of technical
> challenges here, as well as the introduction of another system (the change
> cache), but it's an interesting way around the problem, since rather than
> addressing how to inform editors of impending maintenance it simply
> eliminates the necessity for that communication.
Sounds (very) needlessly complex. Not to mention if it partially fails
and people edits go through, then un-go through, people won't be
happy.
> 3) throw up a banner on the edit page itself. The time when we want to
> inform someone that there is going to be maintenance that will impede
> editing is when the user begins an edit. (at the moment we inform them
> when they try to save the edit in the form of an error message.)
> [..]
This also sounds reasonable. I personally would just go with just a
normal central notice, but this would also be fine imo.
> 4) don't make any change from what we do now. The external store databases
> rarely fail or undergo maintenance. Increasing the complexity of the
> system to protect against their outage will be more likely cause harm than
> the outages themselves. Instead, just announce it on the blog before and
> apologize to anybody affected afterwards.
I really feel that having a site/central notice for planned
maintenance is important. At the very least stuff like this should
probably be announced on various mailing lists or VP's. Our editors
are important, we should make sure we avoid unnecessarily wasting any
time/effort they put in to the wiki.
-bawolff
Is there anyway to turn off those Jimbo pics every time I check
something in Wikipedia...
I use many different public terminal browsers so won't be logged in.
Yes there's the little box with the [X] but "he has already looked at me".
Why can't they sign somebody who doesn't scare children, like
http://en.wikipedia.org/wiki/Pee-wee_Herman . Why does the best person
for the campaign have to be the most logical person? Haven't they got
any advertising sense? I bet Pee-wee would love to help. Why don't they
give him a call?
Now that Sam has announced the 1.18 Release Candidate, we'd like to make
sure that we've created a tarball that will work.
Please give 1.18RC1 a try and add your experience to
<http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Upgrade_reports>.
I just upgraded one of the wikis I maintain from 1.15 and recorded my
experience. Of course, as Sam writes in his announcement, you should
probably not do this on a production wiki "unless you are both very
brave and very confident in your MediaWiki administration skills." So,
maybe you'll want to try it in a test installation.
That said, let us know of your successes!
Of course, we'd like to know about failures, too, and that page is an
appropriate place to report them (in addition to bugzilla), but we
really need to know if this release is as good as we think it is.
Thanks,
Mark.
I'm happy to announce the availability of the first release candidate of
the new MediaWiki 1.18 release series.
Please try it out and let us know what you think. Don't run it on
any wikis that you really care about, unless you are both very
brave and very confident in your MediaWiki administration skills.
MediaWiki 1.18 is a large release that contains many new
features and bug fixes. This is a summary of the major changes of
interest to users. You can consult the RELEASE-NOTES file for the
full list of changes in this version.
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.18 brings the usual host of various bugfixes and new
features.
jQuery 1.6.4 is now included as standard, along with numerous
more jQuery plugins.
Breaking changes:
* action=watch / action=unwatch now requires a token
As of 1.18, some extensions are now being bundled with the released tarball.
The following extensions are bundled with MediaWiki as of 1.18. All are
currently in use
on Wikimedia sites.
* ConfirmEdit - Various CAPTCHA techniques to try to prevent spambots and
other automated tools from editing your wiki.
* Gadgets - A system to allow users to enable or disable JavaScript or
CSS tools made available to users site-wide.
* Nuke - A special page allowing administrators to mass-delete content
added by a spammer or vandal.
* ParserFunctions - Additional parser functions (like #if and #switch to
supplement the "magic words" present in MediaWiki.
* Renameuser - A special page which allows authorized users to rename
user accounts.
* Vector - Enhancements to the Vector skin.
* WikiEditor - An improved and customizable editing toolbar developed
along the Vector skin.
Major features
- --------------
Better gender support
-- ---------------------
Until version 1.17, MediaWiki used neutral nouns to address and identify
users on their user page.
In English, this was not an issue since "User" matches both genders, but in
some languages the
neutral gender is always masculine; for example, this would cause
French-speaking female
Wikipedia users to be referred to as "Utilisateur" (male user) instead of
"Utilisatrice" (female user).
With version 1.18, user pages reflect the user's gender, if they have
specified it in their preferences.
More gender support (for instance in logs and user lists) will be available
in MediaWiki 1.19.
Improved file metadata support
-- -----------------------------
MediaWiki now detects the camera orientation from Exif metadata, and
rotates the picture
preview accordingly. The original file remains unchanged.
The overall metadata support in MediaWiki has been greatly extended.
Previously, MediaWiki could only
extract limited Exif metadata, and showed a subset of it on file
description pages. Since 1.18, MediaWiki
can extract IPTC and XMP metadata from uploaded files, and more Exif
information. This includes an
embedded description, author information, GPS coordinates, or copyright
statement.
Improved directionality support
-- -------------------------------
A lot of work has been done to fix directionality bugs (Left-To-Right,
Right-To-Left). Most notably bug 6100 is
fixed, which allows to display an RTL interface on an LTR wiki properly (and
vice versa). This was developed
under $wgBetterDirectionality, which is now no longer used because the
improvements are merged
with the core code.
A positive consequence is that the page content on wikis with multiple
scripts is aligned according to the
direction of the selected variant. For example, on a Kazakh language wiki,
selecting the Arabic script
variant will align the text as RTL, while selecting the Latin or Cyrillic
variant will align it as LTR.
Easily find where to customize interface messages
-- ---------------------------------------------
MediaWiki allows you to customize the user interface by editing pages in the
MediaWiki namespace.
However, even though they can be viewed at Special:AllMessages] the sheer
number of these messages
makes it difficult to find which one needs to be customized. In MediaWiki
1.18, a new pseudo-language
is introduced (qqx) to help people find such messages, by displaying the
messages' key instead of the
actual messages. All one has to do is append ?uselang=qqx to the page's
index.php/
URL (see
https://www.mediawiki.org/w/index.php?title=MediaWiki_1.18&uselang=qqx as an
example).
New plugin for collapsible elements
-- -----------------------------------
The new jQuery.makeCollapsible allows you to create collapsible tables,
lists and so on,
by adding the class mw-collapsible to the elements.
See the manual for details:
https://www.mediawiki.org/wiki/Manual:Collapsible_elements
Protocol-relative URLs
-- ----------------------
MediaWiki now supports protocol- relative URLs in links, interwiki targets
and $wgServer.
Protocol-relative URLs look like //example.com/wiki/Foo ; the browser will
recognize this
as http://example.com/wiki/Foo when following a link from an HTTP page, and
https://example.com/wiki/Foo when following a link from an HTTPS page.
This way, protocol-relative URLs enable a wiki to support HTTP and HTTPS
while serving
the same HTML for both, which means the parser cache doesn't have to be
split.
More personalisable styles and scripts
-- --------------------------------------
MediaWiki now automatically loads javascript and stylesheets more specific
to each user.
There is a separate CSS and JS file for each usergroup
(MediaWiki:Group-sysop.css,
MediaWiki:Group-autoconfirmed.js, etc), and also a CSS file for users
viewing without
JavaScript (MediaWiki:Noscript.css).
Other changes
-- -------------
$wgEnableDublinCoreRdf and $wgEnableCreativeCommonsRdf no longer
work in core, and the functionality has been moved to the relevant
extensions.
See http://www.mediawiki.org/wiki/Extension:DublinCoreRdf and
http://www.mediawiki.org/wiki/Extension:CreativeCoreRdf as appropriate
Math
- ----
$wgUseTeX has been superseded by the Math extension. To re-enable
math conversion after upgrading, obtain the Math extension from SVN or from
http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php:
require_once "$IP/extensions/Math/Math.php";
Language support
- ----------------
As with every release, MediaWiki 1.18 brings improved support for
languages in MediaWiki, with improved translation and features for
the many supported languages.
New languages:
* Angika (anp)
* Brahui (brh)
* Central Dusun (dtp)
* Jamaican Creole English (jam)
* Khowar (khw)
* Liv (liv)
* Kichwa (qug)
API
- ---
API bug fixes and new features have been added to 1.18, providing
more options for input and output.
* API modules were added to access QueryPage based special
pages, to Compare pages, Revert files, and to be able to access
other special pages such as Special:UnwatchedPages,
Special:MimeSearch and Special:ActiveUsers
* The output of the generated help page has been improved
The API contains a breaking changes against previous releases:
* action=watch now requires POST and token.
Other
- -----
Our thanks go to everyone who helped to improve MediaWiki
by testing the beta release and submitting bug reports and patches.
Release notes
- -------------
Complete release notes are at
http://www.mediawiki.org/wiki/Release_notes/1.18
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz
Patch to previous version (1.18.0beta1), without interface text:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch.
gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz.si
g
http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch.
gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
Hey,
(Full replied to message can be found here: http://pastebin.com/J0aLk2t9)
> Please respond to appropriate mail list -- either WikiTech-L
Might be interesting to people here :)
> But I found terminology used in Validator frustrating and misleading.
Well yeah, I agree, the names parameter and argument are used pretty
loosely through the extension.
> However, it will break compatibility with existing Validator… What do you
think? It is possible? How manage compatibility? Create incompatible
Validator2?
In general I agree with your remarks, but it's not really possible to just
change this on the fly, as it would break a lot of compatibility. I suggest
creating a new alternate system while keeping the old one, so things can
gradually be migrated, and then have the old thing go when it's no longer
used.
In particular, I'd like to split the param definition from the parameter
(with value) handling functionality. Since the Parameter class is used all
over the place to define parameters, changing this one would be hard. I
also thing it's not that bad of a name, and clearer then Descriptor. So
maybe it's better to find an alternate name for the "parameter with value"
class, which is only used in Validator itself anyway. And I'd like to have
a more lightwight way of defining parameters, rather then creating a
Parameter object for each. In most cases an associative array suffices,
which can then be turned into an object later on.
And I think the current way parameter criteria and manipulations are
defined sort of sucks. You need a class for each, while often you want to
do very simple stuff. Passing in a function should also work. In PHP 5.3+,
anon functions would make a lot of sense here. If a separate parameter
definition class is cerated, it might actually make a lot of sense to have
doValidation and doManipulation methods in there. This does not allow to
share criteria and manipulation objects like the current system, but is
probably less of a hassle and less over engineered.
Also, I'd like to get rid of the evil LSB hack in the ParserHook class, but
guess it's still to early to do that (since you'd need PHP 5.3+).
Any such changes would contribute to a new mayor release, version 0.5. The
last big changes, those for 0.4, where made over a year ago, and although I
see a bunch of stuff that could be made better architecture wise, the
current system works. So I'm not that keen on making these changes now and
deal with all the compatibility issues. (Maybe after SMW 1.7 has been
released.) But if you feel like poking at it or writing up a proposal for a
new architecture, please do, I'll happily provide feedback.
> BTW, in many languages positional arguments are allowed before the first
named argument. Validator allows:
> {{ #func: pos1… | namedA=… | pos2… | namedB=… }}
Yeah, it does allow this. Originally it did not, but I figured some users
might not understand or think about the difference, so I just added this
because it works. I don't see what your issue with this is. I don't know
how this is called, but don't see how that matters :)
> I am sure Validator is a great idea and really helps. I used it in few my
extensions. I also wrote parser function `#validate' to validate template
arguments and use it in almost all my templates!
Well, please share your code - sounds like this could be useful to other
people as well ;)
Although the current architecture might need some tweaking to become really
nice, I think having a declarative system for parameters is very powerful
as it allows for a whole range of cool things, which is why I created the
extension in the first place. Since then I've only become more convinced of
this, and would really like to see such functionality get put into core at
some point, in one form or another. Any comments on this are appreciated.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--