I may have stumbled upon it. If I change the API call from
"titles=File:XYZ.jpg" to "titles=Template:XYZ" (note: dropped the .jpg)
then it *appears* to get me what I need.
Is this correct, or did I run across a case where it appears to work but
isn't going to be the right way to go? (Like, I'm n
Hoi,
The good news is that work on the "Wikidatafication" of multimedia files
has started. You just provided an excellent example why it is so needed.
One drawback is that once it is done, your current work will need to be
revisited.
Thanks,
GerardM
On 3 June 2014 07:59, james harvey wrote
Given a Wikimedia Commons description page URL - such as:
https://commons.wikimedia.org/wiki/File:Van_Gogh_-_Starry_Night_-_Google_Art_Project.jpg
I would like to be able to programmatically retrieve the information in the
"Summary" header. (Values for "Artist", "Title", "Date", "Medium",
"Dimens
On Mon, Jun 2, 2014 at 6:37 PM, James HK
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 developers is
> interest
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 ext
> 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
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 n
* 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 with
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 Revision::selectArchiveFields().
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 cr
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 re
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 wrote:
>
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 (Berli
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 h
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
(comp
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 curren
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
--
An
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 co
>> 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
> 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 sak
On 1 June 2014 22:45, Daniel Friesen 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, class names, etc. from that.
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. Nei
2014-05-30 0:57 GMT+03:00 Bryan Davis :
> 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 manage anything other
On Fri, May 30, 2014 at 3:56 PM, Bryan Davis 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 quite an addit
On Sun, Jun 1, 2014 at 2:57 PM, Petr Bena 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 (unfortunately no ap
25 matches
Mail list logo
