Programs

Season of KDE
KUWoC is a one month program between mid-January and mid-February in collaboration with the KU Open Source Community (KUOSC) at Kathmandu University.

Note

For organizational reasons, GSoC projects must be written in this specific page.

Projects

All ideas for year 2026
Idea	SoK	KUWoC
Template project	Yes	No
Improve docs-kde-org maintenance	Yes	Yes

Template project

Your Own Idea: Something that you're totally excited about

Project Type: Coding / Web Development / Promo / Translation

Brief Explanation: Do you have an awesome idea you want to work on with KDE but it isn't among the ideas below? That's cool. We love that! But please do us a favor: Get in touch with a mentor early on and make sure your project is realistic and within the scope of KDE. That will spare you and us a lot of frustration.

Expected Results: Something you and KDE love

Knowledge Prerequisite: Probably C++ and Qt, but it depends on your project

Mentor: Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Matrix.

When adding an idea to this section, please try to include the following data:

if the application is not widely known, a description of what it does and where its code lives
a brief explanation
the expected results
pre-requisites for working on your project
if applicable, links to more information or discussions
mailing list or Matrix/IRC channel for your application/library/module
your name and email address/Matrix handle for contact (if you're willing to be a mentor)
if you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.

Do not add SoK ideas with no mentor and no contact info.

docs.kde.org website

Improve docs-kde-org maintenance

Your Own Idea: Extract dblatex-cvs-install from docs-kde-org Project type: Coding

Brief explanation: we are currently reworking the documentation website in https://invent.kde.org/websites/docs-kde-org/-/issues/2. The first task was to generate the documentation of each repo in a specific job (https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/gitlab-templates/documentation.yml?ref_type=heads). Then, a new job will fetch all the generated documents and generate again the website. For now, we are using an old fork of dblatex-cvs-install (https://dblatex.sourceforge.net/) which has been copied pasted in https://invent.kde.org/websites/docs-kde-org/-/tree/master/dblatex-cvs-install?ref_type=heads. There are multiple potential tasks to do in this project:

extract the dblatex from the code in its own repo (keeping the history)
find if we can directly clone the original repository instead of having a fork.
check if we can use a more recent version of the original project while keeping all the changes we did in KDE meanwhile
upstream generic info if it makes sense

Expected results: Easier maintenance, better knowledge on this repo

Knowledge Prerequisite: git (some latex, python, bash knowledge may help). Not a specific knowledge but there will be a lot of investigation, so proactivity and willing to dig is important.

Mentor: Johnny Jazeix. If you are unsure you can always ask in #kde-soc on Freenode IRC, I don't think there is a specific channel for this topic.

Lokalize

Lokalize is KDE's translation system, enabling the translation of KDE programs as well as other external projects. All Lokalize tasks are mentored by Finley Watson (@fin-w:private.coffee , ask on https://matrix.to/#/#kde-mentorship:kde.org and I'll respond). If you want to do something different to the below, take a look at Lokalize bugs or speak to me and we can sort something out. All "prerequisites" describe knowledge that you will use to complete the task. They are not essential, if you lack the knowledge, you'll develop it as you work on the task.

If you want to work on a particular task you need to complete a proposal in this repository using this template and then wait for a decision towards the end of January.

You're welcome to contact me before writing a proposal, I want to help.

WARNING: I will reject all applications written by LLMs. If you can't be bothered to write it, I can't be bothered to read it. The purpose of contributing to KDE is for you to grow and learn.

Once you are accepted, I will open an issue to track your planning and progress in Lokalize's repository, and you will later open a merge request with your changes to merge your code into the main branch of Lokalize. During your time contributing, you will join a Matrix group with your peers (other mentees working on Lokalize) and will be expected to review each others' code. You will also get a status reports page similar to last year's.

Task 1: Follow human interface guidelines

Predicted Task Character: Medium time, easy difficulty.

Proofread and update UI text to ensure it follows KDE's human interface guidelines for text. The HIG standardises how text in buttons / labels etc should look, but Lokalize was never updated to follow this. A start was made but the rest of the text needs reading through. The PO (translation) files should contain all the text, but to understand it in context you will have to cross-reference by running the Lokalize program itself to understand where the text appears.

Expected Result: Lokalize UI follows the HIG.

Knowledge Prerequisites: A good enough fluency in English to complete the task. Ability to navigate the codebase and familiarity with e.g. `grep` tools, and Git / Gitlab to commit the changes, or at least willingness to learn.

Related Merge Requests: https://invent.kde.org/sdk/lokalize/-/merge_requests/259

Task 2: Fix the glossary

Predicted Task Character: Medium time, medium difficulty.

The glossary tab in Lokalize is unintuitive and hard to use, and current doesn't work at all without manually adding the file that saves the glossary data to disk. The glossary UI needs to be updated so that it is easier to use, and the glossary behaviour needs to be improved so that a file is added to the current project when the file doesn't exist. This requires working with active translators, to ensure the glossary is developed best for Lokalize's users.

Expected Result: Clear and easy-to-use glossary tab UI, fix all crashes / UI inconsistency when trying to use the glossary, save the correct "default" file contents when creating a glossary entry for the first time.

Knowledge Prerequisites: C++ knowledge or at least experience coding, Git / Gitlab, UI design experience might be helpful, willingness to work with users to tailor the redesign to their needs.

Task 3: Jump to next translation unit when sort filters are applied

Predicted Task Character: Short time, medium difficulty.

The editor tab contains a dock widget called "Translation Units" which has the ability to filter entries in translation files with the search bar. You move between units with Page Up / Page Down, and moves between them while approving the translations using Control + Page Down. Using the latter shortcut jumps about in the list, rather than working down the list correctly, one after another. This needs to be fixed so the Control + Page Down shortcut ("Approve and go next") works as expected.

Expected Result: For any filtering / ordering of translation units, moving between them using all shortcuts steps up and down the visible filtered list.

Knowledge Prerequisites: C++ knowledge or at least experience coding, Git / Gitlab, some understanding of model / view architecture.

Task 4: Redesign translation memory tab

Predicted Task Character: Long time, hard difficulty.

The translation memory tab allows you to pick a TM (saved translation pairs from previous translation jobs / files) to search through, and shows the results in the list below. The UI needs redesigning to enable searching multiple memories at once by selecting the TMs you want to search, rather than picking only one from a drop-down. The selected TMs to search should be saved per-project, so translators can customise their translations per-project (e.g. only use translation memories with formal language for one specific project). Additionally, the "Manage translation memories" button opens a TM manager which should be merged into the tab instead of existing separately e.g. by moving TM-specific entries into the right-click menu, and adding more general buttons into the TM tab page, or the toolbar that is specific to the TM tab.

Stretch Goal(s): Fix the results list so the selected entry is highlighted with the correct colour from the theme (it seems broken?), and make entry rows only one line tall instead of many lines, when entry text is long.

Expected Result: A list of all TMs to pick instead of a drop-down, each entry checkable with a checkbox. Save selected TMs to the project data. Filter searches per TM grouping, searching each TM and sorting results sensibly.

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab, familiarity with model / view architecture, willingness to pick through more complicated code in a large established codebase.

Task 5: Improved state saving across all tabs

Predicted Task Character: Medium time, medium difficulty.

Some tabs save their state for projects, or across projects. This includes the sizes and locations of editor tab dock widgets, and of list headers within those dockwidgets. Some don't save state data, like the glossary tab. The order of tabs is also not saved, although whether the glossary tab or translation memory tab is open IS saved. This means the order of tabs is not consistent across restarts.

Expected Results: All tabs retain their order across restarts. All dock widgets retain the same shape and size. All list headers retain their size and remember which columns are visible. Additionally, all header widths scale proportionally when their list is resized (e.g. a column taking up 50% list space when the list is 40px wide still occupies 50% when the list is 100px wide, instead of remaining at 20px).

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab, familiarity with model / view architecture, willingness to pick through more complicated code in a large established codebase.

Task 6: Standardise menubar

Assigned to Gustavo Porto https://invent.kde.org/sdk/lokalize/-/issues/9

Predicted Task Character: Medium time, easy difficulty.

Lokalize uses a KDE framework, [KXMLGUI](https://invent.kde.org/frameworks/kxmlgui), to manage its menubar and status bar. In Lokalize, KXMLGUI allows you to define the contents of the menubar for each tab. Right now the tabs have different options in the menubar menus (not a problem) and also have different ordering of menus (annoying and inconsistent) with some menus missing. I want all tabs to offer the same menubar. Where a tab does not use a menu (e.g. Translation Memory tab does not offer "Go" menu), the menu should be added, with menu options disabled. The goal is to offer a standard menubar for all tabs, even if the menus have only disabled options for some tabs.

Expected Results: All menus visible for all tabs, menu entries enabled / disabled depending on the tab.

Tab order: File, Edit, Go, Project, Sync, Tools, Settings, Help

Stretch Goal: Unify the menubar so it is a single instance belonging to the top-level window, rather than to individual tabs. This requires discussion and planning to ensure it's a sensible idea / it's implemented correctly because e.g. keyboard shortcuts are set up per-tab using KXMLGUI too.

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab

mentorship.kde.org

Project Type: Coding

Repo Link: https://invent.kde.org/paulb/kde-mentor-programs-g-so-c-2025-project

Brief Explanation: mentorship.kde.org currently looks like a website, but does not behave like an onboarding system
This project aims to convert the site into a guided entry point for KDE mentorship.

Complete the homepage as a traffic router that guides users to other internal pages
Repurpose the /mentorship page into /programs page, listing all mentorship (SoK, GSoC, OSPP if applicable, academic and business mentorship programs)
Improve the /mentees page into a hall-of-fame style showcase of past contributors
Complete the /resources list of KDE learning materials

Expected Results:

Homepage: Fully functional with routing
Programs (Mentorship): Listing of all mentorship opportunities
Mentees: Improved showcase with consistent cards
Resources: Categorized KDE resources

Knowledge Prerequisite: HTML / CSS, Git / Gitlab, familiarity with static site generators, basic JavaScript and a sense of UX would be helpful

Mentor: Anish Tak (@drowsywings:matrix.org), Paul Brown (@bro666:kde.org), channel for discussion: #kde-www:kde.org

Plasma Setup

Project Type: Coding

Repo Link: https://invent.kde.org/plasma/plasma-setup

Plasma Setup is KDE's first run setup wizard, providing a friendly way to create the first user account and configure basic system settings.

Brief Explanation: Plasma Setup currently only supports desktop form factors, and would benefit from support for Plasma Mobile as well.

Split kcm_keyboard from plasma-desktop into a separate library, since we are currently using it and depending on plasma-desktop makes it impossible to work for plasma-mobile. https://invent.kde.org/plasma/plasma-setup/-/issues/25
Make the QML UI responsive so it works well on both desktop and mobile form factors (i.e. phone/tablet). Bonus if it also works well on very large screens, to support Plasma Bigscreen.
A stretch goal could be to add support for mobile-specific settings, such as cellular network configuration. (Very optional, only if time permits.)

https://invent.kde.org/plasma/plasma-setup/-/issues/16

Expected Results:

Plasma Setup works well on both desktop and mobile form factors.
No regressions on desktop from the current state.

Knowledge Prerequisite: C++, QML, Qt, git, UI/UX design experience would be helpful.

Mentor: Kristen McWilliam (@merritt:kde.org)

Channel for discussion: #plasma-setup:kde.org