To reduce the amount of clicks needed during code review, I wrote a
gadget that displays basic information about a revision in
tooltips.[1] To enable it, you need to check "Display revision
information in tooltips" in your preferences (section "Gadgets").
Have fun!
----
[1] http://www.mediawiki.org/wiki/File:CodeTooltips.png
--
Max Semenik ([[User:MaxSem]])
Hello,
Some localizable messages in MediaWiki features and extensions have
very complicated, ambiguous and error-prone wording. A big example for
that would be FlaggedRevs, but there are others. MediaWiki also has
ability for changing messages according to number, gender and other
grammatical features. It's not enough to just translate a list of
strings there - the translation must also be tested in context.
The right way to do it is to have a test suite: A document that walks
the translator through all the use cases of the feature so that all
possible messages permutations and combinations appear.
There are plenty of methodologies and tools for testing code, as well
as books and courses that teach them. I tried to search for set
methodologies that focus on testing localization, but until now i
didn't find almost anything.
So, two questions:
1. Are there currently any tests in the MediaWiki test suite that
focus on localization?
2. Does anyone on this list know about testing methodologies that
focus on localization?
PS: I wrote a few things about it in the English Wikipedia article
[[Software testing#Internationalization and localization]], although i
admit that it's at least partly original research based on my own
experience.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
I really need to sort out how I receive mailing list, rather than just
digests
Just tested it, literally copy pasting the gadget into one of the existing
CR JS files (granted, if/when committed it should be its own file), refresh
CR, and it works.
Should be easy to put in our SVN, no? ;)
Sam
I'm working with a group that has customized their mediawiki
installation so that they can create multiple wiki instances, each with
their own database, that have no knowledge of each others existence.
This was done for security and privacy reasons.
They now would like to be able to search a number of these multiple wiki
instances from within one newly defined wiki. I'm thinking the method
they are attempting may be as simple as creating a wiki home page with
links to each of the wikis they would like to search.
Is this possible? Is the wiki search driven by a crawler that would
follow the links on that new wiki home page? If not, is there an
approach I could follow to be able to provide search capability against
a select number of these individual wikis under one umbrella?
Thanks for any suggestions!
I have been wondering, I am unable to access SVN at all.
What would be the best way for me to get the code and submit patches?
Also, I am assuming that access to the repo would be completely
useless to me; would there be no reason for me to be granted it
therefore or would it still have its uses?
Thanks in advance,
Joseph Roberts
Hi everyone,
Russ Nelson (svn account: nelson) is a new committer to core
MediaWiki. Russ is contracting to Wikimedia Foundation to create a
scalable media storage system based on OpenStack's Swift object store,
some Swift middleware custom for MediaWiki, and File and
FileRepo-derived classes specific to Swift.
User page:
http://www.mediawiki.org/wiki/User:RussNelson
Rob
(I'm taking a two week hiatus from banging the 1.17 tarball release
drum. It'll be be back next week. In the meantime, have a look at
http://bugzilla.wikimedia.org/26676)
Earlier this week, I gave you my list of bugs marked “highest” priority,
but two devs that I have an enormous amount of respect for pointed out
gaping holes in my list and made it practically non-existent. So,
tonight, I've gone through the next level of bugs trying to find the
ones that I thought should be the “highest” priority.
But first, If you'd like to look at the two lists I put out earlier this
week here are links to the messages:
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/52549http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/52568
Now, the new “highest” priority bugs.
Bug# Description
2888 Broken thumbnails not being generated
https://bugzilla.wikimedia.org/2888
It isn't clear that this one is still happening, and later
comments may have turned this into an “SVG doesn't thumbnail
bug” which would make this a dupe of (probably) #8566
6100 Allow different directionality (rtl/ltr) for user interface and
wiki content depending on user preferences language and &uselang
https://bugzilla.wikimedia.org/6100
I worked on something related to this bug last year (maybe
fixing it?) and the bug has plenty of patches available if
more work is needed. This one seems worth the effort.
14629 Titleblacklist entires with <newaccountonly> should affect
automatically created accounts with SUL too
https://bugzilla.wikimedia.org/14629
Still popping up as recently as last November. Interest has
been shown, not-quite-total fixes applied, but still it remains.
18682 Can't provide alt text for files in <gallery>
https://bugzilla.wikimedia.org/18682
I like Maria's comment: I know that moaning won’t get this
bug fixed, but I am desperate. I was quite happy when
galleries were finally free of layout tables (#3276). However,
gallery is as useless as before without the possibility to
add alternative text to the images. The more images you have
in an article, the more missing alt texts are annoying. And
usually articles containing a lot of images (e.g. about
paintings) are using galleries.
19161 Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/19161
I think this one is fixed but I'm relying on you to help me
determine what, if anything, still needs to happen. This is
refered to in #23126 as well.
21919 Google News SiteMap Extension
https://bugzilla.wikimedia.org/21919
Bawolff has already done a lot of work on this to bring it
up to snuff. He now need another developer to review his
code and approve it for deployment or tell him what needs to
be fixed.
23126 Locked and hidden accounts can unify new local accounts
https://bugzilla.wikimedia.org/23126
Tim says this is apparently a deliberate chage, and later
comments leave me confused: should this be closed or the fix
for this bug reverted?
Let me know what you think of this latest batch of bugs. Are they
worthy of the attention?
Mark.
hi all!
In the hope i'm not clubbing a diseased donkey, i'd like to share an idea i ran
across: we could use the RC4-128 cypher for secure.wikimedia.org, instead of
AES256. RC4 is reportedly a lot faster (3 to 4 times the throughput). Since CPU
capacity for encryption has been mentioned as one of the problems with making
secure.wikimedia.org reliable, I thought it might help.
Note that even though the use of RC4 in WEP led to WEP being broken, RC4 is
still fine for use with SSL. The attacks that broke WEP don't apply there
<http://www.rsa.com/rsalabs/node.asp?id=2009>,
<http://blog.ivanristic.com/2009/08/is-rc4-safe-for-use-in-ssl.html>. Google and
BankOfAmerica, among others, seem to trust in this :)
-- daniel
I noticed that there's a github mirror of the svn repository at
https://github.com/mediawiki, but it is rather out of date. Any idea
if/when it could be made up-to-date again?
I volunteer to help if it is necessary.
--
Yuvi Panda T
http://yuvi.in
Since I've had so much success with the triage meetings for Bug 27339
(http://eiximenis.wikimedia.org/Bug27339, summary coming tomorrow) I
thought I'd try to do the same thing with wikitech-l and the
non-enhancement bugs marked “highest” priority.
Every week, I'll publish a list of these bugs here with a summary of
their status. Since I don't always have a good grasp of what is of the
most interest to the larger community, I need some feedback on these
bugs. If you think there is something that should be on this list that
isn't, let me know. Likewise, if you think something on this list
should not be here, let me know.
For now, though, I'll just post the one-line summary of the bug and its
number. Look these over. If you see one that you think you could take
responsibility for, then assign it to yourself. I do ask, though, that
a developer has only one highest priority bug. Don't get over-ambitious
— I will be nagging you, after all.
So now, the bugs:
28052 Deploy Gender Namespaces on all relevant wikis
27089 Request to move Wikimedia.in to Wikimedia servers
23126 Locked and hidden accounts can unify new local accounts
27537 When SVG file is broken, warn about that, instead of mime failure.
22428 Line breaks in pasted text not picked up in Safari 4, Chrome 4
16976 Wikis ready for creation (tracking)
1319 doBlockLevels inserts pre-tags in a text created by an extension
Hope to hear from you all,
Mark.
