On Apr 26, 2012, at 2:25 AM, Ryan Kaldari wrote:
Krinkle and I went back and forth on this one last year. Apparently, it's a
bit of a bootstrapping problem since all of our comments are currently
written the wrong way (due to an old bug in doxygen that has since been
fixed), and thus our
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already
On May 3, 2012, at 5:28 AM, Krinkle wrote:
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https
. That way things won't break if a version or
milestone is renamed and new ones are automatically added.
-- Krinkle
[1]
https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/c5611c966112d1eb8ff63a5651c7729161cd265a/index.php#L40
[2]
https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob
Some of the ops that fullfill shell requests paste diffs into BugZilla comments,
which is awesome.
Hereby friendly request to those (and others!) to, from now on, paste links to
gerrit change sets (or gitweb commits) - for easy reference :)
-- Krinkle
On May 10, 2012, at 1:55 AM, Patrick Reilly
The MWNightly tool has been down for a while (since February, around migration
to Git), so I took the liberty to write a new tool for this.
https://toolserver.org/~krinkle/mwSnapshots/
Updates hourly, even.
With Git making packages of a repository is a lot easier, but for those without
On May 10, 2012, at 4:04 AM, Liangent wrote:
On Thu, May 10, 2012 at 8:45 AM, K. Peachey p858sn...@gmail.com wrote:
On Thu, May 10, 2012 at 10:41 AM, Krinkle krinklem...@gmail.com wrote:
Some of the ops that fullfill shell requests paste diffs into BugZilla
comments,
which is awesome
On May 10, 2012, at 8:32 AM, Thomas Gries wrote:
Am 10.05.2012 02:57, schrieb Krinkle:
The MWNightly tool has been down for a while (since February, around
migration to Git), so I took the liberty to write a new tool for this.
https://toolserver.org/~krinkle/mwSnapshots/
Updates hourly
the boxes underneath
next to the first two on the first row.
This example is for example about a table-code layout vs. row containers with
floating elements.
-- Krinkle
[1] Note that at the time (maybe still today) those [expand]/[collapse] buttons
from those Wikipedia templates are shown regardless
wouldn't be needed (you'd click a few buttons and have it). Take a look at a
GitHub project issue tracker. All it has is titles, assignee, milestone,
open/close and labels. And all can be queried from the overview with a single
click.
-- Krinkle
[1] I know that many of these can be disabled
no such bug or
limitation, and in MediaWiki it will work just fine.
Not sure how that link is relevant..
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On May 14, 2012, at 5:04 AM, K. Peachey wrote:
On Mon, May 14, 2012 at 12:55 PM, Krinkle krinklem...@gmail.com wrote:
I'm convinced all other fields can be done without and removing them will
improve the workflow of the developers and the Bugmeister. Including, but not
limited to:
- Platform
s = document.createElement('script'); /* ... */ }())}
You get the idea..
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or an assignee
available).
For myself I created a little portal to make working with our current workflow
easy (for MediaWiki core that is).
https://toolserver.org/~krinkle/wmfBugZillaPortal/
On May 22, 2012, at 4:05 AM, Yuvi Panda wrote:
Also, Tracking bugs let us make comments about the release
to the url,
then check the browser console again.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Manual:How_to_debug
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I couldn't get it to update (Mac OS X).
Reported in Bugzilla: https://bugzilla.wikimedia.org/37135
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
] in labsconsole).
-- Krinkle
[1] simpel pages such as https://labsconsole.wikimedia.org/wiki/Deployment/Help
although probably under a different name.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
complicated to use, but provides a lot of features.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or labsconsole, so
nevermind.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
suite to his repository.
Ready
to be expanded and build upon!
-- Krinkle
[1] https://github.com/santhoshtr/CLDRPluralRuleParser
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jun 21, 2012, at 7:13 AM, Krinkle wrote:
On Jun 20, 2012, at 1:02 PM, Niklas Laxström wrote:
No, this is not about a wikitext parser. Rather something much simpler.
Have a look at [1] and you will see rules like:
n in 0..1
n is 2
n mod 10 in 3..4,9 and n mod 100 not in 10..19,70
the flood for support,
while keeping them in the relevant context of developers and conversations.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/Category:Tutorials
I could also (co-)host that or another session regarding front-end unit testing.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
reports back to Gerrit (our code
review tool)
with a comment linking to the test results and a flag PASSED or FAILED.
For example: https://gerrit.wikimedia.org/r/#/c/13037/ (jenkins-bot)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
they cause problems
* how to solve that (and how the solution is indeed better for everyone)
... then is is a matter of spreading links to that documentation and waiting
for it to be incorporated on the 700+ wikis with the many many portal pages,
and other structures that have bad layouts.
-- Krinkle
awesome!
-- Krinkle
On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber br...@pobox.com wrote:
On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:
So, stripping inline styles:
* will not fix bad layouts made with tables (which are probably at least as
common as bad layouts made
if this sounds crazy, but you could do git review -d 1234
and test it that way.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to
be checked out.
I agree with Chad, there is no problem with an actual testing branch, but if
we can avoid it with an (what could be) a better workflow with less overhead of
rebasing, dependency manipulation and double-merging etc. then..
-- Krinkle
On Fri, Jun 29, 2012 at 1:23 PM, Krinkle krinklem
, just curious. I'm not vouching for or against it.
Thank you!
-greg aka varnent
Thank you!
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it is for. When we are planning to deploy something
that requires wikis to change something, we'd reach out through those
ambassadors who translate it into their own wiki (if needed) and do or make
sure is done, whatever needs doing.
-- Krinkle
___
Wikitech-l
best to always work in a topic branch, keep master clean, and do simple
pulls from gerrit/master.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Have you looked at the example extensions?
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/examples.git;a=tree
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
it.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
by default,
that could be a very useful feature. I'll leave that up to someone else more
involved to comment about.
[1] https://en.wikipedia.org/wiki/Template:Persondata
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
amendment will be in the master's history (which is just as much a squash,
except that that squash is the result if re-ammending over and over again,
instead of subsequent commits being squashed afterwards).
-- Krinkle
[1] branch-review model, as in, a model where a review is about a
topic-branch
simple ways for improving Gerrit
The 7--+1 simple ways for improving Gerrit.
After 5 comes 6, you know ;-)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We already have hourly snapshots of the stable master though:
https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master
(and it includes release branches, feature branches and wmf branches).
That could be expanded to keep old version (right now it only keeps the
latest one
be generated on demand.
-Chad
That's why I created mwSnapshots are a replacement for vvv's mw-nightly
(which, before it was taken down, afaik still only worked with SVN).
https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master
And it does cache :)
-- Krinkle
and will (at least for a long while to come) support both. Even more
because the default set up out of the box is /w/index.php/Page_name, and
the only way we can make sure existing wikis don't break is by supporting
this.
-- Krinkle
___
Wikitech-l mailing
:
Didn't we solve this already by being able to pass a version to
wfDeprecation() and allowing users to set $wgDeprecationReleaseLimit to
hide/show from whatever cut-off point they desire?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
Regarding how to calculate the line-width (for the 80-100 convention), the
way my old editor used to do it made the most sense to me: Consider a tab 1
character (because it is).
That also gives the most flexibility in indenting/outdenting blocks without
having to worry frequently about it being
.
Are JavaScript/CCS are really updated so often?
Eugene.
Can you elaborate a bit? (urls, timestamps, http headers, ..)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/show_bug.cgi?id=39158
Would be awesome if someone that is familiar with this stuff can have a
look at it :)
Cheers
This is part of the Vector extension.
Use option useeditwarning.
-- Krinkle
[1] https://www.mediawiki.org/wiki/Extension:Vector
Okay, sorry for being away for 30 minutes while I enjoyed dinner.
Someone[1] pointed me to this thread and suggested I chime in, so here I go.
On Aug 28, 2012, at 2:50 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote:
Either way $( 'div' ) is NOT something officially supported by jQuery
that. And if in
doing so we saving revision space, that's nice.
Other examples:
* https://commons.wikimedia.org/wiki/Commons:Database_reports (and subpages)
* https://commons.wikimedia.org/wiki/Commons:Auto-protected_files (and subpages)
-- Krinkle
accurate and
explains the full change (not just the first version of the patch, nor just the
last amendment to the patch).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Indeed, this is by design on GitHub.
These kind of rules need to be socially applied and controlled.
There is no way to prevent it mechanically through GitHub.
Common agreement between developers, prior to granting access, of course.
-- Krinkle
there is a preference is set for
gadget- + gadgetId.
It may be useful to require a server side registry, for Gadgets this wouldn't
be an issue since
all gadget Ids are known. For backwards compatibility array_keys of
wgDefaultOptions could
be registered automatically / implicitly.
-- Krinkle
: true
});
};
/code
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
that this message is not wiki-content, it doesn't make sense to
truncate it. It simply needs to be shortened at the source. The interface
messages in question are (from ApiWatch.php):
* addedwatchtext [1]
* removedwatchtext [2]
removedwatchtext is short and to the point.
-- Krinkle
[1] https
another problem: Resizing the window. The spreading of
messages over multiple columns would have to either be re-build after resizing
the window.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
, the standard will include a natural fallback by
storing the 1-0 ratio image in the src attribute. Which is what we'd want on
older browsers/devices anyway.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
it should appear inside the interface where
it was performed?
Anyway, just my 2 cents :)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
are very specific and targeted at their purpose.
By replacing a single align attribute with all kinds of inline styles the
original intention of that align attribute will be lost at the cost of a lot of
bloat in the output that we don't really need anyway.
-- Krinkle
whether fixes for those issues are
already included or not? Most important is
https://gerrit.wikimedia.org/r/#/c/23900/
That commit is not included. I can merge it in or make a second RC with
1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
-- Krinkle
On Sep 22, 2012, at 9:31 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote:
On Sat, 22 Sep 2012 00:10:11 -0700, Isarra Yos zhoris...@gmail.com wrote:
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct
consequence of a user
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger m...@everybody.org wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger m...@everybody.org wrote:
That commit is not included. I can merge it in or make a second RC with
1.20wmf12.
What do you
On Sep 23, 2012, at 8:03 PM, Mark A. Hershberger m...@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
Also, this bugzilla query should be empty before release as well (either by
fixing bugs,
or reviewing/merging pending commits that claim to fix stuff, or deferring
the bug
proven itself by being used over a long period of time by other extensions.
I mean, things don't have to be in core to be usable. Let it be an extension,
let it grow. Extensions can perfectly depend on other extensions, there is no
need to have it be in core, make your own decisions.
-- Krinkle
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxst...@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklem...@gmail.com wrote:
Another problem I found in the current setup is that its a bit
counter-intuitive how to manage the directory structure for developers. I
mean, most
common way to categorize bot edits in analytics (unless only
covering recent data).
There is an open bug to store the bot flag in the revision table, thus making it
permanently available[2].
-- Krinkle
[1] For example on Commons, where I am a sysop, there is a bot I ran that edits
sysop
for it.
+1 :-)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
a good idea, never.
The solution I'd propose (and Daniel also mentioned this various times here and
elsewhere) to output checkboxes as fallback and an interface like jQuery
Chosen
as enhancement.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
On Oct 2, 2012, at 4:25 PM, Chris McMahon cmcma...@wikimedia.org wrote:
I am pleased to announce that Željko Filipin joins WMF this week as QA
Engineer.
Welcome Željko!
For the last 1.5 year, hashar and I have set up the current integration
environment. I'm also in CET (Krinkle on freenode
, and following
current conventions for front-end code with mw and jQuery).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/ everywhere is obvious (it should have
one or two assertions to make sure the other behaviour is also tested), no need
to duplicate the entire test suite 2 or 3 times for unimportant details.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
them in core. Because
that wouldn't be an improvement over the current situation.
If we have good ground to remove them (because they're silly options that we
don't want end-users to be thinking about), then we remove them. Don't move
them from one junkyard to another.
-- Krinkle
[1] https
of as a minor oddity that
should be removed as a bug.
We know now that (though it might have been a bug originally) it is a major
feature that unless replaced, must not be removed.
-- Krinkle
[1] https://bugzilla.wikimedia.org/41155
___
Wikitech-l
whenever you feel like.
-- Krinkle
[1] I intend to remove them separately, not all at once. So if support for a
few is shown, I'll still remove the rest. Please reply complete (e.g. I use X
will mean I keep X, it won't mean I leave Y and Z as well
that only omits RESOLVED/**.
@AndreKlapper: What do you think?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
/buglist.cgi?resolution=---query_format=advancedproduct=MediaWikitarget_milestone=1.20.0%20releaselist_id=157827
Zarro Boogs found.
Nice :)
-- Krinkle
[1] https://toolserver.org/~krinkle/wmfBugZillaPortal/ (version 1.20 open regr.
milestone 1.20.0 open
On Nov 6, 2012, at 2:44 PM, Andre Klapper aklap...@wikimedia.org wrote:
On Tue, 2012-11-06 at 02:24 +0100, Krinkle wrote:
We have the following indications that should be used instead:
* blockers / dependencies
* status ASSIGNED
* keyword upstream
* priority low or lowest
* severity minor
) {
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Or better yet, since this is supported by jQuery core for a while now, like
this:
$(el).css('opacity', 0.5);
Which will do the right thing for newer browsers and old IE respectively.
-- Krinkle
[1] http://api.jquery.com/jQuery.browser/
[2] http
* https://www.mediawiki.org/wiki/Git/Workflow
* https://www.mediawiki.org/wiki/Git/Tips
* https://www.mediawiki.org/wiki/Gerrit
* https://www.mediawiki.org/wiki/Gerrit/Navigation
+ https://www.mediawiki.org/wiki/Git/Gerrit
-- Krinkle
___
Wikitech-l mailing
working outside MediaWiki and need it is good enough for you,
you'd copy and paste those dozen or so lines. Or (after jQuery 1.9 is released)
simply load the jquery-compat version on your web page.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
,cyrillic,latin-ext
More about protocol-relative:
http://paulirish.com/2010/the-protocol-relative-url/
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
legal team of this infringing use.
Erik
Also, http://www.wi.ki/ violates the terms of the creative commons license:
https://commons.wikimedia.org/wiki/File:Wikipedia_mini_globe_handheld.jpg
https://creativecommons.org/licenses/by-sa/3.0/deed.en
-- Krinkle
master branch should
support 1.21 and 1.22-alpha (if and until the extension maintainer
decides that compatibility needs to be broken and makes a
REL1_21 branch).
-- Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=37946
___
Wikitech-l mailing
.
Extensions that aren't maintained, aren't maintained.
As a start, I created a REL1_20 branch for extensions that were bundled with
1.20.0.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
Hey all,
For a while now we have .jshintrc rules in the repository and are able
to run node-jshint locally.
TL;DR: jshint is now running from Jenkins on mediawiki/core
(joining the linting sequence for php and puppet files).
I cleaned up the last old lint failures in the repo yesterday in
to Gruntjs and have
migrated to Zuul (instead of Gerrit Trigger), we can easily create a catch-all
job for any repositories that don't have a dedicated job which would simply
execute grunt lint (aka the Universal Linter) that will run phplint,
jshint, csslint, puppetlint etc.
-- Krinkle
On Nov 21
editors have their own (possibly outdated) copy of jshint (I know
SublimeLinter had an old version for a while). If you have node-jshint
installed, I'd recommend configuring the linter plugin of your editor to shell
out to your version of jshint (if it supports that).
-- Krinkle
should be set in the Assigned to field.
I'd recommend we also require a Milestone to be set for Highest
priority tickets.
That way it is clear to both the assigned developer and the community
what the expectations are.
-- Krinkle
___
Wikitech-l mailing
://bugzilla.wikimedia.org/show_bug.cgi?id=15936 which I hope
will be solved though it's not a show stopper, as long as there is any
way at all to get there (even if it requires to go to
Special:RecentChanges) that would be an incredible improvement to the
current situation).
Greetings,
Krinkle
[1] https
://en.wikipedia.org/wiki/mw:DB
This one doesn't and only works when done from within a page (like
[[mw:DB]]) becuase iw_local is 0.
I think the Special:Search entry is a bug / undocumented feature in
that it ignored the 'local'-setting.
--Krinkle
[1] http://www.mediawiki.org/wiki/Manual:Interwiki_table
Op
as there is any
way at all to get there (even if it requires to go to
Special:RecentChanges) that would be an incredible improvement to the
current situation).
Greetings,
Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=9501
[2]
http://commons.wikimedia.org/wiki/Commons:Village_pump
'edge' those edge cases are, and on how much they are
known.
Doing that would may render it unusable for established wikis and
would never become the default anytime soon, right ?
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Perhaps the new installer could contain that as an option during the
inital setup.
Like a two or three-column thing with a bunch of checkboxes.
Language: English [\/]
Default theme (X) Vector (_) Monobook (_) Foobar
Common Extension: [X] ParserFunctions [X]
etc. you get the idea
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
things like {{FA|xx}} and {{Commonscat|Foobar}} for
indicating Featured articles and interprojects can be transcluded
along aswell.
--
Krinkle
Op 11 okt 2010, om 23:50 heeft Strainu het volgende geschreven:
2010/10/11 Marcus Buck w...@marcusbuck.org:
An'n 11.10.2010 20:13, hett Strainu
=wikitable in
order to work
with the CSS definitions in MediaWiki.
Just thought I'd let you know :)
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
as possible (a little abstraction is
likely required,
but shades and gradients are possible in Vector too!).
Altough it looks like an automated pixel-to-vector conversion, the
idea is quite clear
in the following file:
http://commons.wikimedia.org/wiki/File:MediaWiki.svg
--
Krinkle
a problem though.
I must say I reallylike the general flow of the thing!
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
in the pre-commit file.
Oh the irony.
-Chad
if/when this is enabled. Does this require anything from the commiters ?
Do I need to install something or run a command in addition to or
instead of 'svn commit -m ' ?
Sounds nice as an additional check :)
--
Krinkle
,
with a link to an MW.org page with an overview of a few things that
regulars may want to know (ie. the most common differences).
Just an idea :)
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
and has been default on several wikis for a
long while.
--
Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm getting blank pages after adding that (in Safari, Mac).
I tried using importScriptURI'ing it but to no luck. I presume because
the script internally calls more document.writes.
--
Krinkle
Op 1 jan 2011, om 13:50 heeft Magnus Manske het volgende geschreven:
For the impatient, add
projects is, what are
the ultimate goals, which are closest to it ?
Then import from others to it to make one awesome thing.
Personaly I also prefer the non-WYSIWYG editing style. In other words:
Showing what things are but staying in (in)direct contact
with wikitext.
--
Krinkle
101 - 200 of 483 matches
Mail list logo
