Later today, at 2300 UTC, we'll be in #wikimedia-office discussing Pau
Giner's grid system RfC.
https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system to
simplify the creation of user interfaces and make them ready for multiple
screen sizes.
Check out the new patchset
On Sun, Jun 1, 2014 at 2:57 PM, Petr Bena benap...@gmail.com wrote:
Yes there has been an update recently, we released 3.0.0 :)
I totally agree, actually ubuntu users can install run huggle using
1 line in terminal, and a goal is to have it as much accessible for
everyone as possible
On Fri, May 30, 2014 at 3:56 PM, Bryan Davis bd...@wikimedia.org wrote:
There is still some ongoing internal discussion about the best way to
verify that included libraries are needed and that security patches
are watched for and applied from upstream. Chris Steipp is awesome,
but it would be
2014-05-30 0:57 GMT+03:00 Bryan Davis bd...@wikimedia.org:
I think bug 65188 [0] is the solution suggested by Ori that you are
referring to. Would this alone be enough to fix the problems for
translatewiki.net? More directly, is translatewiki.net using the top
level composer.json file to
Am 30.05.2014 15:38, schrieb Brad Jorsch (Anomie):
I think you need to look again into how FlaggedRevs uses it, without the
preconceptions you're bringing in from the way you first interpreted the
name of the variable. The current behavior makes perfect sense for that
specific use case.
To make things worse, I noticed on my development environment that our
own scap-equivalent will just go on to run composer update even if the
file conflicted. This causes it to remove the extensions and libraries
we currently install via composer, also breaking the site.
I hope for the sake
On 1 June 2014 22:45, Daniel Friesen dan...@nadir-seen-fire.com wrote:
What kind of decoupling did you have in mind?
Not specifying that each skin has to have exactly one lc identifier
and then starting to rely on this requirement and generate all sorts
of secondary names, identifiers, paths,
What kind of decoupling did you have in mind?
Not specifying that each skin has to have exactly one lc identifier
and then starting to rely on this requirement and generate all sorts
of secondary names, identifiers, paths, class names, etc. from that.
E.g why not just ask that skin for it's
Hello,
I have created a new Jenkins job 'php-composer-validate' which invokes
'composer.json' on a proposed change and bails out whenever it is faulty.
The change is only triggered on changes that modify composer.json.
To have the job triggered on your repository, you would have to edit
Zuul
Hi,
On Mon, 2014-06-02 at 11:36 +0900, ikuyamada wrote:
It seems that the page view stats have not been uploaded for several days.
http://dumps.wikimedia.org/other/pagecounts-raw/2014/
Are there any plans to fix this?
See https://bugzilla.wikimedia.org/show_bug.cgi?id=65978
andre
--
Andre
A grid system for content authors would be useful as well. There have
been some discussions about better semantic markup for image widths
and placement as part of the change to image thumbnail sizing which
landed last week and was reverted yesterday.
This doesn't seem to be included in the
Hi,
I'm looking for someone to review and (hopefully) accept a very small (3
line) patch I wrote for the ImageMap extension. The patch improves the
behavior of image maps with links to [[Media:...]] files. Instead of
linking to the image page, these links should go directly to the media file
Hey,
To make things worse, I noticed on my development environment that our
own scap-equivalent will just go on to run composer update even if the
file conflicted. This causes it to remove the extensions and libraries
we currently install via composer, also breaking the site.
I hope for
Hey all,
I got this e-mail because of my participation at various PHP and open source
conferences. However, this new conference is more trying to focus around the
PHP ecosystem of applications (MediaWiki, Wordpress, Drupal, …) which for a
long time have had their own separate conferences
IANA grid expert, but I think it would be a huge missed opportunity not
to let this be used for content. It could be a great help with pages like
Portals, which are currently reliant on loads of inline styles for layout,
or worse, tables.
Peter
On 2 June 2014 15:39, C. Scott Ananian
Some newer RfCs that you ought to know about, mostly draft-ish and in
progress. Please comment on their talkpages.
* https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication
With many more entry points and the need for inter-service
authentication, a service-oriented architecture
This is in about 50 minutes, in #wikimedia-office.
-Sumana
On 06/02/2014 02:14 AM, Sumana Harihareswara wrote:
Later today, at 2300 UTC, we'll be in #wikimedia-office discussing Pau
Giner's grid system RfC.
https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system to
simplify the
The third (and hopefully final) release candidate for 1.23.0 (1.23.0-rc.3) is
now available for download.
The changes since 1.23.0-rc.2 are as follows:
* (bug 65225) jquery.suggestions: Handle CSS ellipsis better for IE.
* (bug 65765) Add ar_text to the list from
* https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication
With many more entry points and the need for inter-service
authentication, a service-oriented architecture requires a stronger
authentication system.
This is literally the same thing as AuthStack except more generic and
I would also like to express my disappointment at third party users being
thrown under the bus once again. Several people have been putting a lot of
effort into supporting third party users, so it really saddens me that this
is dismissed as an irrelevance by some so easily.
Third party users were
That is just the unfortunate truth. We are
not going to misuse libraries and hack together MediaWiki just so extension
installation can be *slightly* easier.
This sort of behaviour towards non-WMF extension developers is
interesting and if your objective is to alienate (as with the attitude
This sort of behaviour towards non-WMF extension developers is
interesting and if your objective is to alienate (as with the attitude
above) volunteer developers then your on the right path.
Some people forget that users not always choose MW because of its
software but because it provides some
On Mon, Jun 2, 2014 at 6:37 PM, James HK jamesin.hongkon...@gmail.com
wrote:
That is just the unfortunate truth. We are
not going to misuse libraries and hack together MediaWiki just so
extension
installation can be *slightly* easier.
This sort of behaviour towards non-WMF extension
23 matches
Mail list logo
