Lea_Lacroix_WMDE added a comment.
@Smalyshev Alright! Please ping me if I can help with anything :)
TASK DETAIL
https://phabricator.wikimedia.org/T215967
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: EBernhardson, Lea_Lacroix_WMDE
Cc:
Smalyshev added a comment.
@Lea_Lacroix_WMDE yes, but it will be deployed when WikibaseCirrusSearch
extension is fully deployed, thus we might want to wait with the announcement
until then.
TASK DETAIL
https://phabricator.wikimedia.org/T215967
EMAIL PREFERENCES
Lea_Lacroix_WMDE added a comment.
Hello @EBernhardson @Smalyshev Is this something that has an inpact on
Wikidata as well? Would it be worth an announcement?
TASK DETAIL
https://phabricator.wikimedia.org/T215967
EMAIL PREFERENCES
gerritbot added a comment.
Change 491580 **merged** by jenkins-bot:
[mediawiki/extensions/WikibaseCirrusSearch@master] implement inlabel search
keyword
https://gerrit.wikimedia.org/r/491580
TASK DETAIL
https://phabricator.wikimedia.org/T215967
EMAIL PREFERENCES
gerritbot added a comment.
Change 491580 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/extensions/WikibaseCirrusSearch@master] implement inlabel search keyword
https://gerrit.wikimedia.org/r/491580TASK DETAILhttps://phabricator.wikimedia.org/T215967EMAIL
Smalyshev added a comment.
But here since we have multiple languages I feel that one may ask for a word in two different languages and prefer having a OR between the two
Yes, this is possible, but I wonder how frequent it would be that somebody needs a label in Russian or Portuguese? I can invent
dcausse added a comment.
In general ORing a keyword is only meaning for keywords that match a code, it's rare when people ask us why can't I do intitle:foo OR intitle:bar. But here since we have multiple languages I feel that one may ask for a word in two languages different and prefer having a OR
Smalyshev added a comment.
I have a feeling we're overdesigning it a little. I think it should be simple and cover 80% of cases, and if you need more complex things you'd probably be better with using generic boolean syntax like OR/AND.
inlabel:foo@en may be ok, though obviously we'd have trouble
EBernhardson added a comment.
i like the suffix with @. The use case for | as or sounds pretty good, but allowing the two forms of | that have different language handling seems more indescisive to parse, especially since we are parsing mostly with explode or sometimes regex's. I wonder, how far
dcausse added a comment.
Why not put the languages as a suffix?
inlabel:word@en: word in english
inlabel:word@fr*: word in fr and all its fallbacks
inlable:word@{pt,fr*,-fr-ca}: word in pt or fr and all its fallbacks except fr-ca
inlabel:foo|bar@{pt,fr*,-fr-ca} foo or bar in pt or fr and all its
EBernhardson added a comment.
I'm not sure if it's great, but i see two possible solutions to en being the final fallback language for almost everything:
Strip en as the final fallback and require it to be explicitly provided.
Let any query with fallbacks query en as well
Offer a syntax to
EBernhardson added a comment.
In T215967#4956419, @Smalyshev wrote:
I like the structure of the syntax but would probably bikeshed the exact delimiters a bit if possible (later). Also, are we following fallback chains or only seeking exact language match? If we match exactly we may want to also
EBernhardson added a comment.
Actually i hadn't thought about inlabel:py-br,pt|colaborativa, that might be better than what I had with successive | characters. The successive pipes can be undetermined, but taking everything before the first pipe is very easy reason about.TASK
EBernhardson added a comment.
In T215967#4956419, @Smalyshev wrote:
I like the structure of the syntax but would probably bikeshed the exact delimiters a bit if possible (later). Also, are we following fallback chains or only seeking exact language match? If we match exactly we may want to also
Smalyshev added a comment.
I like the structure of the syntax but would probably bikeshed the exact delimiters a bit if possible (later). Also, are we following fallback chains or only seeking exact language match? If we match exactly we may want to also think about allowing fallbacks.
Nuria added a comment.
@Ramsey-WMF Could we possibly get a bit more structured use cases?
Are those documented somewhere besides this ticket so we can see how this use case fits on the big picture? Is there any UI that goes with this case?TASK DETAILhttps://phabricator.wikimedia.org/T215967EMAIL
16 matches
Mail list logo
