I just included a link to the initial design specifications in the task description. These outline the language selection flow in the context of the Query builder.



The specifications defining the visual and interactive features of the Language Selector component itself are available in this separate page in the file. Said specs are a synthesis of the original detailed documentation provided by the Language team, and the Design style guide.



I wonder if we want to capture the effort to adjust/develop the component in a dedicated task? That way, I could upload assets and capture open questions there.

 As a disclaimer, I must say that this looks like quite a complex element to build. I hope that reusing the existing Vue component can save us some implementation time.



Aside from this, there are some open questions (I have the feeling these won’t be the only ones we’ll face) that should be resolved in order to help define the behavior of this component in the context of the apps (both the Query Builder and the Mismatch Finder – see T328149):



1. Menu size/ number of columns: How many languages do we expect will be available? Following the original specifications, the size of the menu (number of columns) to use depends on the number of languages provided. If the list is greater than 30, then we should use the 3 columns layout instead of 1 (the default).



2. Grouping language variants: Again, depending on the amount of languages and variants of said languages that we’ll provide, we might want to group them within the menu, as recommended by the original design documentation. (Specs are missing for now and would be created depending on our decision)



3. ’Suggested languages’: There's a section rserved for them in the designs. Do we want to simply render an alphabetical list of languages, or do we want to provide users with language suggestions based on their user preferences (UI lang, babel)?

4. Do we want the search field to offer autocomplete? In such case, the selection of the suggested language would be made on enter. Following the original specs: ‘Filtering considers all language names, autocompletion shows only for the names in the current UI language, the language itself (autonym), and ISO codes.’ I wonder if this behavior is already embedded in the component being reused. Again, wondering if this is something we might be able to reuse from the original implmentation. That might be the determining factor here.

5. Lastly, do we need to display any additional action such as, a link to allow users to 'Translate this page'?

Mh, it might be worth to take a slight step back here. At some point, we probably do not want to maintain a Vue LanguageSelector component by ourselves, but use the one from Codex.

So the question becomes: Do we want to be the team that creates the (first version of the) official LanguageSelector component in Codex? So far, it seems like no team has claimed that yet: https://www.mediawiki.org/wiki/Design_Systems_Team/Codex_Planned_Components

If yes: then we need to coordinate that tightly with the WMF Design System Team, so that can schedule another collab sprint (cc @karapayneWMDE)
If no: then we should probably focus on creating a rather low-effort 80/20 component, that we can replace by the official Codex LanguageSwitcher as soon as that has been build by another team. Most likely, that low-effort component will not meet 100% of the Design/Product requirements, but be much better than nothing.

Relevant other tasks in this context:

• T324344: Update Query Builder to Vue 3
• T327680: [WtC] [EPIC] Migrate Query Builder to Codex

I have been wondering the same. From our conversations with product, and the outcome of the previous investigation, it seems that the initial route we're taking is the latter: no. In order to deliver this feature faster, we're building a custom component that will be replaced, together with all the other instances of the language selector, once the Codex solution is ready. My assumption was, too, that this approach would help answer the majority of the questions listed in the comment above.

Nevertheless, I can't avoid thinking that we're missing an opportunity to create a reusable solution here. Something we won't have to 'throw away'. This route would, of course, take quite some more time from all fronts (design, organization, probably implementation): the component needs to be visually standardized, and we'd need to align both with the Design System Team and with the Language Team (to align on ownership, define the component characteristics and the scope of our initial implementation). I'm not the right person to say but, while I don't think a new collab sprint is necessary (I believe we can be autonomous), we'd definitely need to allocate time to coordinate and prepare. Which would pay off: this is a widely used core pattern.

Hi all,

Considering that it will be released sooner and provide important functionality to the users, I think the best way forward is to keep it to a custom component as Michael suggested in one of his options:

focus on creating a low-effort 80/20 component, that we can replace with the official Codex LanguageSwitcher as soon as that has been built by another team.

For this, I think Sarai's first design option would work best (as a single column).

And to keep it low effort not include:

• three columns
• language variant groupings
• preferred language sections
• Auto-complete
• Extra settings i.e. translate this page

Relevant PRs:

• Add language selector Icon to Wikit; https://github.com/wmde/wikit/pull/678
• Wikit pre-release with the Language Icon: https://github.com/wmde/wikit/pull/679

Change 893802 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Add language selector to QB

https://gerrit.wikimedia.org/r/893802

Change 899550 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Add nested refs in inputs and focus methods

https://gerrit.wikimedia.org/r/899550

Change 899550 merged by jenkins-bot:

[wikidata/query-builder@master] Add nested refs in inputs and focus methods

https://gerrit.wikimedia.org/r/899550

Change 901200 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Add Button to select language

https://gerrit.wikimedia.org/r/901200

Change 901247 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Add autonym in Language Selector Button

https://gerrit.wikimedia.org/r/901247

Change 901200 merged by jenkins-bot:

[wikidata/query-builder@master] Add Button to select language

https://gerrit.wikimedia.org/r/901200

Change 901247 merged by jenkins-bot:

[wikidata/query-builder@master] Add autonym in Language Selector Button

https://gerrit.wikimedia.org/r/901247

The basic query builder is merged; still missing are keyboard navigation, possibly further mobile / RTL changes, and also probably saving the selected language in local storage (or a cookie or whatever).

Potential future improvements (for Language Selector v2):

• store the language in LocalStorage so that it persists across pageloads
• have the entity selector (property selector, Item selectors, etc.) change the language of their contents too
• have the search results (the iframe) be in the changed language

Hi all,

Just wanted to see if this should be appearing on the Query Builder now?

Doesn't seem to be showing up in my browser, could it be because of these: T332312, T332310 or am I too early?

We intentionally haven’t deployed it to https://query.wikidata.org/querybuilder/ yet. I guess the easiest way to verify it would be via Netlify, similar to T324653, but I don’t know how to publish it there.

Oh, I didn’t realize that the branch-deploy npm script runs as part of CI test builds. You should be able to see the language selector here, then: https://901247--clicky-sparqly.netlify.app/

In T328148#8722028, @Lucas_Werkmeister_WMDE wrote:

Oh, I didn’t realize that the branch-deploy npm script runs as part of CI test builds. You should be able to see the language selector here, then: https://901247--clicky-sparqly.netlify.app/

We probably also want it deployed on push/merge to the master branch. Maybe that could be a workflow on the GitHub mirror?

Hey there! Only a small fix detected here: as specified, there should be a couple of pixels of spacing between the language button and the selector component.

Change 904524 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Add bottom spacing between Language Selector button and menu

https://gerrit.wikimedia.org/r/904524

Change 904524 merged by jenkins-bot:

[wikidata/query-builder@master] Add bottom spacing between Language Selector button and menu

https://gerrit.wikimedia.org/r/904524

Change 904545 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query-builder@master] Close Language Selector on blur

https://gerrit.wikimedia.org/r/904545

Change 893802 abandoned by Lucas Werkmeister (WMDE):

[wikidata/query-builder@master] Add language selector to QB

Reason:

Done in I3891aee85d and I7f05c7f089d.

https://gerrit.wikimedia.org/r/893802

Change 904545 merged by jenkins-bot:

[wikidata/query-builder@master] Close Language Selector on blur

https://gerrit.wikimedia.org/r/904545

To update: The spacing issue has been fixed but the onblur issue has created issues with the clear button that still need to be fixed.

Onblur issue to be addressed in T333932

Unsure of what to do about this parent ticket now that all related tasks have been resolved: should validation happen after the component has been released and is available in the Query Builder?
Let us know your thoughts whenever you have time, @Arian_Bozorg. Thank you!

Yes, once it's been added to the Query Builder I will validate it and close the ticket :)

I created a subtask to fix the placement of the language button in the Query builder on mobile devices. This should prevent the logo from overlapping with it in smaller viewports: T335596: Query Builder: Language button should move below logo on mobile devices.

The ticket was opened as a subtask only to reflect its relationship with this ticket, but we still need to discuss whether the parent is actually blocked by it.

Change 914265 had a related patch set uploaded (by Michael Große; author: WDQSGuiBuilder):

[wikidata/query-builder/deploy@production] Merging from da723d5ecc0a12b6ab6abfd461c7f2513314a533

https://gerrit.wikimedia.org/r/914265

Change 914265 merged by Michael Große:

[wikidata/query-builder/deploy@production] Merging from da723d5ecc0a12b6ab6abfd461c7f2513314a533

https://gerrit.wikimedia.org/r/914265

We discovered that an icon is missing in the deployed query builder. There was a bug ticket created for this: T335754: All icons in Language Selector component are missing