Last modified: 2010-07-21 11:01:45 UTC
Assume A and a are different variants of the same character in a wiki with language converter. In the 'insert link' dialog (of WikiEditor), if a page 'XA' exists but I input 'Xa' in the dialog, it says 'the page does not exist'. However, in the rendered page, it points to 'XA' correctly.
In my own client code, I usually wrap 'Xa' in [[ ]], and send it to api.php?action=parse&prop=links, then check the 'exists' attribute in the response.
Does it list 'XA' in the suggestions list?
(In reply to comment #2) > Does it list 'XA' in the suggestions list? Sorry for my laziness. I went to check api.php?action=opensearch directly, and it didn't list 'XA' if I put search=Xa in it.
and of course it can list XA if I use search=X only.
Right, so it looks like we need two things here: 1) We need the API's title normalization code to normalize Xa to XA, assuming XA is the canonical variant and Xa is an alias (is this correct?) so the existence check succeeds. 2) We need Extension:TitleKey to take variants into account. Currently, typing "WORLD CUP" into the link dialog on enwiki will suggest "World Cup" and a number of other results: Extension:TitleKey makes this case-insensitive, but we need it to make it variant-insensitive as well.
1. There's no variant is 'canonical'. Pointing variant links to correct pages is by converting a link to its all possible variants, and check whether any page with a variant as title exists one by one. Titles stored in database also have different variants -- it depends on the creator. 2. Case converting rules are fixed, but variant converting rules (zh rules. sr, tg ones are fixed) are not -- because it's difficult to guarantee a set of rules never makes mistakes. See [[zh:Wikipedia:字词转换请求或候选]]. People propose new rules (or fix old rules), and [[zh:User:PhiLiP]] may add them to MediaWiki at a time.
(In reply to comment #6) > 1. There's no variant is 'canonical'. Pointing variant links to correct pages > is by converting a link to its all possible variants, and check whether any > page with a variant as title exists one by one. Titles stored in database also > have different variants -- it depends on the creator. > > 2. Case converting rules are fixed, but variant converting rules (zh rules. sr, > tg ones are fixed) are not -- because it's difficult to guarantee a set of > rules never makes mistakes. See [[zh:Wikipedia:字词转换请求或候选]]. People propose new > rules (or fix old rules), and [[zh:User:PhiLiP]] may add them to MediaWiki at a > time. OK, that sounds kinda like a nightmare. Marking the bug as filed as INVALID since this is not a bug in the insert link dialog: it's the two API modules it's using that return incomplete data, which in turn is caused by the components they rely on not being variant-aware enough. The two issues identified in this discussion should be filed as separate bugs against core and Extension:TitleKey. Note that the issues you mentioned may make them somewhat tricky to fix.
Cannot the method I mentioned in comment 1 be used to resolved the page existence check problem?
(In reply to comment #8) > Cannot the method I mentioned in comment 1 be used to resolved the page > existence check problem? Yes, but it's expensive to fire up the parser just to do an existence check. The API should be capable of that on its own by using whatever function the parser uses.
Solving bug 24059 can make variants appear in the suggestion list.
Now that bug 24296 has been fixed, the existence check in the dialog can check for variants too. This was done in r69671. Going to mark this bug as FIXED since there will be no further action required once opensearch starts listing variant titles (i.e. once bug 24059 is fixed).
