What: Localisation and internationalisation bug triage
When: Wednesday, January 18, 13:00 UTC
Time zone conversion: http://hexm.de/cu
Google Calendar: http://hexm.de/cv
Where: #wikimedia-dev on freenode
Use http://webchat.freenode.net/?channels=wikimedia-dev
if you don't have an IRC client
Notes: http://etherpad.wikimedia.org/BugTriage-i18n-2012-01
I'm working with Siebrand Mazeland to hold a l10n and i18n triage in a
couple of weeks. You are all invited as usual.
Bugs and issues to be covered are TBD, but this is the area of code that
affects every user of MediaWiki, so I expect we'll cover a lot of ground.
Mark.
a user Jan Kucera (Kozuch) (with email of garbage5(a)seznam.cz) has been mass
changing the priority of bugs based on a very crude vote count. this is
very disruptive and counter productive issue. I would ask that one of our
devs mass revert this please.
Johh
I've reverted a number of recent commits to the Title class which added
several more pre-cached fields to it, as I really don't think we want that
sort of data in Title objects to begin with. A Title object is meant to
represent a... well, a page title :) and as such should be roughly
equivalent to passing the string-form title around, but without having to
parse and de-parse the items all the time.
Since ancient times we've had a couple things like an article ID being
saved into local state, which is frequently useful to optimize lookups but
has its own problems (it has to be explicitly cleared or reset from time to
time). These really belong more in a 'Page' object than a 'Title' however.
These days we've got a WikiPage class which has been further split from
Article as well; it seems to me that these sorts of things might belong
better there than in Title. Thoughts?
-- brion
Several of us took off the past few days. But now its time to get back
on the Code Review wagon.
CRStats (http://toolserver.org/~robla/crstats/) shows that on December
24th we were had around 500 revisions left for review.
This wasn't too bad except that we CRStats shows we were supposed to be
closer to 300 revisions left.
Today is worse. We're up to over 600 revisions for review while Robla's
projections show that we're supposed to be closer to 200 revisions for
review.
So, I'm gonna pile on with Chad and Brion here and ask you guys to stop
working on features and refactoring by Friday (if not today) and help
out with reviewing code or, if that isn't your thing, help fix code
marked FIXME:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/status/fixme
We've got about 40 revisions marked FIXME and I'm sure that more will
show up as we go through the review queue.
For what its worth, until we branch, I'm going to be putting trunk up on
for testing on http://deployment.wmflabs.org/ and asking different
users to try it out.
If you have any other ideas for how we can get more eyes on the code
we've produced over the past few months, I'm all ears!
Mark.
Hi.
I filed <https://bugzilla.wikimedia.org/show_bug.cgi?id=33464> just now
regarding adding a "Developer" or "API" link to the footer of Wikimedia
wikis as a means of better publicizing the MediaWiki API and encouraging
tool development with MediaWiki.
The question becomes what the target of such a link should be. I think there
are a few possibilities of where it could go, on MediaWiki.org and
Meta-Wiki. I'm not sure which site is most appropriate here and I'm not sure
which page is best.
Regarding what users should see when clicking this link, I think a few key
points must be made clear, namely that:
(a) there is an API!
(b) it generally doesn't require registration (though registering has
[[benefits]]), but more importantly the API does not require invitation
(c) easy-to-find links for programming language libraries (inspired by
<http://developer.wordnik.com/> which has large icons that developers can
easily recognize); currently a lot of this content (aggregated lists of
MediaWiki API libraries) is actually still on the English Wikipedia; it
would need to be moved over
(d) links to information about database dumps (when they're appropriate to
use, how they're obtained, etc.)
(e) links to information about MediaWiki development (as opposed tool
development alongside MediaWiki)
The whole intro page should be fairly simple and clean and have i18n
capability from the outset, I suppose.
Thoughts?
MZMcBride
On Wed, Jan 4, 2012 at 7:42 AM, Daniel Friesen <lists(a)nadir-seen-fire.com>wrote:
> On Tue, 03 Jan 2012 06:14:36 -0800, Antoine Musso <hashar+wmf(a)free.fr>
> wrote:
>
> > Le Fri, 30 Dec 2011 18:31:30 +0100, Krinkle <krinklemail(a)gmail.com> a
> > écrit:
> >> Since virtually any value other than null and undefined is an object,
> >> including numbers, strings and functions.
> >
> > Much like ruby! http://ruby-doc.org/core/Integer.html
> >
> > $ irb
> > >> 5.upto( 10 ) { |num| print "#{num}ber," }
> > 5ber,6ber,7ber,8ber,9ber,10ber,=> 5
> > >> print 4.even?
> > true=> nil
> > >>
> >
> > You can change the 'even?' behavior to do something else of course :D
> >
> >
>
> ;) Oh no, in Ruby EVERYTHING is an object, there is no 'virtually' or
> 'almost'.
>
> >> nil.class
> => NilClass
> >> puts "nil is nil" if nil.nil?
> nil is nil
> => nil
> >> nil.is_a? NilClass
> => true
>
> Although, their booleans are awkward.
> >> true.class
> => TrueClass
> >> false.class
> => FalseClass
> >> true.class.superclass
> => Object
> >> false.class.superclass
> => Object
> Last I checked the way to say "Is this a boolean?" in Ruby was `value ===
> true || value === false`. Ugh.
>
> In JavaScript we have Boolean instead.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
JavaScript:
>> true.constructor
< Boolean()
and Boolean inherits from Object too.
Difference though is that in constrary to Array and Object, JavaScript
treats a literal
strings, numbers and booleans always strictly equal to a similar one.
In that 5 === 5. Wheares new Number(5) === new Number(5) is false.
So eventhough numbers, strings and booleans are objects, they do not have
"typeof"
object, only those that are declared object through "typeof" are compared
by reference.
So both [1, 2] === [1, 2] and new Array(1,2) === new Array(1,2) is false.
yay!
Hi,
I have a question on the UserMailer::EmailNotifications class. Would it
be possible to move the settings of the protected variables out of the
actuallyNotifyOnPageChange() functions and in the initialisation routine
(or some other routine)?
If that is not possible, is there another way to compose a notification
message without sending it out (and without replicating the whole class).
What I want is to modify the list of watchers. I have a fairly small
wiki, where 90% of the edits happen by known editors (who have the
'autopatrol' permission). I'm currently using the
$wgUsersNotifiedOnAllChanges to check edits for spam (some more 7%) and
legitimate edits from guests (the remaining 3%). However, I would be
much happier to get only mails for all Unpatrolled changes (i.e. those
not autopatrolled). So I'm writing a small extension which defines
$wgUsersNotifiedOnUnpatrolledChanges.
Obviously I like a hook that allows me to modify the list of watchers,
but failing that (it's apparently still on the todo list, see r44960)
I'm using the RecentChange_save hook.
However, I seem to fail to use the UserMailer::EmailNotifications class.
Any suggestions?
1. Is there still a way to use UserMailer::EmailNotifications?
2. Should I rewrite the functionality of UserMailer::EmailNotifications
in my extensions?
3. Is it possible to change UserMailer::EmailNotifications?
4. Is there perhaps another way to accomplish what I like to do (I only
know about Extension:AutoWatch, but that is not exactly what I want)?
Regards,
Freek Dijkstra
Hi.
Someone asked me about LiquidThreads and I pointed them to
https://www.mediawiki.org/wiki/LiquidThreads_3.0 only to realize that the
current timeline on that page reads "August 2011".
Is there an updated status for LiquidThreads? I vaguely recall some e-mail
saying it wasn't going to be a priority in 2012, but I don't really
remember. If someone knows and could update this list or that page, that'd
be awesome.
MZMcBride
This is a (admittedly long and elaborate) question, not a proposal. I ask
it in order to learn whether anyone has given it or something like it
some thought.
Has anyone thought of creating MW 2.0? I mean by this, completely
rewriting the application in a way that may make it incompatible with MW
1.x.y.
Pros
----
* Improving the application architecture
* Utilizing more client side resources, thereby reducing the server side
resource requirements.
* Clean up and improve existing services.
Cons
----
* Rewrites of major applications normally fail because they become overly
ambitious.
Some possible ways MW 2.0 might improve MW 1.x.y
Change the parser
-----------------
* Get rid of mediawiki markup and move to html with embedded macros that
are processed client side.
* Move extension processing client side.
* Replace templates with a cleaner macro-based language (but, KISS).
Pros
----
* Reduce server side resource requirements, thereby reducing server side
costs. Server side becomes mostly database manipulation.
* Make use of the far larger aggregate resources available on client side
(many more client machines than server machines).
* With macro processing client side, debates about enhancements to parser
extensions that require more processing shift to looking at client side.
* Allows development of a parser driven by well-defined grammar.
Cons
----
* Unclear whether it is possible to move all or most parser processing to
client side.
* Would need a (probably large and complex) transition application that
translates mediawiki markup into new grammar.
* Since not all clients may have the resources to expand macros and do
other client side processing in a timely manner, may need to provide
server side surrogate processing based on either user selectable (e.g.,
preferences) choice or automatic discovery.
* Need to select client side processing engine (e.g., Javascript, Java),
which may lead to major developer fighting.
Clean up security architecture
------------------------------
* Support per page permissions, ala' Unix file system model.
* Integrate authentication with emerging global services (e.g., OpenID)
without use of extensions.
* Move group membership definition out of LocalSettings into database
table.
Pros
----
* Chance to think through security requirements and craft clean solution.
* Offload most authentication processing and login data protection to
service providers that more sharply focus on its requirements.
* Some customers have expressed interest in per page permissions.
Cons
----
* Changing security architectures is a notoriously difficult objective.
Most attempts lead to bloated solutions that never work in practice.
* Some developers oppose per page permissions.
* Would need to develop WMF standards that authentication providers must
meet before accepting them for WMF project login.
This is sufficient to illustrate the direction of my curiosity, but there
are other things that MW 2.0 could do that might be discussed, such as:
* Change the page history model. When page is flagged stable, subsequent
page changes occur to new draft page. Provide link to draft page on
stable page.
* Think through how to support multiple db backends so application
development doesn't continually break this support.
--
-- Dan Nessett
Hi folks,
You probably noticed that I started the bot I talked about and got a
bit criticised for :) because it's written in c#, however we are using
it in some channels and it is producing logs. What we need now is to
create a simple search interface written in php or even javascript. If
there are some people who would like to volunteer we could work
together on that, the logs are stored on labs on
http://bots.wmflabs.org/~petrb/logs (note some channels are just empty
folders, logged are only all dev channels) I can of course give you
access there, if you already have labs access or just cron svn up
whole folder, and we could work together on some inteface which would
be in trunk/tools/wmib/logs
We could also use current source of search interface we have on
toolserver, but it doesn't seem to work to me, no idea why and I don't
have source code of current interface so if someone can commit it to
svn we could base new interface on current interface or just improve
it and maybe in future update even that (I mean search interface we
use for #mediawiki). goal is to create a simple interface where you
can pick a channel, date, eventually some criteria hit search and it
would come out with results. I think it would be useful for people who
got disconnected while chatting and need to know what was going on, or
search past discussions or meetings.