headers
Andre Engels | 7 Apr 2011 08:33
Picon

cmstartsortkey for Categorymembers

When using cmstartsortkey for a category, I get the impression the
result is incorrect.

I requested:

http://en.wikipedia.org/w/api.php?cmprop=title|ids|sortkey|timestamp&cmstartsortkey=Da&format=json&list=categorymembers&cmlimit=500&action=query&cmtitle=Category%3AAll_disambiguation_pages

The way I understand it (and the way pywikipediabot uses it) this
should give the disambiguation pages starting at Da. In reality
however, it gives them starting at D + <some unicode character beyond
z>. Am I misunderstanding the working of this api part or is this a
bug?

--

-- 
André Engels, andreengels <at> gmail.com

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 4 comments |
headers
Roan Kattouw | 7 Apr 2011 10:26
Picon

Re: cmstartsortkey for Categorymembers

2011/4/7 Andre Engels <andreengels <at> gmail.com>:
> The way I understand it (and the way pywikipediabot uses it) this
> should give the disambiguation pages starting at Da.
It never listed disambig pages whose *title* starts at Da, it always
listed disambig pages whose *sortkey* starts at Da. With the category
collation rewrite, sortkeys are now in all uppercase (which is why you
need DA to accomplish what you want), and they may have crazier binary
formats in the future.

Roan Kattouw (Catrope)
Permalink | Reply | 3 comments |
headers
Andre Engels | 7 Apr 2011 10:33
Picon

Re: cmstartsortkey for Categorymembers

On Thu, Apr 7, 2011 at 10:26 AM, Roan Kattouw <roan.kattouw <at> gmail.com> wrote:
> 2011/4/7 Andre Engels <andreengels <at> gmail.com>:
>> The way I understand it (and the way pywikipediabot uses it) this
>> should give the disambiguation pages starting at Da.
> It never listed disambig pages whose *title* starts at Da, it always
> listed disambig pages whose *sortkey* starts at Da. With the category
> collation rewrite, sortkeys are now in all uppercase (which is why you
> need DA to accomplish what you want), and they may have crazier binary
> formats in the future.

Thanks, that answers my question. Just go to uppercase :-)

--

-- 
André Engels, andreengels <at> gmail.com

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 0 comments |
headers
Carl (CBM | 7 Apr 2011 18:14
Picon

Re: cmstartsortkey for Categorymembers

On Thu, Apr 7, 2011 at 4:26 AM, Roan Kattouw <roan.kattouw <at> gmail.com> wrote:
> With the category collation rewrite, sortkeys are now in all uppercase (which is
> why you need DA to accomplish what you want), and they may have crazier binary
> formats in the future.

I want to confirm this: are you saying that all the following sortkeys
are now treated as identical?

"Article title" "Article Title" "ARTICLE TITLE" "ArTiClE TiTlE"

I'm asking because for a while we had to explicitly set the sortkey to
"Article Title" to avoid sorting based on the capitalization of the
second word.

Thanks for the info,

- Carl
Permalink | Reply | 1 comment |
headers
Roan Kattouw | 7 Apr 2011 19:31
Picon

Re: cmstartsortkey for Categorymembers

2011/4/7 Carl (CBM) <cbm.wikipedia <at> gmail.com>:
> I want to confirm this: are you saying that all the following sortkeys
> are now treated as identical?
>
> "Article title" "Article Title" "ARTICLE TITLE" "ArTiClE TiTlE"
>
Yes, they're all normalized to "ARTICLE TITLE". This (uppercasing of
everything) is a temporary solution until we can enable UCA, which
will probably mangle things even more.

Roan Kattouw (Catrope)
Permalink | Reply | 0 comments |
headers
Sreejith K. | 14 Apr 2011 09:07
Picon

CentralAuth SUL Login

The documentation for API:Login is not elaborate enough and I find it confusing. I don't know whether I am the only one. This is the statement in particular that I am finding difficult to comprehend.

CentralAuth SUL Login

...
Now you have to parse the cookie by looking for the centralauth_ cookies and adding additional entries for all other wikis that centralauth covers in your setup.

The cookies I get when I log in (after I get a success message) is like this. First, I do not understand why the domains for centralauth cookies is not having the language code (in this case 'en'). I tried manually changing it to en.wikipedia.org but that did not help. Second, I am not sure whether I create new cookies myself and give the names as enwiki_User, enwiki_Token and enwiki_Session and then copy the domain and values.

"Domain:en.wikipedia.org, Name:enwiki_session, Value:a645f734457a6dc84071c76920f49d17"
"Domain:en.wikipedia.org, Name:enwikiUserID, Value:1668905"
"Domain:en.wikipedia.org, Name:enwikiUserName, Value:Sreejithk2000"
"Domain:.wikipedia.org, Name:centralauth_User, Value:Sreejithk2000"
"Domain:.wikipedia.org, Name:centralauth_Token, Value:10818a0450a622c4b3ca32e25a73df54"
"Domain:.wikipedia.org, Name:centralauth_Session, Value:aa05490f4be76d3be15641e71531bcc5"

Can someone elaborate on the next steps on the API portal or reply back to this email? 

Quite surprisingly, I pointed my api to commons and all the Domains now gives the complete domain (commons.wikipedia.org) and I can get an edit token with these cookies. 

Thanks,
Sreejith K.
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 2 comments |
headers
Roan Kattouw | 14 Apr 2011 09:22
Picon

Re: CentralAuth SUL Login

2011/4/14 Sreejith K. <sreejithk2000 <at> gmail.com>:
> The documentation for API:Login is not elaborate enough and I find it
> confusing. I don't know whether I am the only one. This is the statement in
> particular that I am finding difficult to comprehend.
>
> CentralAuth SUL Login
>
> ...
> Now you have to parse the cookie by looking for the centralauth_ cookies and
> adding additional entries for all other wikis that centralauth covers in
> your setup.
> The cookies I get when I log in (after I get a success message) is like
> this. First, I do not understand why the domains for centralauth cookies is
> not having the language code (in this case 'en').
That's intentional, so you can have one cookie for all *.wikipedia.org
subdomains.

> I tried manually changing
> it to en.wikipedia.org but that did not help.
Don't.

> Second, I am not sure whether
> I create new cookies myself and give the names as enwiki_User, enwiki_Token
> and enwiki_Session and then copy the domain and values.
No, you just need to save these cookies and pass them back in
subsequent requests just like the other cookies. I agree that the
manual text suggests something else.

Roan Kattouw (Catrope)
Permalink | Reply | 0 comments |
headers
Platonides | 16 Apr 2011 01:38
Picon

Re: CentralAuth SUL Login

Sreejith K. wrote:
> The documentation for API:Login
> <http://www.mediawiki.org/wiki/API:Login> is not elaborate enough and I
> find it confusing. I don't know whether I am the only one. This is the
> statement in particular that I am finding difficult to comprehend.
> 
> 
>         CentralAuth SUL Login
> 
> ...
> Now you have to parse the cookie by looking for the centralauth_ cookies
> and adding additional entries for all other wikis that centralauth
> covers in your setup.

You can use all the cookies centralauth_User, centralauth_Token,
centralauth_Session to all the WMF domains. They will automatically log
you in and provide the <lang>wiki_session, <lang>wikiUserID (which you
then need to treat the normal way).

Alternatively, you can also log into the other domains the normal way
and not make cehtralauth_* cookies "global".
Permalink | Reply | 0 comments |
headers
Roan Kattouw | 17 Apr 2011 15:23
Picon

[Mediawiki-api-announce] BREAKING CHANGE: Sortkeys in list=categorymembers and prop=categories are now hexadecimal

As of r86257 [1], which will be deployed to Wikimedia wikis soon and
will be included in the 1.17 release, sortkeys output by
list=categorymembers and prop=categories are now encoded as
hexadecimal strings, so "FOO" becomes "464f4f".

As previously announced, sortkeys are no longer guaranteed to be
human-readable, and may in fact contain binary data (this will happen
when Wikimedia switches to the UCA/ICU collation). However, outputting
binary data, notably in XML, was problematic [2], so I decided to use
hexadecimal encoding. This means the sortkey as returned by the API is
now guaranteed to not be human-readable, even if the underlying
collation uses a human-readable format (such as the uppercase
collation currently in use on Wikimedia wikis). However, it will still
sort correctly: if A sorts before B in the binary format, that will
also be the case in the hexadecimal format.

The following things changed:
* The 'sortkey' property in list=categorymembers and prop=categories
is now a hexadecimal string
* In prop=categories , clprop=sortkey will now also output the
'sortkeyprefix' property (human-readable part of the sortkey).
list=categorymembers already provided this through
cmprop=sortkeyprefix
* The format of cmcontinue has changed from type|pageid|rawsortkey to
type|hexsortkey|pageid . If you did not make any assumptions about the
format of cmcontinue and just passed back whatever you got in
query-continue, this won't affect you

Roan Kattouw (Catrope)

[1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86257
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28541

_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Permalink | Reply | 0 comments |
headers
Андрій Гончар | 22 Apr 2011 11:25
Picon

Api access restriction

Hello!
Can I restrict access to mediawiki api?
I need deny all permission for every users, except one, which login and password I give to client
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 7 comments |

Gmane