[go: up one dir, main page]

Page MenuHomePhabricator

Wikidata Query Builder does not support MUL language code
Open, Needs TriagePublic

Description

Wikidata Query Builder outputs the following code, there is no fallback to MUL

SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }

Event Timeline

I am just realizing that the ticket is about the Query Builder but the original request on-wiki is actually linking to a query in the Query Service UI.
I am fairly sure this needs to be fixed in the Query Service UI instead.

I am just realizing that the ticket is about the Query Builder but the original request on-wiki is actually linking to a query in the Query Service UI.

But it does mention that the query was built by the query builder (and the query looks like that too).

IMHO there are three possible approaches to this task:

  • update the query builder to emit "[AUTO_LANGUAGE],mul,en", matching the WDQS UI suggestions (arguably it’s always been unfortunate or even a bug that the query builder didn’t even include ,en)
  • implement T379135: [AUTO_LANGUAGE] does not use language fallbacks and update the query builder to emit "[AUTO_LANGUAGES]" (assuming my suggestion at T379135#10295680 is taken up)
  • make the label service follow language fallbacks, in which case we can also change the WDQS UI suggestions to just "[AUTO_LANGUAGE]" (I’m not aware of a task for this yet)

The on-wiki comment by Vicarage seems to suggest that the query builder should follow the user’s babel profile, but since the query builder is used anonymously (without logging in via Wikidata), I don’t think that’s currently possible, and IMHO it’s not worth adding OAuth integration just for this feature.

Thank you!

IMHO there are three possible approaches to this task:

  • update the query builder to emit "[AUTO_LANGUAGE],mul,en", matching the WDQS UI suggestions (arguably it’s always been unfortunate or even a bug that the query builder didn’t even include ,en)
  • implement T379135: [AUTO_LANGUAGE] does not use language fallbacks and update the query builder to emit "[AUTO_LANGUAGES]" (assuming my suggestion at T379135#10295680 is taken up)
  • make the label service follow language fallbacks, in which case we can also change the WDQS UI suggestions to just "[AUTO_LANGUAGE]" (I’m not aware of a task for this yet)

The second sounds like it'd be best to me but is also probably more work. So maybe the first for now? Thoughts?

The on-wiki comment by Vicarage seems to suggest that the query builder should follow the user’s babel profile, but since the query builder is used anonymously (without logging in via Wikidata), I don’t think that’s currently possible, and IMHO it’s not worth adding OAuth integration just for this feature.

Agreed.