Question: Plans for translation (i18n) support in Quickshell?

[AhmedSaadi0]

Hi,

I noticed that while qsTr() calls exist in QML files, there currently seems to be no way to load translation files (.qm) for the application.

I wanted to ask if there are any plans to support translations (i18n) in Quickshell?
Is this something expected in the near future, or is there a roadmap for implementing it?

Thank you.

[sadorowo]

I think that this feature is needed for a lot of developers, I want to migrate from AGS but for now I'd need to write my own JSON-based translation system like I used to do in Aylur's GTK Shell. I want to take advantage of the powerful Qt multilanguage system and Qt Linguist app.

[AhmedSaadi0]

Nobody has answered about the roadmap yet. I think I am going to make a Pull Request to add this feature myself. But honestly, I am too busy right now. I can't work on it soon. I will check the project later when I have time.

[komagata]

Quickshell is a framework for building complete desktop shells, and localization seems like a capability that is best provided by the runtime rather than reimplemented by every shell configuration.

QML already provides the standard qsTr() family of functions, and the Qt translation ecosystem provides TS/QM catalogs, Qt Linguist, contexts, disambiguation, plural handling, and dynamic retranslation. However, a Quickshell configuration currently has no supported way to install and retain a QTranslator, so it cannot use that standard workflow end to end.

As a result, every localized Quickshell project must either build a native extension or create its own translation runtime and API. That fragments translation tooling and requires each project to solve the same locale, plural, context, and retranslation problems independently.

First-class catalog loading in Quickshell would let configurations use the Qt APIs already present in QML. Quickshell would not need to own any translations or decide how individual projects organize them; it would only provide the missing runtime integration for loading, replacing, and retaining translators safely across reloads.

Omarchy is one concrete example. During an AI-assisted investigation of its i18n support, I verified that an external QML module can install a .qm catalog and call QQmlEngine::retranslate() to update existing qsTr() bindings inside an unmodified Quickshell process. This confirms that the required Qt primitives work inside an unmodified Quickshell process, although the correct upstream API, translator lifetime, and reload behavior still need to be designed within Quickshell.

I am not publishing or submitting a Quickshell patch from that investigation. I’m only reporting the observed behavior to help clarify the required integration; any upstream implementation should be independently designed and written in accordance with Quickshell’s contribution policy.

@outfoxxed Would a general mechanism for installing and replacing Qt translation catalogs be within the intended scope of Quickshell? If so, even a brief indication of the preferred API surface would help downstream shell projects converge on the standard Qt approach instead of developing incompatible alternatives.

[komagata]

An update to my earlier comment: I have since opened an AI-assisted implementation in #1081 for discussion.

It loads i18n/qml_.qm catalogs using QTranslator, so shells can use the standard qsTr() and Qt Linguist workflow, including plural forms and language switching through Qt.uiLanguage. The current proposal uses one catalog per shell; separate plugin catalogs are not covered.

@sadorowo @AhmedSaadi0 You both expressed interest in this feature earlier. Would this approach fit your use cases, or is there anything it would need to support for your shells?

[sadorowo]

An update to my earlier comment: I have since opened an AI-assisted implementation in #1081 for discussion.

It loads i18n/qml_.qm catalogs using QTranslator, so shells can use the standard qsTr() and Qt Linguist workflow, including plural forms and language switching through Qt.uiLanguage. The current proposal uses one catalog per shell; separate plugin catalogs are not covered.

@sadorowo @AhmedSaadi0 You both expressed interest in this feature earlier. Would this approach fit your use cases, or is there anything it would need to support for your shells?

My use case is custom Wayland shell with multi-language support. I want to migrate over from Aylur's GTK shell to Quickshell but this feature is the only thing that I'm missing right now - I would appreciate Qt Linguist support to not write another translator like I've done previously.

[AhmedSaadi0]

Hi @komagata , thanks so much for taking the initiative on this! I'm quite busy at the moment, so I won't be able to test it right away, but sticking with the official Qt workflow (QTranslator, qsTr(), and Qt Linguist) is definitely the right move and the most solid approach. Really appreciate your effort on this!