Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
Hi,
I'm trying to use Wikibase on my pool wiki and language wikis.
In my pool wiki, I can create properties and items, but I can't add site
links to them. ID: "Q1", site id: "cswiki", site link: "article name"
gives me the error "The specified article could not be found on the
corresponding site." even though that article exists on cswiki.
I also can't access data from the language wikis. If I use
{{#property:P1}} in an article on cswiki, nothing shows up.
I downloaded Wikidata-refs-heads-master.tar.gz and extracted it to the
extension folder of my pool wiki and language wikis.
My LocalSettings.php of the pool wiki looks like this:
# Wikibase
$wgEnableWikibaseRepo = true;
$wgEnableWikibaseClient = false;
$wmgUseWikibaseRepo = true;
$wmgUseWikibaseClient = false;
require_once __DIR__ . "/extensions/Wikidata/Wikidata.php";
require_once __DIR__ .
"/extensions/Wikidata/extensions/Wikibase/repo/ExampleSettings.php";
# SiteMatrix Extension
require_once "$IP/extensions/SiteMatrix/SiteMatrix.php";
$wgLocalDatabases = array( 'cswiki', 'dewiki', 'enwiki', 'eswiki',
'frwiki', 'huwiki', 'hywiki', 'itwiki', 'nlwiki', 'plwiki', 'poolwiki',
'ptwiki', 'ruwiki', 'srwiki', 'svwiki' );
My LocalSettings.php of the language wikis (cs for example) look like this:
# Wikibase Extension
$wgEnableWikibaseRepo = false;
$wgEnableWikibaseClient = true;
$wmgUseWikibaseRepo = false;
$wmgUseWikibaseClient = true;
require_once __DIR__ . "/extensions/Wikidata/Wikidata.php";
# Settings
$wgWBSettings['repoUrl'] = 'http://pool.mypedia.com';
$wgWBSettings['repoScriptPath'] = '/w';
$wgWBSettings['repoArticlePath'] = '/wiki/$1';
$wgWBSettings['siteGlobalID'] = 'cswiki';
$wgWBSettings['repoDatabase'] = 'poolwiki';
$wgWBSettings['changesDatabase'] = 'poolwiki';
# Optional
$wgWBSettings['siteGroup'] = 'mypedia';
$wgWBSettings['sort'] = 'code'; //optional
$wgWBSettings['sortPrepend'] = array(
'cs'
);
In populateSitesTable.php, I changed
"https://meta.wikimedia.org/w/api.php" to
"http://pool.mypedia.com/w/api.php" and "$validGroups = array(
'wikipedia', 'wikivoyage', 'wikiquote', 'wiktionary','wikibooks',
'wikisource', 'wikiversity', 'wikinews' );" to "$validGroups = array(
'mypedia' );"
Do I need to change "$wikiId = $this->getOption( 'wiki' );" too, since
it says "wiki" is expanded to "wikipedia"?
Table "sites" in the poolwiki database looks like this:
site_id | site_global_key | site_type | site_group | site_source |
site_language | site_protocol | site_domain | site_data | site_forward |
site_config
1 | cswiki | mediawiki | mypedia | local | cs | http:// |
com.mypedia.cs. |
a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}}
| 0 | a:0:{}
[...]
15 | poolwiki | mediawiki | pool | local | en | http:// |
com.mypedia.pool. |
a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}}
| 0 | a:0:{}
I changed site_group "wikipedia" to "mypedia" and added data for
site_protocol and site_domain by hand.
I noticed that the script path is "/w/$1" here, while $wgScriptPath in
LocalSettings.php is actually "/w", could that cause any problems?
And should I change site_group of the pool to mypedia like I did with
the language wikis or isn't that necessary?
Wikibase DataModel 0.8, Wikibase Repository 0.5 alpha, WikibaseLib 0.5
alpha and Wikidata show up in Special:Version of the pool wiki.
Wikibase Client 0.5 alpha, Wikibase DataModel 0.8, WikibaseLib 0.5 alpha
and Wikidata show up in Special:Version of the language wikis.
Any help would be really appreciated!
Thanks and cheers,
Till
Hi,
I'm running multiple language wikis and one pool wiki. The problem is
that no file descriptions are fetched in the language wikis although
$wgFetchCommonsDescriptions is set to true.
LocalSettings.php of the language wikis:
$wgUseSharedUploads = true;
$wgSharedUploadPath = 'http://pool.example.com/w/images';
$wgSharedUploadDirectory = '/path/to/pool/w/images/';
$wgHashedSharedUploadDirectory = true;
$wgFetchCommonsDescriptions = true;
$wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki
#$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki
$wgRepositoryBaseUrl = "http://pool.example.com/wiki/Image:";
ForeignAPIRepo used to work fine before, but since I switched from
Apache to Nginx, no images show up anymore in the language wikis. This
is how my LocalSettings.php used to look like:
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'pool',
'apibase' => 'http://pool.example.com/w/api.php',
'fetchDescription' => true, // Optional
'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are
seconds)
'apiThumbCacheExpiry' => 0, // required for local thumb caching
);
I also tried to set 'name' => 'poolwiki', (name of the pool database)
but that doesn't work either.
I also re-started Memcached and I even deleted a file description page
from the CloudFlare cache, but still no file description can be seen :/
My software: MediaWiki: 1.22.0
PHP: 5.3.27 (fpm-fcgi)
MySQL: 5.1.70-log
Any help would be über-cool.
Thanks and cheers,
Till
On 24 October 2014 08:41, Chad <innocentkiller(a)gmail.com> wrote:
> On Fri, Oct 24, 2014 at 8:12 AM, James Forrester <jforrester(a)wikimedia.org
> >
> wrote:
>
> > On 23 October 2014 18:39, Legoktm <legoktm.wikipedia(a)gmail.com> wrote:
> >
> > > Hi,
> > >
> > > As part of the librarization project[1], we are planning on taking the
> > > CSSJanus library that is currently in includes/lib/ and bringing it in
> > > with composer. However, it requires PHP >=5.3.3 in its
> composer.json[2].
> > > Krinkle has stated[3] that is due to the fact that it has only been
> > > tested on 5.3.3 and higher, and it's also what travis-ci provides.
> > >
> > > After doing some research[4], it appears that we would be dropping
> > > support for Ubuntu 10.04LTS, which has security support until April
> > > 2015. MediaWiki 1.25.0 is expected to be released in May 2015.
> > >
> > > Does anyone have any objections to dropping 5.3.2 support? I've
> uploaded
> > > [5] that actually increments the required version number.
> > >
> >
> > I understood that the vague plan was to switch over to 5.4.x
> requirement,
> > and that we'd only waited because Wikimedia wasn't ready yet. Has this
> > changed? I know a number of people have talked about wanting to use PHP
> > traits.
> >
> >
> Yes, but that's longer term.
>
How much longer? 1.25 is May 2015; Wikimedia's ZAP -> HAT migration is
nominally to be finished within a month…
> This minor bump still in the 5.3.x branch I think we can do immediately.
>
Sure, if announcing a 1.25 dependency change and then changing the change
later won't disrupt people too much.
(Copying the main MediaWiki-l list for those who don't follow wikitech-l)
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
While looking into upgrading my 1.22.5 installation to 1.23.5, I noticed that the tests/ directory was missing. Looking in git it is there for the REL1_23, but seems to have vanished in the tarballs for releases?
Am I missing something? or are these releases incomplete?
Sincerely confused,
-Daniel (Us+er:AlephNull)
Hi all,
My team at the MITRE Corporation is considering using the LiquidThreads
(LQT) code base as a starting point for a new commenting extension we are
writing. We would either fork LQT and work directly on the existing code,
or at least use the code as inspiration or a basis for how to start
designing our own extension.
I'm aware that development of LQT was canceled over three years ago - can
anyone shed some light on the backstory of why it was abandoned? If there
were some fundamental technical flaws with the extension, that would be
good for us to know if we shouldn't waste our time; on the other hand, if
it was more of a policy/philosophy reason, then that would also be good for
us to know, to see if that reasoning applies to our needs.
Thanks!
--
Jason Ji
The MITRE Corporation
Hi,
I've added Cite and refToolbar to my Wiki but they aren't being loaded.
Cite was automatically in my extension directory immediately after
installation, so what I did was I added
require_once "$IP/extensions/Cite/SpecialCite.php";
To near the end of LocalSettings.php and while cite appears @
Special:Version it does not appear to be working. For example, citation
templates I've added to my Wiki are not organized into footnotes when
contained between <ref> </ref> tags and these tags are, in fact, left
unparsed in articles.
As for refToolbar I added this extension (via copy-pasting the files
listed here
[https://en.wikipedia.org/wiki/Wikipedia:RefToolbar#Related_scripts]
into their respective MediaWiki namespace pages (including adding
* refToolbar[ResourceLoader|default|dependencies=user.options,mediawiki.legacy.wikibits]|refToolbar.js
* refToolbarBase[ResourceLoader|hidden|rights=hidden]|refToolbarBase.js
to MediaWiki:Gadgets-definition). <gadget-refToolbar> appears @
Special:Preferences under Gadgets and is ticked.
Thanks for your time,
Brenton
NGIH THOMAS TANSA
SICA
BAMENDA
PHONE,NO.699163636
N,WEST REGION
03-02-15
tansahthoma(a)yahoo.com
thomastansahthomas(a)yahoo.com
kenlilianlilianken(a)yahoo.com
On Sat, 1/31/15, mediawiki-l-request(a)lists.wikimedia.org <mediawiki-l-request(a)lists.wikimedia.org> wrote:
Subject: MediaWiki-l Digest, Vol 136, Issue 35
To: mediawiki-l(a)lists.wikimedia.org
Date: Saturday, January 31, 2015, 1:00 PM
Send MediaWiki-l mailing list
submissions to
mediawiki-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
or, via email, send a message with subject or body 'help'
to
mediawiki-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of MediaWiki-l digest..."
Today's Topics:
1. Re: LiquidThreads backstory? (Max
Semenik)
2. Re: SVG thumbnailing (Brenton Horne)
3. Re: Problems with Special:ActiveUsers
since update from 1.22
to 1.24 (Jakub Klinkovský)
----------------------------------------------------------------------
Message: 1
Date: Fri, 30 Jan 2015 16:40:26 -0800
From: Max Semenik <maxsem.wiki(a)gmail.com>
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Subject: Re: [MediaWiki-l] LiquidThreads backstory?
Message-ID:
<CAGgaK7+F=zdwNrhknzz4=a1Q0MjQ-xgqDvg0D09eiOppg9M8Zg(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jan 30, 2015 at 10:11 AM, Jason Ji <jason.y.ji(a)gmail.com>
wrote:
> Thanks for your feedback. To clarify a bit, we're not
thinking of using
> LiquidThreads as it is - we have a different extension
we will be building,
> with some different needs than LQT has. For example, we
may not need any
> integration with watchlists. So our thought is that we
might fork LQT and
> modify it to suit our needs. We're still very early in
the design phase.
>
The bad part of LQT is not about interaction with watchlist.
It will be
essentially untouched by any trimming short of complete
rewrite.
> Max - when you say just use Flow, do you mean we should
fork the Flow code
> base and work from there, or that we should just
install Flow? Flow looks
> interesting, but we're not sure it will have the
features we need, and our
> timeframe is likely to be shorter than the timeframe of
Flow development.
>
If you fork something, you will have to maintain it forever
- why not put
the same effort in contributing to mainline instead? And
Flow is quite
complete for most use cases, and its team is mostly working
on adding
support for various crazy workflows user communities have
created in more
than 10 years without a good discussion system. I don't
think you need to
wait for these.
> Is there somewhere I can go read in detail about the
bugs and unfixable
> problems with LQT? We might not fork LQT at all, but we
were also thinking
> of using wiki pages to store comment text. So if that
idea is fundamentally
> broken, it would be great to know why.
I already explained why, bugs are here:
https://phabricator.wikimedia.org/search/query/ojED3mdcIKDQ/
--
Best regards,
Max Semenik ([[User:MaxSem]])
------------------------------
Message: 2
Date: Sat, 31 Jan 2015 13:32:39 +1000
From: Brenton Horne <brentonhorne77(a)gmail.com>
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Subject: Re: [MediaWiki-l] SVG thumbnailing
Message-ID: <54CC4CD7.4020008(a)gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
librsvg didn't work. I've installed it via cygwin (I'm
running Windows 7
64 bit). I even directed MediaWiki (via $wgSVGConverterPath
=
'C:\cygwin64\usr\include\librsvg-2.0\librsvg';) towards the
directory
where it is installed. Any other ideas?
On 31/01/2015 5:11 AM, Brion Vibber wrote:
> It looks like you're defaulting to converting SVGs
using ImageMagick, which
> can be a bit flaky (and there also seems to be a
version mismatch where it
> doesn't like the options being given to it.)
>
> If you can, try switching the SVG renderer to rsvg,
which is the tool we
> use on Wikipedia:
>
> * install 'librsvg' (and if necessary 'librsvg-bin')
package on the system;
> should be available in standard Linux package managers
as it's a library
> used by GNOME desktop. Also available through Homebrew
on Macs. Not sure
> about Windows. :)
>
> * in LocalSettings.php set:
>
> $wgSVGConverter = 'rsvg';
>
>
> As for the borders and such, you probably need to copy
some CSS styles from
> the [[MediaWiki:Common.css]] page from Wikipedia.
>
> -- brion
>
>
> On Thu, Jan 29, 2015 at 6:34 PM, Brenton Horne <brentonhorne77(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> I've noticed that SVG thumbnailing on my new
locally-hosted Wiki is
>> thumbnailing svgs incorrectly. This is what it
appears like atm when
>> incorporated into an infobox:
http://i.stack.imgur.com/dRWkj.png.
>> Likewise I've also noticed there's no enclosing box
around infoboxes in my
>> Wiki, which you can also see in this image. This is
the sort of infobox
>> formatting I'd like
http://i.stack.imgur.com/aI0Tx.png.
>>
>> Thanks for your time,
>> Brenton
>>
>> _______________________________________________
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>>
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
------------------------------
Message: 3
Date: Sat, 31 Jan 2015 12:55:22 +0100
From: Jakub Klinkovský <j.l.k(a)gmx.com>
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Cc: aschulz(a)wikimedia.org,
ori(a)wikimedia.org
Subject: Re: [MediaWiki-l] Problems with Special:ActiveUsers
since
update from 1.22 to 1.24
Message-ID: <20150131115522.GG3377(a)jlknb.lan>
Content-Type: text/plain; charset="utf-8"
On 28.01.15 at 13:57, Bartosz Dziewoński wrote:
> The special page was rewritten in MediaWiki 1.23 to
make it usable on wikis
> the size of Wikipedia (commit 87be24db /
> https://gerrit.wikimedia.org/r/#/c/110299/
and some follow-up changes).
> Unfortunately this optimization for massive wikis seems
to have caused the
> performance to suffer on smaller ones a bit.
>
> (I have no answer to your problems, just saying this.
:( Perhaps it helps
> someone else help you.)
>
> --
> Bartosz Dziewoński
I've also noticed that with each time the
Special:ActiveUsers page is reloaded,
the time value in the message
> You are viewing a cached version of this page, which
can be up to ... old.
is decreased by 20 minutes on the "small" wikis, and by 10
minutes on "large"
wikis such as Wikipedia. The message of the above linked
commit is
> Made ActiveUsers use querycache and do staggered
updates on view
Is this what "staggered updates" are supposed to do? Does
the cached page age
really depend on how frequently it is loaded by users? This
would explain why
the age is over 29 days for small wikis, while large wikis
serve ~1day old page.
CC'ing the author and committer of the change, so that we
don't have to
speculate anymore... The original post of this thread can be
viewed here:
https://lists.wikimedia.org/pipermail/mediawiki-l/2015-January/043850.html
--
Jakub Klinkovský
Hi,
since the update of MediaWiki from 1.22 to 1.24, which happened about 10 days
ago [1], ArchWiki has some problems with the Special:ActiveUsers page [2]:
* The number of users in the list is much lower than it should be according to
the Special:Statistics page.
* The users in the ActiveUsers list are not the most recently active users
according to Special:RecentChanges (but it happened several times that the
list contained only my account, which could be related to that I was the most
recently logged-in user viewing a page at that time).
* The ActiveUsers list will grow larger (but not large enough) when the page is
reloaded frequently, but will be emptied after some time regardless of
$wgActiveUserDays which is 30, the issue is only a few days old on our wiki.
* The second line on the ActiveUsers page says:
"You are viewing a cached version of this page, which can be up to 29 days, 23
hours and 40 minutes old."
This value is too large, isn't it? Is it even configurable? I have been unable
to find anything related. Also, I don't think the page was cached until 1.23
or 1.24, so perhaps this is part of the problem...
As far as we know, ArchWiki is not the only one affected, see e.g. [3].
Thanks for any clues about the issue.
--
Jakub Klinkovský (Lahwaacz), ArchWiki admin
[1]: https://bbs.archlinux.org/viewtopic.php?pid=1494117#p1494117
[2]: https://wiki.archlinux.org/index.php/Special:ActiveUsers
[3]: http://wiki.gentoo.org/wiki/Special:ActiveUsers
Hi,
I've noticed that SVG thumbnailing on my new locally-hosted Wiki is
thumbnailing svgs incorrectly. This is what it appears like atm when
incorporated into an infobox: http://i.stack.imgur.com/dRWkj.png.
Likewise I've also noticed there's no enclosing box around infoboxes in
my Wiki, which you can also see in this image. This is the sort of
infobox formatting I'd like http://i.stack.imgur.com/aI0Tx.png.
Thanks for your time,
Brenton
