Re: [Wikitech-l] RFC: Refactoring the Title object

[Tim Starling]

On 25/10/13 03:32, Daniel Friesen wrote:
> On 2013-10-24 9:19 AM, Brad Jorsch (Anomie) wrote:
>> The claimed problem behind a lot of this is "too many dependencies"
>> making things hard to test and the idea that you can somehow make this
>> go away by dividing everything into tinier and tinier pieces. To some
>> extent this works, but at the cost of making the system as a whole
>> harder to understand because you have to track all the little pieces.
>> I doubt MediaWiki has reached the point of diminishing returns on
>> that, but I'm not really sure that the end-goal envisioned here is the
>> *right* division.
> Then there's the potential that individually testing a bunch of
> components doesn't always match what happens in the actually used code
> that puts everything together. So in the end you either have to also
> test the thing as a whole anyways. Or you end up with unit tests that
> are even less useful than you started because they won't catch
> regressions they would've originally.

Intuitively, it seems likely that if we reduce the typical scope and
integration level of automated testing, we will end up missing bugs,
because bugs which were previously testable due to being within a
single unit will now be spread over multiple units. Presumably this
effect is offset by an increase in test coverage.

However, I would prefer not to make such decisions by intuition alone.
It would be nice to see some solid statistical data on this.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Tim Starling]

On 25/10/13 03:19, Brad Jorsch (Anomie) wrote:
> So then the RFC proposes a "ServiceRegistry" to try to get around this
> problem of everything requiring dozens of arguments. But after observing
> that RequestContext already *is* this, it then argues against using
> RequestContext on the basis of additional dependencies. The logical
> extension of this argument is that we're not really talking about a
> "ServiceRegistry" here, we're talking about a "TitleServiceRegistry" and
> then we'd also have a "RevisionServiceRegistery", "PageServiceRegistry",
> "UserServiceRegistry", and so on, trying to pretend there is no forest
> because we can point to all the individual trees. Why not have one
> ServiceRegistry, maybe even part of RequestContext, and use it
> preferentially for passing services instead of just as a fallback? 

The proposal as I understand it is just for a single ServiceRegistry
class, rather than TitleServiceRegistry etc. I raised similar concerns at



Daniel's response was: "You are right that the ServiceRegistry is
again bundling all the services in a single object. The point is to
restrict access to ServiceRegistry to "bootstrapping code" (e.g. in
static hook handlers) only. RequestContext is used all over the code,
so all the code is dependent on anything in the RequestContext. That
makes me very very reluctant to add more stuff to it."

> Do we
> really have the need for multiple differently-configured services all over
> the place in "real" code that we need to be passing them around
> individually, or is it just for testing where we could as easily solve the
> problem by creating a registry instance that throws errors for all the
> services not needed for each test?

Division of the Title class could help with features such as:

* Dealing with titles in foreign wikis, with a different set of
namespaces and first letter capitalisation to the request context wiki

* The URL customisation needs of features like action=render and DumpHTML

> The claimed problem behind a lot of this is "too many dependencies" making
> things hard to test and the idea that you can somehow make this go away by
> dividing everything into tinier and tinier pieces. To some extent this
> works, but at the cost of making the system as a whole harder to understand
> because you have to track all the little pieces. I doubt MediaWiki has
> reached the point of diminishing returns on that, but I'm not really sure
> that the end-goal envisioned here is the *right* division.

Since the Title class is large to start with (4895 lines) I figure it
can tolerate being cut up a few times without the resulting pieces
becoming tiny. So, it makes an interesting test case for the approach.
We will see the consequences with more clarity once the code reaches
Gerrit for review, if we allow it to proceed that far.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Tim Starling]

On 24/10/13 23:19, Jeroen De Dauw wrote:
> Hey,
> 
> Proposed:
>>
>> $tp = new TextTitleParser();
>> try {
>> $title = $tp->parse( $text );
>> $tf = new UrlTitleFormatter( $title, 'foo=bar );
>> return $tf->format();
>> } catch( MWException ) {
>> return null;
>> }
>>
> 
> I hope this is your own interpretation of what would happen on top of what
> is proposed and not what is actually proposed, since this code snippet has
> some issues.
> 
> Those parser and Formatter objects contain configuration specific state. If
> you instantiate them like this, you are creating code that is just as bad
> as Title::newFromText, where this newFromText method relies on similar
> config specific state. In both cases you are using global state and
> programming against concretions.

No, it's not what's proposed, it's proposed to have a thing called a
ServiceRegistry which would supply parser/formatter instances. I think
the ServiceRegistry itself should be managed by the RequestContext,
for lifetime control, whereas Daniel Kinzler thinks it should be a
singleton.

> Does the RFC also sate exceptions should be used rather than returned error
> values? Seems like a quite disjoint concern to me. And if you use
> exceptions, please use them properly and do not copy-paste MWException all
> over.

No, the RFC does not state that exceptions should be used.

Maybe you should both read the RFC.

https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Matthew Flaschen]

On 10/24/2013 08:04 PM, Steven Walling wrote:

On Thu, Oct 24, 2013 at 7:04 AM, Dan Andreescu wrote:


That's really cool Ori.  Have people looked into why jQuery UI gets loaded
by default?  It seems to not be used in any obvious way.



One reason I've heard for doing this is so people can use it content pages.
We've had requests to do the same for mediawiki.ui. Otherwise, people who
want to put buttons in Help pages and the like can't use it.


We're not doing it on purpose AFAICT.  See 
https://bugzilla.wikimedia.org/show_bug.cgi?id=0 .  If this causes 
content buttons to break, some sites may want to add jquery.ui.button to 
their Common.js.


Like Daniel said, most of jquery.ui is useless without JavaScript.  We 
could load just jquery.ui.button on content pages, but mediawiki.ui 
would probably be preferable, since we're trying to move that way.


It would be nice to only add it on pages that use it, but I'm not sure 
how feasible that is.


Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[Matthew Flaschen]

On 10/24/2013 08:27 PM, Steven Walling wrote:

Thanks for doing this Jon.

When I used the Vector version, at first I got an all black screen, which
made me think it was broken. I guess that was just a CSS rule to click and
delete? :)


Yes.


Yeah, if we don't have a bug about settling on one overlay style, we
should. This is pretty bad. Maybe the work being done to split out
ve.ui/oo.js/whatever we're calling it might help us settle on a standard?


It's part of https://bugzilla.wikimedia.org/show_bug.cgi?id=55534


  * .guider_button



Extension:GuidedTour. Matt will explain more I'm sure.


Right.  As noted, it's not actually being used.

To complicate it further, I think the UX team actually now wants to go 
in a totally different direction with no blue buttons at all 
(https://www.mediawiki.org/wiki/File:WMF_DESIGN_Password_Reset.png).


So we should try to finalize that if possible.  That might avoid people 
having to go back and change their HTML twice (once to use mw-ui, 
another to e.g. add another layer).


In some cases CSS can be changed alone, but sometimes they have to be 
changed in tandem, which is more code to touch.


CCing the design list.

Matt

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[Matthew Flaschen]

On 10/24/2013 05:43 PM, Jon Robson wrote:

I think we are all in agreement that the CSS in MediaWiki is a mess
but it's not clear how to solve the mess.

I think I've created a useful bit of JS to visualise this mess and
make a path to solving it clearer.

If you visit:
http://jonrobson.me.uk/lsg/


This is an interesting tool.  I think mostly we have a pretty good 
understanding what the issues are, but it's still a lot of work.  My 
understanding (correct me if I'm wrong):


1. The design and UX team generally want to transition from jquery.ui to 
a mediawiki.ui library.
2. VE has special issues since they want it to be usable as a 
stand-alone editor, but they are making progress in factoring out 
oojs-ui (a new UI library) from ve.ui 
(https://gerrit.wikimedia.org/r/#/c/88896/).  I think they are 
interesting in making mediawiki.ui a custom layer on top of the more 
general oojs-ui library (kind of like you can have jquery ui themes. but 
probably with significant differences in the details).  This part is 
probably the most up in the air, and would be good to discuss at the 
architecture summit, among other places.



You will see in the dropdown mediawiki vector styles. This is a CSS
file I created by manually concatenating all CSS files loaded by
default on desktop.


Can you explain how you did this?  I don't see GuidedTour being loaded 
by default on desktop (and it certainly should not be).  See e.g. 
http://httparchive.org/viewsite.php?pageid=11675485#waterfall



* .guider_button


Good catch.  This is not actually used anymore.  It was originally from 
a third-party library (GuidersJS), which we have now forked/merged into 
GuidedTour.  I have been planning to make the UI in GuidedTour sit on 
top of of mediawiki.ui for a while (including things where mediawiki.ui 
doesn't have an implementation yet).  However, in the meantime, you're 
right we should remove the no longer needed CSS 
(https://bugzilla.wikimedia.org/show_bug.cgi?id=56142).



3) There are 13 different CSS rules for creating a pdf icon next to a link


It's helpful to link to existing bugs 
(https://bugzilla.wikimedia.org/show_bug.cgi?id=54604)


Changing the parser would probably make the CSS simpler, like you said. 
 Of course, that requires a more testing than a simple CSS change.


The reason for searching for pdf# and pdf?, rather than just PDF is 
probably to avoid false positives.


Some of those are actually in English Wikipedia's 
https://en.wikipedia.org/wiki/MediaWiki:Common.css, not core.


They chose to override the PDF icon.  If it's libre, and there's 
consensus to use it in core, we could do that.


They also added selectors for mw_content, which seems to only be used in 
Modern and thus should be moved to 
https://en.wikipedia.org/wiki/MediaWiki:Modern.css (at least until it 
can use the same content ID as everyone else).



I encourage you to dig into these styles and notice similarities and
help us fix this mess! I'd suggest we start moving the common styles
into a common library in MediaWiki core and change all our extensions
to make use of the same class names. It's a big job but I think we can
get this.


Yes, the way I see it, for simple things like PDF styling, it should 
continue using the common/skin framework.  For "features", like buttons 
and dialog, we seem to be heading towards mediawiki.ui.


Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page title length

[Daniel Friesen]

On 2013-10-24 5:05 PM, Nathan Larson wrote:
> Reposted to https://www.mediawiki.org/wiki/Page_title_size_limitations . 
I cleaned up and cited it. Though in this instance writing up an RFC
quoting the research I did on what needs changing and what kind of
limits we need to understand to pick the maximum title size would have
been better in this instance than a page.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[Steven Walling]

Thanks for doing this Jon.

When I used the Vector version, at first I got an all black screen, which
made me think it was broken. I guess that was just a CSS rule to click and
delete? :)

On Thu, Oct 24, 2013 at 2:43 PM, Jon Robson  wrote:

> 1) We have 6 ways of describing modal windows that take up the full
> screen (click 6 times on that demo to delete these 6 rules and see the
> stuff underneath)
> * .fullscreen
> * .modal_editor
> * #guider_overlay
> * .mw-fullscreen-overlay
> * .mwEmbedPlayer
> * .ui-widget-overlay'
>

Yeah, if we don't have a bug about settling on one overlay style, we
should. This is pretty bad. Maybe the work being done to split out
ve.ui/oo.js/whatever we're calling it might help us settle on a standard?


>  2) We have 4 slightly different ways of describing a blue button
> * body .ui-button.ui-button-blue
>

jQuery.ui


>  * .mw-ui-button.mw-ui-primary
>

mediawiki.ui


>  * .guider_button
>

Extension:GuidedTour. Matt will explain more I'm sure.


>  * button.button.blue
>

This is ULS I believe? The relevant bug is
https://bugzilla.wikimedia.org/show_bug.cgi?id=50599
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Daniel Friesen]

On 2013-10-24 5:04 PM, Steven Walling wrote:
> On Thu, Oct 24, 2013 at 7:04 AM, Dan Andreescu 
> wrote:
>
>> That's really cool Ori.  Have people looked into why jQuery UI gets loaded
>> by default?  It seems to not be used in any obvious way.
>>
> One reason I've heard for doing this is so people can use it content pages.
> We've had requests to do the same for mediawiki.ui. Otherwise, people who
> want to put buttons in Help pages and the like can't use it.
This brings up two points:
A) Instead of relying on defaults we should probably have some parser
function these pages can use to declare that they want mediawiki.ui css
to be loaded.
B) jQuery UI's styling is intended for JS components and hence loaded
via JS. Page contents shouldn't be relying on it.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Matthew Flaschen]

On 10/24/2013 10:04 AM, Dan Andreescu wrote:

That's really cool Ori.  Have people looked into why jQuery UI gets loaded
by default?  It seems to not be used in any obvious way.


Yes.  See https://bugzilla.wikimedia.org/show_bug.cgi?id=0 .  I have 
two patches that together I think should fix it (it did for me locally). 
 One of them has been merged.  The other is ready for review 
(https://gerrit.wikimedia.org/r/#/c/88943/).


Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page title length

[Nathan Larson]

>
> Changing the maximum length of a title will require a huge number of
> changes and is not easy to make configurable so we should do this only
> one time changing the maximum length of title to the maximum we can
> feasibly make it.
>


> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>

Reposted to https://www.mediawiki.org/wiki/Page_title_size_limitations .

-- 
Nathan Larson 
Distribution of my contributions to this email is hereby authorized
pursuant to the CC0 license
.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Steven Walling]

On Thu, Oct 24, 2013 at 7:04 AM, Dan Andreescu wrote:

> That's really cool Ori.  Have people looked into why jQuery UI gets loaded
> by default?  It seems to not be used in any obvious way.
>

One reason I've heard for doing this is so people can use it content pages.
We've had requests to do the same for mediawiki.ui. Otherwise, people who
want to put buttons in Help pages and the like can't use it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[Jon Robson]

Yeh it's bizarre Ori had the same one. It's really strange as I have
the exact same browser as Ori and can't reproduce it. I'm trying to
work out what's going on and push a fix. The version on my website has
a workaround around this issue in the meantime!


On Thu, Oct 24, 2013 at 4:08 PM, MZMcBride  wrote:
> Jon Robson wrote:
>>This script is still very much a proof of concept so if anyone is
>>interested in improving the visualisation I'd encourage you to send me
>>a pull request on github :)
>
> https://github.com/jdlrobson/LivingStyleGuide
>
> I tried this tool very quickly and it seemed to only generate a white
> screen. :-(  My browser error console reports the following:
>
> Uncaught InvalidCharacterError: The string contains invalid characters.
> Uncaught TypeError: Cannot call method 'init' of undefined
> Uncaught ReferenceError: lsg is not defined
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
http://jonrobson.me.uk
@rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HTTP Archive now tracking several Wikimedia wikis

[Bartosz Dziewoński]

On Fri, 25 Oct 2013 01:20:41 +0200, Matthew Flaschen  
wrote:


This is is very interesting.  It seems like we should be able to pull that 1.3 
MB down a bit (I don't think that takes into account gzip, but I'm not sure).  
jquery.ui would be a start (it's not actually used on the main page, but it's 
loaded).  See https://bugzilla.wikimedia.org/show_bug.cgi?id=0


Out of that 1.3 MB, ULS fonts contribute to almost a megabyte (search the 
waterfall for 'amiri'). How was it ever considered acceptable to deploy this is 
beyond me.


--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HTTP Archive now tracking several Wikimedia wikis

[Matthew Flaschen]

On 10/22/2013 06:49 PM, Ori Livneh wrote:

The HTTP Archive () audits the setup and
performance of popular websites, reporting things like load times,
download sizes, performance scores, waterfall charts, and cache
headers. They provide per-site reports as well as aggregate data about
trends in web technology.


This is really great.  It should be especially useful for comparing over 
time.



They added several Wikimedia wikis to their index last month and the
first two reports (dated Oct 1 and Oct 15) are available. The reports
for the desktop site of the English Wikipedia are available here:
.


This is is very interesting.  It seems like we should be able to pull 
that 1.3 MB down a bit (I don't think that takes into account gzip, but 
I'm not sure).  jquery.ui would be a start (it's not actually used on 
the main page, but it's loaded).  See 
https://bugzilla.wikimedia.org/show_bug.cgi?id=0


And it really should be higher, since two requests failed (they show as 
0 size).


Thanks,

Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[MZMcBride]

Jon Robson wrote:
>This script is still very much a proof of concept so if anyone is
>interested in improving the visualisation I'd encourage you to send me
>a pull request on github :)

https://github.com/jdlrobson/LivingStyleGuide

I tried this tool very quickly and it seemed to only generate a white
screen. :-(  My browser error console reports the following:

Uncaught InvalidCharacterError: The string contains invalid characters.
Uncaught TypeError: Cannot call method 'init' of undefined
Uncaught ReferenceError: lsg is not defined

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page title length

[Daniel Friesen]

On 2013-10-24 3:00 PM, Brion Vibber wrote:
> 2) Search around for '255' appearing in .php, .inc, or .js files and change
> the checks to 1023.
>
> You might be able to get away with mostly changing just this bit in
> includes/Title.php:
>
> # Limit the size of titles to 255 bytes. This is typically the size
> of the
> # underlying database field. We make an exception for special
> pages, which
> # don't need to be stored in the database, and may edge over 255
> bytes due
> # to subpage syntax for long titles, e.g. [[Special:Block/Long
> name]]
> if (
> ( $this->mNamespace != NS_SPECIAL && strlen( $dbkey ) > 255 )
> || strlen( $dbkey ) > 512
> ) {
> return false;
> }
>
> Update both the 255 and the 512 check with larger numbers (the 512 check is
> for Special: pages, since they often take other page titles as parameters).
> There's a JavaScript clone of this check in
> resources/mediawiki/mediawiki.Title.js, which should probably be updated
> likewise.
Also either update all user_name fields in the database or update
User::getCanonicalName to use a 255 byte limit instead of depending only
on Title for that.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] FOSS Outreach Program for Women: call for candidates, projects, and mentors

[Quim Gil]

PLEASE FORWARD TO WHOEVER MIGHT BE INTERESTED

Wikimedia will participate in the FOSS Outreach Program for Women - 
Round 7. Interns of this program work full time in an open source 
project during 4 months.


https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women

Candidates interested are encouraged to add themselves to the table at 
https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7#Candidates 
- even if you are still preparing your proposal.


We are actually running late (my fault). The application process is open 
until November 11. The internship period goes from December 10 to March 
10, 2014.


The Wikimedia Foundation is planning to fund up to 8 interns. This is a 
great opportunity for Wikimedia / MediaWiki related projects. Our 
process is quite simple: define a project, find the mentors and go for it!


https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects

https://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors

The previous featured projects and confirmed mentors have been moved 
respectively to the Raw and Bench sections. If you want to participate 
in this OPW round move the entries back to the featured sections.


New projects and mentors are welcome too, of course!

If you have any questions please ask.

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page title length

[Brion Vibber]

On Thu, Oct 24, 2013 at 10:01 AM, Élie Roux
wrote:

> This title is around 90 Tibetan characters, but each caracter being 3
> bytes, it exceeds the limit for title length of 256 bytes that MediaWiki
> has.
>
> So I have two questions:
>
> 1. If I change this limit to 1023 in the structure of the database
> ('page_title' field of the 'page' base), will other things (such as search
> engine) break? Is there a way to change it more cleanly?
>
> 2. Could I propose you to make this limit 1023 instead of 255 (or to make
> it configurable easily)? This would allow at least 256 characters (even for
> asian languages) instead of 256 bytes, which seems more consistant with the
> fact that MediaWiki is well internationalized.
>

As mentioned already in this thread, changing this limit is possible in
theory but . not simple to do reliably, as there are a number of
database columns with the same limitation, and the 255-byte limit
assumption is unfortunately scattered throughout a number of places in the
code.


If you only need to *display* longer-form original page titles on the
article, you might consider using the {{DISPLAYTITLE:}} keyword with
$wgRestrictDisplayTitle disabled to allow fairly arbitrary customizations:

https://www.mediawiki.org/wiki/DISPLAYTITLE#Displaytitle
https://www.mediawiki.org/wiki/Manual:$wgRestrictDisplayTitle


If you really want the full-length titles as the low-level page title, you
might try something like this:

Note that as of MySQL 5.0.3, VARCHAR columns are no longer limited to 255
bytes -- they can go up to 65,535 (or the maximum row size defined for the
table). So it should be possible to change the column definitions... but I
have not tested it and make no guarantees!

1) Before configuring MediaWiki, edit maintenance/tables.sql and change
instances of "VARCHAR(255)" to "VARCHAR(1023)".

2) Search around for '255' appearing in .php, .inc, or .js files and change
the checks to 1023.

You might be able to get away with mostly changing just this bit in
includes/Title.php:

# Limit the size of titles to 255 bytes. This is typically the size
of the
# underlying database field. We make an exception for special
pages, which
# don't need to be stored in the database, and may edge over 255
bytes due
# to subpage syntax for long titles, e.g. [[Special:Block/Long
name]]
if (
( $this->mNamespace != NS_SPECIAL && strlen( $dbkey ) > 255 )
|| strlen( $dbkey ) > 512
) {
return false;
}

Update both the 255 and the 512 check with larger numbers (the 512 check is
for Special: pages, since they often take other page titles as parameters).
There's a JavaScript clone of this check in
resources/mediawiki/mediawiki.Title.js, which should probably be updated
likewise.

There are similar checks for other fields such as the edit comment, which
you might also want to make sure get increased, but that looks like the
most important one.

Be sure *not* to change instances of '255' that are actually color
components or other values -- you can't safely do a mass search and replace!

-- brion


>
> Thank you in advance,
> --
> Elie
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Visualising CSS debt - cleaning up our messy codebase

[Jon Robson]

I think we are all in agreement that the CSS in MediaWiki is a mess
but it's not clear how to solve the mess.

I think I've created a useful bit of JS to visualise this mess and
make a path to solving it clearer.

If you visit:
http://jonrobson.me.uk/lsg/

You will see in the dropdown mediawiki vector styles. This is a CSS
file I created by manually concatenating all CSS files loaded by
default on desktop.

When visualised you see a lot of interesting things:
1) We have 6 ways of describing modal windows that take up the full
screen (click 6 times on that demo to delete these 6 rules and see the
stuff underneath)
* .fullscreen
* .modal_editor
* #guider_overlay
* .mw-fullscreen-overlay
* .mwEmbedPlayer
* .ui-widget-overlay'
2) We have 4 slightly different ways of describing a blue button
* body .ui-button.ui-button-blue
* .mw-ui-button.mw-ui-primary
* .guider_button
* button.button.blue
3) There are 13 different CSS rules for creating a pdf icon next to a link

I've also added mobile styles and styles introduced by visual editor
and if you compare those to the desktop one you'll see we have even
more inconsistencies.

I encourage you to dig into these styles and notice similarities and
help us fix this mess! I'd suggest we start moving the common styles
into a common library in MediaWiki core and change all our extensions
to make use of the same class names. It's a big job but I think we can
get this.

This script is still very much a proof of concept so if anyone is
interested in improving the visualisation I'd encourage you to send me
a pull request on github :)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page title length

[Daniel Friesen]

On 2013-10-24 10:01 AM, Élie Roux wrote:
> 1. If I change this limit to 1023 in the structure of the database
> ('page_title' field of the 'page' base), will other things (such as
> search engine) break? Is there a way to change it more cleanly?
Other things won't break. But the limit is hardcoded into the software
so it won't actually change the limit. However if you change both places
you will encounter bugs unless you make sure to make a huge number of
other changes to the database and also handle user names by either
changing every column that accepts a user name or editing User.php to
use a limit other than what Title uses.

> 2. Could I propose you to make this limit 1023 instead of 255 (or to
> make it configurable easily)? This would allow at least 256 characters
> (even for asian languages) instead of 256 bytes, which seems more
> consistant with the fact that MediaWiki is well internationalized.
Just to clarify (You're switching between 255 and 256 through your
message) it's 255 bytes. The choice of using 255 bytes for title length
wasn't an arbitrary choice. 255 bytes – not characters – was picked
because 255 bytes is the maximum string length that can be represented
using 1 byte. ie: 1 byte (8 bits -> 2^8=265 values not including 0) can
represent the range 0-255 so a varchar uses 1 byte to declare the length
of the varchar's contents. If you use ANY length larger than 255 the
varchar will always require 2 bytes to store the length of the column.

Changing the maximum length of a title will require a huge number of
changes and is not easy to make configurable so we should do this only
one time changing the maximum length of title to the maximum we can
feasibly make it.

  * It's hardcoded in Title::secureAndSplit.
  * User::getCanonicalName will need some extra code to restrict
usernames to 255 bytes as it currently depends on Title to do that.
(And increasing the user name length is far more problematic than
the title length)
  * docs/title.txt and TitleTest.php will need an update.
  * The canonical page.page_title needs an ALTER COLUMN.
  * A number of other core tables will need column alters; (archive,
page, template, image, category)links.(a, p, t, i, c)l_title,
category.cat_title, (lang, iw)links.(l,iw)l_title,
recentchanges.rc_title, and so on.
  * All extensions that store titles in the database will need to do
similar ALTER COLUMN updates or else they will have unexpected errors.
  o It might be worth doing this first. Since a larger varchar
length in the database won't cause any bugs while the software
still uses 255 bytes.


The next (and tbh final) title max length shouldn't be something
arbitrary, we should pick the maximum we can theoretically store (max we
can store with 2 bytes/a 16bit uint and the max we can possibly store
are actually the same thing, at least on MySQL in regards to VARCHAR).

The next step up from 1 byte representing 0-255 is not 0-1023 as you're
thinking. 2 bytes can represent a length of 0-65535 bytes.
However we actually cannot use VARCHAR(65535) for the title. There are a
number of other limits we hit which cap varchar column lengths below
what can be represented with a 16bit uint length.

  * MySQL Has a maximum row length of 65,535 bytes[1]; This includes the
storage of whatever all the columns on the table require in the row
storage.
  * PostgreSQL doesn't seem to have the same max row size issues as
MySQL because it's row max – depending on whether you ask the about
page[2] or wiki FAQ[3] – is either 1.6TB or 400GB. And the column
max size is 1GB.
  * However PostgreSQL seems to say "indexes can not be created on
columns longer than about 2,000 characters"[1]. I don't know the
precise details but it might make our limit 2000 bytes. ((We'll need
some more input on someone who knows PostgreSQL))
  * The varchar WP page[4] says Oracle's limit is 4000 bytes.
  * Before MySQL 5.0.3 VARCHAR colums could only be declared a maximum
of 255. ((This means we'll have to drop support for 5.0.2 and change
our "5.0.2 or later" MySQL requirements to "5.0.3 or later"))
  * MyISAM's index prefix maximum is 1000 bytes and InnoDB is 767
(unless you use a dynamic/compressed field and innodb_large_prefix).
This means that [[A{1000 bytes}A]] and [[A{1000 bytes}B]] cannot
both exist as the index prefix is used to ensure uniqueness. This
limit will be database dependent. And the only fix would be to add a
new column containing a hash of the title text and drop the
uniqueness constraint on page_title.

Deciding the title max we should use will probably need some more
information than what I've gathered so far.

((Side topic: We use `varchar(n) binary` for the title now. However
anyone that feels like changing this to `varchar(n) CHARACTER SET utf8`
needs to be wary that MySQL triples the (n) so it can store " utf8
chars" instead of " bytes that happen to be utf8" so t

Re: [Wikitech-l] Page title length

[Nathan Larson]

On Thu, Oct 24, 2013 at 1:01 PM, Élie Roux wrote:

> Dear MediaWiki developers,
>
> I'm responsible for the development of a new Wiki that will contain many
> Tibetan resources. Traditionnaly, Tibetan titles of books or even parts of
> books are extremely long, as you can see for instance here :
> http://www.tbrc.org/#!rid=**W23922 ,
> and sometimes too long for Mediawiki, for instance the title of
>
> http://www.tbrc.org/?locale=**bo#library_work_ViewByOutline-**
> O01DG1049094951|W23922
>
> , which is
>
> ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་**ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲི**
> ལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་**ཆུན་པོ་
>
> . This title is around 90 Tibetan characters, but each caracter being 3
> bytes, it exceeds the limit for title length of 256 bytes that MediaWiki
> has.
>
> So I have two questions:
>
> 1. If I change this limit to 1023 in the structure of the database
> ('page_title' field of the 'page' base), will other things (such as search
> engine) break? Is there a way to change it more cleanly?
>
> 2. Could I propose you to make this limit 1023 instead of 255 (or to make
> it configurable easily)? This would allow at least 256 characters (even for
> asian languages) instead of 256 bytes, which seems more consistant with the
> fact that MediaWiki is well internationalized.
>
> Thank you in advance,
> --
> Elie
>

Wouldn't ar.title, log_title, rc_title, and so on also need to have their
sizes increased? I didn't see any bug report proposing an increase in page
title size, although there was this one about comment size.
https://bugzilla.wikimedia.org/show_bug.cgi?id=4715
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Jon Robson]

Yes and this is bad.
jQuery UI must die a horrible death... :)

Thanks Ori for highlighting these things and prompting these questions.
I guess https://bugzilla.wikimedia.org/show_bug.cgi?id=47145 is the
closest bug to achieving this.


On Thu, Oct 24, 2013 at 7:04 AM, Dan Andreescu  wrote:
> That's really cool Ori.  Have people looked into why jQuery UI gets loaded
> by default?  It seems to not be used in any obvious way.
>
>
> On Tue, Oct 22, 2013 at 7:07 PM, Ori Livneh  wrote:
>
>> Running mw.loader.inspect('css') in a JavaScript console will now
>> report CSS stats for each active ResourceLoader style module,
>> including the total count of selectors and the percentage of those
>> that match some node in the current DOM.
>>
>> ---
>> Ori Livneh
>> o...@wikimedia.org
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
http://jonrobson.me.uk
@rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code-in: Lua templates

[Quim Gil]

Can someone list at 
https://www.mediawiki.org/wiki/Google_Code-In#Lua_templates one or more 
wikitext templates waiting for a Lua rewrite?


We have currently none. Having 5 would be great. We will fine tune the 
details if/when we get accepted.


Thank you!

PS: I'm going to create similar sections for gadgets and bots in the 
wiki page.


On 10/20/2013 02:53 PM, Quim Gil wrote:

On 10/20/2013 11:11 AM, Mark Holmquist wrote:

A little warning: where a task can be split into multiple modules, try
to make the modules reusable by other modules easily.


We can't expect newcomer students to know that, therefore the trick is
that someone knowing better modules available around document this in
the specific task of a template.

The typical description of a Lua template task could be organized like this:

1. Common short intro: MediaWiki templates

2. Common short intro: Wikitext vs Lua templates

3. Specific short intro: Template:XYZ

4. Optional specific instructions e.g. include Module:123

5. Common instructions for deployment and testing.




--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bugzilla Weekly Report

[Greg Grossmeier]

[Sorry for the late reply, this sat (finished) in drafts for too long.]


> I was creating the charts manually, it took just a few minutes every week.
> I knew it would take way more time if I started playing with scripts and
> tools. I have already created a bug[1] to automate the process, but I am
> not sure if that would be a good investment of time, since I do not know if
> anybody looks at the charts.

Personally, I think they'd be used/viewed (more) if they were made into
a BZ dashboard (on the bz domain, doesn't have to be a BZ-managed page,
just a static HTML file would work initially).

Thats the thing I miss most from tools like Launchpad: higher level
views into the data. Right now, our only option tends to be custom
reports for every tool we have, which is kind of annoying as non of the
tools talk to each other (reliably/easily) 

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Page title length

[Élie Roux]

Dear MediaWiki developers,

I'm responsible for the development of a new Wiki that will contain many 
Tibetan resources. Traditionnaly, Tibetan titles of books or even parts 
of books are extremely long, as you can see for instance here : 
http://www.tbrc.org/#!rid=W23922, and sometimes too long for Mediawiki, 
for instance the title of


http://www.tbrc.org/?locale=bo#library_work_ViewByOutline-O01DG1049094951|W23922

, which is

ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲིལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་ཆུན་པོ་

. This title is around 90 Tibetan characters, but each caracter being 3 
bytes, it exceeds the limit for title length of 256 bytes that MediaWiki 
has.


So I have two questions:

1. If I change this limit to 1023 in the structure of the database 
('page_title' field of the 'page' base), will other things (such as 
search engine) break? Is there a way to change it more cleanly?


2. Could I propose you to make this limit 1023 instead of 255 (or to 
make it configurable easily)? This would allow at least 256 characters 
(even for asian languages) instead of 256 bytes, which seems more 
consistant with the fact that MediaWiki is well internationalized.


Thank you in advance,
--
Elie

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Daniel Friesen]

On 2013-10-24 9:19 AM, Brad Jorsch (Anomie) wrote:
> The claimed problem behind a lot of this is "too many dependencies"
> making things hard to test and the idea that you can somehow make this
> go away by dividing everything into tinier and tinier pieces. To some
> extent this works, but at the cost of making the system as a whole
> harder to understand because you have to track all the little pieces.
> I doubt MediaWiki has reached the point of diminishing returns on
> that, but I'm not really sure that the end-goal envisioned here is the
> *right* division.
Then there's the potential that individually testing a bunch of
components doesn't always match what happens in the actually used code
that puts everything together. So in the end you either have to also
test the thing as a whole anyways. Or you end up with unit tests that
are even less useful than you started because they won't catch
regressions they would've originally.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Brad Jorsch (Anomie)]

On Thu, Oct 24, 2013 at 12:04 AM, Chad  wrote:

> On Wed, Oct 23, 2013 at 8:44 PM, Tyler Romeo  wrote:
>
> > On Wed, Oct 23, 2013 at 10:54 PM, Chad  wrote:
> >
> > > I've personally not been convinced of this Value/Parser/Formatter
> pattern
> > > but if I'm the only one I'll just keep my big mouth shut
> > >
> >
> > I agree with this as well. The idea behind this RFC is the "hair can't
> cut
> > itself" pattern.
>
> I wish my hair could cut itself ;-)
>

Maybe my hair can't cut itself, but I can cut my own hair without having to
find a Barber instance. ;)


Looking at the RFC itself, it does seem to be following the "kingdom of
nouns" model Maxsem linked to. And it has a maze of twisty little objects,
all different, that tends to concern me in these proposals. Why do we need
a separate TitleParser and TitleFormatter? They use the same configuration
data to do complementary operations. And then there's talk about making
"TitleFormatter" a one-method class that has subclasses for every different
way to format a title, and about having a subclass for wikilinks (huh?)
which has subclasses for internal and external and interwiki links (wtf?),
and so on. High-level methods to actually do anything useful like "move a
page" or "parse some wikitext" seem like they are going to need to take
dozens of these objects to be able to actually do what they need to do.
(And yes, I know the argument is that then the useful function should be
split into multiple smaller functions with fewer arguments, to which I
reply "you just pushed the problem up the call stack, you didn't solve it").

So then the RFC proposes a "ServiceRegistry" to try to get around this
problem of everything requiring dozens of arguments. But after observing
that RequestContext already *is* this, it then argues against using
RequestContext on the basis of additional dependencies. The logical
extension of this argument is that we're not really talking about a
"ServiceRegistry" here, we're talking about a "TitleServiceRegistry" and
then we'd also have a "RevisionServiceRegistery", "PageServiceRegistry",
"UserServiceRegistry", and so on, trying to pretend there is no forest
because we can point to all the individual trees. Why not have one
ServiceRegistry, maybe even part of RequestContext, and use it
preferentially for passing services instead of just as a fallback? Do we
really have the need for multiple differently-configured services all over
the place in "real" code that we need to be passing them around
individually, or is it just for testing where we could as easily solve the
problem by creating a registry instance that throws errors for all the
services not needed for each test?

Somewhere in this thread someone claimed that we shouldn't have code that
processes user input and then does something and then formats the output,
presumably because each of those should be their own "tree". So how then
does any end user actually do anything? At the top level something *does*
have to do all three things, even if it does it by calling into various
"trees" and each of those trees has its own branches and each branch has
its own twigs and so on.

The claimed problem behind a lot of this is "too many dependencies" making
things hard to test and the idea that you can somehow make this go away by
dividing everything into tinier and tinier pieces. To some extent this
works, but at the cost of making the system as a whole harder to understand
because you have to track all the little pieces. I doubt MediaWiki has
reached the point of diminishing returns on that, but I'm not really sure
that the end-goal envisioned here is the *right* division.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mw.inspect: new CSS report

[Dan Andreescu]

That's really cool Ori.  Have people looked into why jQuery UI gets loaded
by default?  It seems to not be used in any obvious way.


On Tue, Oct 22, 2013 at 7:07 PM, Ori Livneh  wrote:

> Running mw.loader.inspect('css') in a JavaScript console will now
> report CSS stats for each active ResourceLoader style module,
> including the total count of selectors and the percentage of those
> that match some node in the current DOM.
>
> ---
> Ori Livneh
> o...@wikimedia.org
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Antoine Musso]

Le 24/10/13 11:40, Max Semenik a écrit :
> Now:
> 
> $title = Title::newFromText( $text );
> if ( $title ) {
>  return $title->getLocalUrl( 'foo=bar' );
> }
> return null;
> 
> Proposed:
> 
> $tp = new TextTitleParser();
> try {
> $title = $tp->parse( $text );
> $tf = new UrlTitleFormatter( $title, 'foo=bar );
> return $tf->format();
> } catch( MWException ) {
> return null;
> }

Since I am lazy, I would want:

  return Title::newFromText( $text )
 ->getLocalUrl( 'foo=bar ');

Aka make Title::newFromText() to always return an object having the
methods neededs, albeit when the $text does not form a title, it would
yield a NullTitle objet that has calls returning nothing (or other
NullTitle object).

Less fatal errors.

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Jeroen De Dauw]

Hey,

Proposed:
>
> $tp = new TextTitleParser();
> try {
> $title = $tp->parse( $text );
> $tf = new UrlTitleFormatter( $title, 'foo=bar );
> return $tf->format();
> } catch( MWException ) {
> return null;
> }
>

I hope this is your own interpretation of what would happen on top of what
is proposed and not what is actually proposed, since this code snippet has
some issues.

Those parser and Formatter objects contain configuration specific state. If
you instantiate them like this, you are creating code that is just as bad
as Title::newFromText, where this newFromText method relies on similar
config specific state. In both cases you are using global state and
programming against concretions.

Does the RFC also sate exceptions should be used rather than returned error
values? Seems like a quite disjoint concern to me. And if you use
exceptions, please use them properly and do not copy-paste MWException all
over.

This example also seems rather fabricated and not representative of most
use cases. Ignoring the points above, it strikes me as only making sense in
a transaction script, ie something which goes from handling user input
(such as parsing a title), through domain logic (altering a title), to
presentation (ie formatting a title). Given what MW does, it is much more
likely any particular piece of code only resides in one layer, rather then
3. Though I can imagine how we have lots of code that for no good reason
does this anyway, quite plausibly prompted by the fact that the Title
object caters to all 3 layers.

I read that as namespaces other than the one you're obviously referring
> to with a TitleValue--so Category:Foo only knows about Category:, not
> Project: or User:.
>
> Maybe someone can clarify here?
>

It is good to have a value object to not be dependent on configuration, so
instances of it do not get messed up if the config is changed. So
presumably in this case it'd contain an int, rather then an
internationalized sting or whatever.

Also,
> http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>

I stopped reading at

All Java people love "use cases"
>

Perhaps you could summarize what the RFC in question does wrong according
to the post you linked?

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Refactoring the Title object

[Max Semenik]

On 24.10.2013, 6:54 Chad wrote:

> On Wed, Oct 23, 2013 at 7:39 PM, Tim Starling wrote:

>> I'm inclined to accept this RFC, except perhaps with minor changes. It
>> would be nice if I could get some comments on it from someone other
>> than me or Daniel, but if nobody else has anything to say, I will just
>> accept it.
>>
>>
> I've personally not been convinced of this Value/Parser/Formatter pattern
> but if I'm the only one I'll just keep my big mouth shut.

My main problem with this proposal is that it aims to make us all very
good typists, by making every popular operation much more verbose.

Now:

$title = Title::newFromText( $text );
if ( $title ) {
 return $title->getLocalUrl( 'foo=bar' );
}
return null;

Proposed:

$tp = new TextTitleParser();
try {
$title = $tp->parse( $text );
$tf = new UrlTitleFormatter( $title, 'foo=bar );
return $tf->format();
} catch( MWException ) {
return null;
}

Which of them is more clear? Writing which of them you're less likely
to introduce errors?

Also, http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Code-in: are you in?

[Guillaume Paumier]

Hi,

On Thu, Oct 10, 2013 at 7:51 PM, Quim Gil  wrote:
>
> But of course this will only work if many projects want to step in with a
> task and a mentor for it. So what do you think?

This was the perfect opportunity to create the long-overdue task list
around tech communications:
https://www.mediawiki.org/wiki/Technical_communications/What_you_can_do

According to what has been said in this thread, the Translation bit
may not work for Code-in, but I expect the rest to be in scope. I'll
be available as a mentor for all those tasks and I can be responsive
over week-ends and holidays (timezone permitting).

If others see possible tasks on this topic that I didn't include or
think of, edit the page liberally and we'll [[WP:BRD]] if needed.

-- 
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l