Smalyshev added a comment.
@Hrishikes this task is about search and it already has been fixed. Please submit the linking issue as a separate task.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: H
Hrishikes added a comment.
This problem is present in other Wikis too. I have noticed it in enWS and bnWS, whenever a link containing these characters (like য়) goes to a non-Wiki site, it does not work, but it works fine when the link goes to another Wiki.TASK DETAILhttps://phabricator.wikimedia.or
Mahir256 added a comment.
@greg Okay, thank you for the clarification. I will close this task after Monday, then. (Probably should fix the URL I linked to, though.)TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/
Sjoerddebruin added a comment.
Wikidata is still on MediaWiki 1.31.0-wmf.7, while the change is included in 1.31.0-wmf.8.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SjoerddebruinCc: Sjoerddebruin, tstarli
Smalyshev added a comment.
@Mahir256 Please note wmf.8 is still not deployed on www.wikidata.org - see https://phabricator.wikimedia.org/T178635.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: ts
Smalyshev added a comment.
Seems to be working ok on test.wikidata.org, so closing. If it fails on wikidata when the train moves on, please reopen.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc:
Smalyshev added a comment.
@thiemowmde I think it should fix it but can't check since it's not deployed yet (not even on test). So I'd like to keep it open until we can verify the problem is indeed gone.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimed
gerritbot added a comment.
Change 387959 abandoned by Smalyshev:
Normalize search term before matching against result
Reason:
looks like better solution has been found
https://gerrit.wikimedia.org/r/387959TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wik
gerritbot added a comment.
Change 390365 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] To identify superseded requests, use the requested search term instead of the returned search term
https://gerrit.wikimedia.org/r/390365TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL P
gerritbot added a comment.
Change 390365 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/extensions/Wikibase@master] To identify superseded requests, use the requested search term instead of the returned search term
https://gerrit.wikimedia.org/r/390365TASK DETA
hoo added a comment.
In T170779#3734809, @Smalyshev wrote:
@Snaterlicious, @hoo, @thiemowmde Do you know why the check is there and what it meant to be doing? @tstarling raised the following concern:
The search term is normalized by the server using $wgContLang->normalize(), which potentially inc
TJones added a comment.
@Smalyshev, thanks for tracking this one down! That was some weird behavior, but things getting normalized and not matching makes sense.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
gerritbot added a comment.
Change 387959 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[data-values/value-view@master] Normalize search term before matching against result
https://gerrit.wikimedia.org/r/387959TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCE
Smalyshev added a comment.
In jquery.ui.suggester.js we've got this:
if ( typeof requestTerm === 'string' && requestTerm !== self._term ) {
// Skip request since it does not correspond to the current search term.
return;
}
So looks like the term we get from the result may not be the
Smalyshev added a comment.
Looking at the network trace when searching for ଡ଼, the result is returned (Q31441900) but for some reason is not displayed. The warning is there, but does not prevent the display of the result. I suspect the frontend, but will dig deeper.TASK DETAILhttps://phabricator.wik
TJones added a comment.
Note that you don’t need to change your interface to Bengali to see these effects, and the fact that it is the Bengali keyword for “category” doesn’t seem to matter either. You can search for single characters and get the described behavior.
(Be sure to clear the search box
Mahir256 added a comment.
@debt No, the results are simply not appearing. The JSON response is still normal, but the results do not render on screen. The symptoms as listed in the task description still persist.TASK DETAILhttps://phabricator.wikimedia.org/T170779EMAIL PREFERENCEShttps://phabricator
17 matches
Mail list logo
