Two more easy patches are awaiting commit, for those hunting for top
RESLOVED/FIXED position: bugs 33494 and 33496.
Also, with the upcoming migration go GIT, I have a suggestion for
another access group: /Skins. I do not really consider the skins/
directory to be part of core or extensions, as skins only relate to the
client side.
For that matter, perhaps /Client would be another option, whouch would
include both skins/ and resources/; all client-side components of MediaWiki.
--
Erwin Dokter
Why do email notifications from Wikipedia have the sender as
"MediaWiki Mail"? Most Wikipedia users probably don't know what
"MediaWiki" is. I suggest it be changed to "Wikipedia" or "Wikipedia
notifications" or something like that.
Hello All,
I am planning to develop a new Open Source project keeping mediawiki as the
baseline. I wonder how the liciening policy of mediawiki will affect my
intention. Could somebody help me on whether it is possible to develop my
own app using mediawiki and distribute it as an opensource project?
Thanks,
Regards,
Sajith Vimukthi Weerakoon,
T .P No : ++94-716102392
++94-727102392
Hi,
The current mw.msg javascript api of mediawiki is not capable or
handling messages with PLURAL, and GENDER syntax. This is a
limitation for the extensions/core to show localized messages
according to gender, plural context. To make sure that the javascript
based message parsing system function same as the php message handing,
Neil had written mediawiki.jqueryMsg.js and he had added it to the
core recently. It is a wikitext parser written in javascript. If we
integrate mw.jqueryMsg with ms.msg, we can make sure that messages
with PLURAL, GENDER, GRAMMAR etc can be handled very well at client
side too.
This change was done in r107556[1], but there was a discussion about
whether mw.jqueryMsg should be added as an optional dependency or not.
r107556 make it load in all pages. But Krinkle commented(see the CR
comments) that it can be added as a dependency to extensions which
require PLURAL/GENDER and he don't see a reason to make mw.jqueryMsg
load everywhere.
1. It is true that currently no messages use PLURAL/GENDER for
messages to be processed at javascript. But when we support this
feature, there will be many valid use cases. Whenever we show
numbers,(eg: "there are 6 items") in any language, plural support is
must. Similarly language like Arabic, Russian etc require Gender,
Grammar too.
2. If we can provide a single abstraction mw.msg around all kind of
l10n messages, that would be a good idea. If a message contains
{{PLURAL}}, doing the message handling in a different way is a bit
odd.
3. If we dynamically load mw.jqueryMsg using mw.loader, it is going to
be asynchronous, and I think that will demand a change in the way
mw.msg is called now.
The concerns are increased page size and may be performance. Niklas
observed that the impact is about 2 KiB in normal mode and 7 KiB in
debug mode. The benefit is better localization of mediawiki.
So what could be the best way to use capabilities of mw.jqueryMsg for
mw.msg by keeping the abstraction that mw.Message and mw.msg provide
now.
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107556
Thanks
Santhosh
The following JavaScript works fine in MediaWiki 1.17.1, when placed into a ResourceLoader-loaded module, producing an alert box:
addHandler(window, 'load', function() {
alert('hello');
});
However, the same code does not seem to run in MediaWiki 1.18.0 in Internet Explorer 8: no alert box is displayed. (It still works in Firefox though.)
Anybody know why?
I have confirmed, using IE Developer Tools, that window.addHandler is defined in IE after the page loads, by typing "addHandler.toString()" in the console:
>>addHandler.toString()
"function(element,attach,handler){if(element.addEventListener){element.addEventListener(attach,handler,false);}else if(element.attachEvent){element.attachEvent('on'+attach,handler);}}"
Thanks,
DanB
> Message: 4
> Date: Mon, 02 Jan 2012 18:07:17 -0500
> From: mhershberger(a)wikimedia.org (Mark A. Hershberger)
> Subject: [Wikitech-l] Fixing bugs before deployment (was Re: Rolling
> towards 1.19... scheduling a code freeze)
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID: <87k45966vu.fsf_-_(a)spyke.nichework.com>
> Content-Type: text/plain
>
> Chad <innocentkiller(a)gmail.com> writes:
>
> > On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> >> I'd like us to plan for a code freeze on trunk -- at least a feature &
> >> refactoring freeze -- starting within a few days to give us all a chance to
> >> tidy up, catch up with code review, and prepare for deployments.
> >>
> >
> > +1
>
> I'm all for it!
>
> > Sounds good. Want to say Friday's the date to be "feature complete" to
> > give people the rest of this week?
>
> Again, great idea.
>
> One thing I would like to do is make sure
> https://www.mediawiki.org/wiki/MediaWiki_1.19 lists all user visible
> changes. I almost said "all significant user visible changes", but then
> someone might know of a user visible change, but not consider it
> significant and neglect to put it in there.
I disagree having "all" visible changes listed would be useful. The
majority of all changes result in some visible change (however minor).
People who are interested in every change generally would already read
the RELEASE-NOTES. If we make a list of changes of roughly the same
scope as the release notes, it will probably have the same number of
readers as the RELEASE-NOTES (Which isn't a whole lot when it comes to
your average Wikimedia).
Personally I liked the major feature summary we did for 1.18 on the
Wiki page. It gave people just interested in "whats new", but not
interested in minor differences that don't make a that much of a
difference, something to look at. There's going to be a good portion
of the user base who are only interested in the highlights.
>
> Starting next week, after the "feature complete" deadline that Chad has
> proposed, I'd like to take a list of features to the different projects
> and work them to try out the changes on a test deployment wiki.
>
> I'm trying to be more proactive about this than we have been in the
> past, so that bugs like the now-infamous EXIF rotation problem
> (https://bugzilla.wikimedia.org/31504) are spotted earlier and,
> hopefully, dealt with *before* deployment.
I doubt that the issue could have been dealt with before deployment.
Most of us thought it was a fairly good idea, pre-release to the wilds
of Wikimedia Commons. In my opinion, the main failures in dealing with
that situation is that we didn't listen to the complaints when they
happened (they were fairly immediate upon deploying 1.18 if i recall),
but instead waited 2 months until someone decided to raise a fuss on
foundation-l.
With that said, it would be great if we could catch everything before
deployment, but sometimes things will get through.
> I need to start doing something similar with tool upgrades, too. If I
> hadn't been content to simply nag Ops about deploying rsvg upgrades or
> recompiling wikidiff2 then bugs like "rsvg on scaler does not support
> styling the root element" (https://bugzilla.wikimedia.org/31122) and
> "Excessive punctuation highlighting in wikidiff2"
> (https://bugzilla.wikimedia.org/33331) might have been recognized
> sooner.
>
> Mark.
Some quick tests to make sure everything works ok should certainly be
done during upgrades, but even still, some things will get through
(For example the other rsvg bug - 33323 would be much harder to catch
from quick tests, and even the rsvg bug would probably have many files
that aren't visibly affected)
A message on the commons village pump whenever rsvg is updated would
be a good idea imho (since they are generally the folks who deal with
svgs and should know if something potentially changed, and people like
knowing when things change). At the end of the day though, unless you
are planning to visually inspect 100 000 odd svg images and compare
the before and after, I doubt you will catch all such bugs.
Cheers,
Bawolff
A test page for the new VIPS image scaler is now available:
https://test2.wikipedia.org/wiki/Special:VipsTest
You can give it names of images from Commons and it will show a
comparison with a moving divider, with the thumbnail from ImageMagick
on the left, and the one from VIPS on the right.
I'll explain what you would expect to see when using this tool:
For JPEG images, using a sharpening radius of 0.8 will make the VIPS
result roughly match the ImageMagick result, as long as the thumbnail
is reduced to less than 85% of the original width. With not enough
sharpening, the resulting image looks blurry. With too much
sharpening, contrast in fine detail will be unrealistically enhanced
and high-contrast borders will develop "halos".
Above about 50% reduction factor, the block average introduces
artifacts in fine detail, so enabling the "bilinear" option will look
better, and will more closely match ImageMagick. But if the bilinear
option is used with a reduction factor much smaller than that, severe
artifacts will be seen in areas of contrasting fine detail.
At small reduction factors, the main difference between ImageMagick
and VIPS is that VIPS uses a simple block average whereas ImageMagick
uses a more complex windowing function. This leads to minor
differences in fine detail.
What we're looking for out of this test is:
* Confirmation that VIPS is not completely failing fpr some class of
images.
* Suggestions for parameter values (sharpening, bilinear) for various
source and destination sizes. VipsScaler allows these parameters to be
configured depending on source size and reduction factor.
-- Tim Starling
Hi,
I think it would be cool to implement a feature which would allow
users to group all their accounts, it would be very useful for sites
like english wikipedia so that people could avoid being accused for
"sock puppetry" (using more than one account) by marking the accounts
as grouped, it is possible to create account in mediawiki so that you
can see in log that it was created by someone else, but this log is
available only for wiki where it was registered on and it's also not
possible to mark account later in case you forgot to create it in
proper way
Statistics of users would be also more accurate because you would be
able to list groups only instead of all users and you would see exact
number of users and not number of all accounts, including alternative
accounts
This group interface could allow people to group their account
anytime, the grouped accounts would be still completely separate, with
different configuration, etc. But it would allow to check how many and
which accounts someone have in a simpler way than it's now. (browsing
multiple logs isn't really easy)
My idea is that each account would implicitly have a group which would
be identical to its name, User:TestyBob would be a member of group
TestyBob but it would be possible to change this group to any existing
group, it would be of course needed to confirm this from target
account, then you would just display members of group Test and you
would see list of all accounts linked to the "main account", so you
would know who is owner, how many account they have and such. I think
it would be best to do this on a SUL level, so that it would work
project independent.
Example:
User:Bob - member of Group:Bob
User:CoolBotofBob - member of Group:Bob
User:Bob (testing) - member of Group:Bob
in this case user has 3 accounts, grouped in a group Bob, it's clear
that Bob is a main account of user
User:Peter - member of Group:Peter
in this case, user has only 1 user account which is a member of its own group
we have 4 accounts in mediawiki and 2 users in this scenario
When user bob create a new account User:B0b he could just change
Group:B0b to Group:Bob and then confirm it from his main account
User:Bob, there would be a special page which would allow to list
members of groups, so it would be really easy to look up if user has
alternative accounts etc.
Thank you for responses, it's just a proposal and it can be heavily
changed upon your feedback.