GSoC on KDE Blogs

Redesigning Lokalize's Translation Memory Tab - GSoC Week 9

Navya Sai Sadu — Tue, 25 Aug 2026 00:00:00 +0000

After working on the UI of TM Tab in Lokalize during the first phase of GSoC, I got back to work on the backend. Currently, only a single TM can be searched in TM Tab. My changes enable querying across multiple selected TMs as per translators' feature request.

A little about threads and mutexes before I share week-wise updates. The GUI runs on the main thread, while TM operations (querying, opening/closing databases, removing files) run as jobs on a separate worker thread pool, TM::threadPool(). This pool is explicitly capped to a single worker thread at startup- setMaxThreadCount(1). This means TM jobs never actually run concurrently with each other, they queue and execute strictly one at a time (this can be changed given my new changes but will have to be careful).

QSqlDatabase connections can only be used on the thread that created them, which is why each job looks up or clones a connection specific to the current thread before querying.

A queued connection is what lets a signal emitted on the worker thread safely invoke a slot on the GUI thread: rather than running the slot's code immediately on the emitting thread.

A mutex protects shared or concurrently-accessed data.

Week 7

I spent week 7 exploring other approaches for quering multiple DBs and merging the results. QSqlQueryModel is only useful to get query results from a single db. It just enabled std::move(*job->query) and there was no way to append results from other TMs.

I felt that my proposed approach, to fire N ExecQueryJobs, merge them in an in-memory SQLite db, and then pass it on to the view, was making things unnecessarily complex and somewhat redundant. I'm sharing the discarded ideas as well in case it helps someone in the future.

Use ATTACH to add other db(s) and perform UNION on the search query. There were some concerns over the complexity of ATTACH and also Lokalize supports remote TMs (PostgreSQL) which doesn't have the provision of ATTACH.
Then, I looked into QConcatenateTablesProxyModel which some KDE apps already use, but there is some bug with its working with QSortFilterProxyModel. I could have had "N TMDBModel instances" (which doesn't seem like a good idea) for each TM and later join them.

Week 8

I decided upon QAbstractTableModel. Unlike QSqlQueryModel (which is a subclass of it), it's more flexible and I had to refactor some of the code. This also meant lazy fetch couldn't be preserved and the results would be stored in QSqlRecords (to preserve all the existing usage on results).

Manually tested against a single TM. Rewrote the TMJob Test too. I find it strange that we always write a test for it to pass. Also from one of the articles I read: "Use test driven development. When you write the test just before the production code, you would never write a monster test, would you?"

Week 9

setFilter() is modified such that ExecQueryJob is fired for each TM. slotQueryExecuted() accumulates each job's rows into the model as they arrive, and only fires resultsFetched() once every selected TM's job has reported back. Row count is also reported directly at the end.

Well, contrary to what I wrote in the last blog, I did end up with an approach quite similar to what TMView does. Are mentors always right?

The part on which I spent a lot of time was what happens if someone retypes their query, or checks/unchecks a TM, while the previous search's jobs are still mid-flight. Stale results shouldn't be allowed to land on top of a newer search's rows. The fix is a generation counter to keep track.

After a lot of coding and debugging, seeing the resuts from multiple TMs made the entire hard work finally pay off.

While testing, the bug mentioned in the previous blog kept pestering me so I fixed it too. I was so fixated on empty/short string that I did not think that the place it was being used could be a problem. It's nice to see the Art of Debugging materialize out of pages of Roger S. Pressman's textbook.

I'll begin to work on TM View once these changes are reviewed and merged.

GSoC 2026: Building Join.Kde.Org

Ansh Singhal — Sat, 22 Aug 2026 00:00:00 +0000

Intro

Helloooooo,
it’s me again, Ansh! , the mentee who has been working on the Join.kde.org
This is the final update within the official timeline of GSoC 2026 for my project: Building Join.KDE.org.

A quick summary:
Over the past 12 weeks, I have worked on creating, designing and implementing the join.kde site into a platform that can answer most of the basic questions a new contributor has. In this post, I’ll mainly focus on the progress from Week 6 to Week 12 along with my final thoughts.

For a short summary, checkout this status report.

Week 6: Contribute/suggest

This week I worked on the ADD section which got renamed to contribute, it includes several sub sections which allows people to contribute based on their interests.

Routed the explore section to KDE.org for you section so people can explore and find their own use for KDE softwares.

Created the suggest section which contains the information on how to report bugs/request for features.

This week was more about improvements on the navbar, I noticed with all the text the nav-bar looked way too cluttered, and simply overwhelming so with the advice from Anish and how he changed the navbar for the mentorship website, I worked up something similar and made dropdowns for the navbar so it can still have more content when clicked.

Week 8: Work on Projects

For this week I worked on the work on projects section which allows people to find groups of projects in invent based on skillset or the programming languages one knows.

I added all the groups available in KDE invent in this section which little tags of skillset.

Week 9: Incubate projects

Worked on designing Incubate projects section: which basically explains what kind of projects fit in KDE and what are the benifits of it. Linked it through a call-to-action button to the relevant resources to incubate project into KDE.

Week 10: read page/ suggest page improvement

Designed the read page with 3 main blog sites

planet
contributor blogs
mentorship blogs

This week was something new, the cards for the read page were simple but the new design of dropdown in suggest page took some time figuring out. added konqi images to the cards because duh it's konqi (but hey we can change them eventually).

Week 11: Divulge Page

Created the Divulge page which is more for people who want to create content for kde whether it be promo material, tutorials or whether help in promotion itself.

It's kind of a copy of the read page but it can always be changed.

Week 12: Events Page

Created the Events page, which included akademy as the main event and then a section for event's KDE hosts which had some sprints and conf.in and then added the section for the events KDE participates in which will likely be expanded eventually.

Fixed some tiny typos and dead link issues.

My Own Development

I learned a lot from this project, both in coding and beyond. Here are the things I remember right now, though the list could go longer:

Now I am very comfortable with Hugo, semantic maps, and YAML files
Finally learned how to deal with SVGs (was my first time working with them)
My frontend skills improved, I think I can design better pages now
I now want to create more stuff that helps people!

Conclusion

Overall, GSoC 2026 has been a great experience for me. Over these 12 weeks I got the chance to work on issues that i faced myself and fix them in a way that helps everyone joining KDE.

Along the way I learned some technical skills, learned how to work across different timezones, to communicate better, and most importantly realized that long discussions are often more necessary than jumping straight into implementation, especially in open source communities.

Big thanks to my mentors Anish and umm Conulting mentor Paul

This wraps up my GSoC journey, but I will be sticking around KDE and plan to explore other projects, especially in the mentorship side of things. See you around in the community.

How to Reach Me

GSoC Alumni Camp Delhi 2026

Ansh Singhal — Wed, 29 Jul 2026 00:00:00 +0000

GSoC Alumni Camp Delhi 2026 – My Experience

I attended the GSoC Alumni Camp in Delhi, it was an amazing opportunity to make people who are already familiar with open source aware of KDE Community and I was actually able to do that. The event itself was from 8:00 A.M. to 10:30 P.M. at night. The event started off with a formal opening session. Soon after was the scavenger hunt (we were hunting people!) it was a 5x5 grid where you needed to get signatures of people who fit the question in the box. A few of them were :

I was born in July (I signed a lot of them )
I have held a koala
I know 3+ languages
I can juggle
I prefer go/Rust and so on. In all honesty it was an amazing ice breaker and something to get to know people. After that there were a few unconferences followed by lunch and then more unconferences till 6:00 P.M. after that lightning talk sessions started and fortunately I got to represent KDE.

Unconference Session – From GSoC Student to Maintainer/Mentor

I also hosted one of the first unconference sessions titled:

From GSoC Student to Maintainer/Mentor

I wasn't expecting a large audience, but at one point the room was at its capacity around 40 attendees.

The audience included:

GSoC Organization Administrators
Mentors
Open source employees
Existing contributors
Google code-in students

The discussion focused on contributor retention after GSoC and how organizations can better support contributors beyond the program. It led to some interesting discussions where we found out what some organisations are doing.

Discussion Points (Noted by an org admin)

Leverage Contributors as Subject Matter Experts

GSoC contributors naturally become subject matter experts for the components they build. When new issues, bug reports, or pull requests relate to their work, proactively invite them to participate in the discussion or review. This helps contributors feel that their expertise is valued and keeps them engaged with the project beyond GSoC.

Improve Communication Around Pull Request Reviews

Complex pull requests often require focused reviews and may take longer than isolated bug fixes. While taking the necessary time for a thorough review is important, mentors should acknowledge review requests and, where possible, communicate an expected timeline. Even a brief acknowledgment improves the contributor experience.

Using Organization Stipends for Contributor Retention

Explore using the GSoC organization stipend to support promising contributors after the program ends. This could fund continued maintenance or feature development through a transparent platform such as Open Collective, allowing contributors to invoice for their work and remain actively involved with the project.

Recognizing Mentor Contributions

Mentoring requires a significant investment of time in reviewing code, guiding contributors, and providing technical support. Consider allocating a portion of the organization stipend to compensate mentors, recognizing their efforts and encouraging long-term participation.

KDE's Community Support

Another topic that generated considerable interest was KDE's support for its contributors.

I talked about how KDE sponsors some students to attend Akademy, and how I was also sponsored to attend the event, which a lot of people agreed organizations should've done (some did, a lot didn't) but a lot of people agreed that when an organization consider these things contributors stay.

After all the unconferences ended a lot of people came up to me saying mine was the best and I managed and engaged everyone in the best way possible ( I was on cloud 9).

Lightning Talk

One of the highlights was being selected to give a lightning talk. Only 18 participants were chosen, and I was one of them.

My GSoC project Join KDE is an advertisement for KDE itself, so the project itself became an easy conversation starter. It was a great opportunity to introduce KDE and make more people aware of the organization.

Although I did fumble the last part of my presentation it was more of me being confused where my slide went (some slides were misplaced) aside from that it went as any other informative talk but hey I was funny on the stage (refer to the pics) so people remember me! You win some you lose some, oh well.

Conversations Throughout the Event

Outside the sessions, I had some interesting discussions with contributors from different organizations. Some contributors showed interest in working wwith us while some showed interest in our eduction/science side but honestly it's hard to bring contributors over as they're in different domains, org admins/mentors or they're busy with their careers.

SU2 Foundation

I had a conversation with a maintainer from the SU2 Foundation, whose work focuses on computational fluid dynamics.

We discussed KDE's scientific and educational initiatives, including KDE for Scientists and several education-related projects. I also shared the KDE For You website as an introduction to the wider KDE ecosystem.

After Party

The conversations continued during the after-party on the following day.

I met a group of students who had become interested in open source after interacting with contributors throughout the event. They had originally attended as friends of another contributor.

One of them is now actively looking for a project to begin contributing to within KDE. YAYYY!

New Contributors

Several first-time contributors approached me asking about projects suitable for beginners.

I introduced them to a number of KDE projects and explained possible contribution paths.

But the same issue they're busy with the beginning of their careers.

Overall Thoughts

The Alumni Camp was one of the best ways to make people aware of KDE and I tried my best while i had fun ( we played uno there! Will bill the cards to the organization jkjk), a lot of people seemed intrigued and asked me to share some stuff about KDE to them or they'll try it on their own. Met someone from GNOME (they didn't get any lightning talk HA! I know, I know no inter project fighting that's bad) had some good conversations, teased the person from GNOME, had breakfast with them, and tried to make the most of the unconference session and the lightning talks to at least get people to know the name KDE!

Event Gallery

Redesigning Lokalize's Translation Memory Tab - Mid-GSoC

Navya Sai Sadu — Mon, 13 Jul 2026 00:00:00 +0000

The past three weeks were a mix of cleanup, debugging, completing the work concerning UI and understanding TMView( since I did not look into it during proposal period) and TMTab again to review my design choices and see if I'm going in the right direction.

Cleaning up TMManager and getting checkboxes working

First up was cleaning TMManagerWin, reformatting, removing now obsolete references and code. With that done, I resumed work on the per-project TM selection checkboxes.

The checkboxes are backed directly by DBFilesModel rather than a separate proxy layer. Overriding flags(), data(), and setData() on the existing model was the way to go. Qt's view renders the checkboxes automatically once Qt::ItemIsUserCheckable is set and Qt::CheckStateRole returns a value. Check state persists to ProjectLocal::selectedTMs() immediately on every toggle via saveCheckedState(), and reloads on project open via a Project::loaded connection.

One non-obvious issue I stumbled into and fixed myself was cleanupSelectedTMs(), which removes stale entries for TMs that no longer exist on disk, was being called immediately when Project::loaded fired. But DBFilesModel populates asynchronously via QFileSystemModel scanning the TM directory. The fix was deferring cleanupSelectedTMs() using QTimer::singleShot(), the same pattern used elsewhere in the codebase for async model population. loadCheckedState() itself runs immediately since it only reads from config and doesn't need the model to be populated. This was a subtle timing issue that only surfaced when testing with an actual project and multiple TM databases. In fact, cleanupSelectedTMs() itself wasn't thought of when planning.

After testing this end-to-end and verifying the .local config file was being written and read correctly, I merged this in.

Studying TMView's querying and why it can't help TMTab

Before touching TMTab's query logic, I spent time understanding how TMView (the suggestions dock widget in the editor) does its querying since my mentor suggested that it's querying might help designing something similar for TMTab's multi-TM quering.

TMView uses SelectJob which operates on TMEntry structs, it does fuzzy word-level matching, scores results, and is designed specifically for the suggestions workflow. It fires secondary DB queries only when the primary project DB scores below a threshold.

This is fundamentally different from what TMTab needs, it uses ExecQueryJob which runs SQL query against a DB and hands the cursor to QSqlQueryModel. The two systems aren't interchangeable, so the multi-DB approach for each has to be designed separately I guess. For TMView, the change is relatively small, loop selectedTMs() and fire one SelectJob per DB. For TMTab, it might turn to be little complex.

Removing the dbName combobox

With the TM list in TMManagerWin now showing checkboxes for selection, the dbName KComboBox in the search panel is redundant, users select which TMs to query via checkboxes, not a dropdown. I removed it from queryoptions.ui and cleaned up all references in tmtab.cpp, but some of them need workaround. The openFile() (RemoveFileJob) gets a TODO, to be fixed properly once multi-DB results carry their source DB name.

Debugging with GDB and Dr Konqi

My mentor reported a crash when opening the QA dock widget in the TM tab. This was a good opportunity to learn proper debugging with GDB, Dr Konqi, and reading backtraces.

After investigating, this appeared to be a preexisting bug unrelated to my changes. It's probably data-dependent and only triggers with specific content in the TM results view at the moment the QA dock repaints. It didn't reproduce on my machine. I might work on it later when I have time.

The years old chats on QtForum and StackOverflow were helpful throughout. Qt itself is so well documented!

I'm looking forward to see how translators would like the TMTab's glow up when the project is completed and all the changes get merged.

Redesigning Lokalize's Translation Memory Tab - GSoC Week 2 and 3

Navya Sai Sadu — Sat, 20 Jun 2026 00:00:00 +0000

The past two weeks went by fast. The learnings I gained while building the toy project I experimented around with Qt during Contribution Period are quite useful now. In the second week of GSoC, I ported the TM Manager from a separate dialogbox to TM Tab. It was done mainly for ease and with the reasoning that everything related to TMs can be in a single place. I kept most of the things as is. A lot of thought went into the UI Design.

The TM Manager is currently a standalone window which is accesible from any tab.

The "Manage Translation Memories" option is already available in the Tools Menu and again in the ToolBar of TM Tab since it's specific to it.

After the changes, pressing F7 or "Translation Memory" option from Tools menu will directly lead to TM Manager too as it is set on the left of TM Tab with a QSplitter. I believe this takes away a little redundancy in the design. This change is also justified pertaing to the future changes regarding Multi-TM selection and quering.

The buttons restrict resizing the splitter horizontally. Intially I put all the actions in a QToolButton as I thought putting them in a right-click context menu might render them undiscovered. But such menus were already being used in some other parts of the app( and obviously other KDE apps).

From coding perspective, all I had to do was instantiate it in TM Tab instead. Since, it was no longer being used as a window( which would also have worked), it no longer inherits from KMainWindow. It used Grid Layout which I think is not exactly needed and just used a VBoxLayout for simplicity.

The splitter state is saved and restored using existing methods.

The obsolete references and methods for TM Manager are cleaned up.

During Week 3, I added checkboxes to DBFilesModel for TM selection which will be used in querying later in TM View for suggestions, autofill etc. and TM Tab for search. In th beginning of the project, I proposed adding another proxy layer over DBFilesModel for the checkboxes to not to disturb other things. But for ease of work, consistent architecture( couldn't find multiple proxy layers being used in the codebase) and with the solace that it won't impact other methods using DBFilesModel for their specific purpose, I went ahead to add checkboxes directly to it.

This is a deviation from my GSoc Proposal wherein I proposed to replace Combo Box with a List Widget having entries with checkboxes for Multi-TM selection. Since there would be TM dbs on the left of the tab anyways, I thought of enabling selection there itself, than to have two places(TM Manager and the List Widget) listing all the TMs.

Setting new flag for checking, showing checked state with data() and storing selected TM names to a set is done. The checked state persistence is to be worked upon. This is where I got stuck. TM names were to be saved and loaded from global and local config based on user's selection but when my mentor reviewed that this complex setup probably is not the best, we reached back to translators who originally requested the feature.

Redesigning Lokalize's Translation Memory Tab - GSoC Week 1

Navya Sai Sadu — Sun, 31 May 2026 00:00:00 +0000

Hi! I'm Navya and am working on Redesigning Lokalize's Translation Memory Tab. Lokalize was created during Google Summer of Code several years ago. This also implies that the conventions to be followed are quite old.

The first week of GSoC was full of learnings and experiments as I had expected. There was no hassle of setting things up and all because I worked on Lokalize during Season of KDE. Things are going as per the plan and I am starting to gain momentum. The weeks ahead require more effort and time. I'm gonna share some of the knowledge gained and used as it might benefit me (to remember or come back to when needed) and other new contributors.

The project essentially resolves the bug and integrates the separate TM Manager Window into the TM Tab for ease.

KConfig

KDE provides devs with KConfig classes to auto generate methods to use for app's configuration settings. This site might also be of some help. Lokalize has lokalize.kcfg for app-wide configuration and projectbase.kcfg and projectlocal.kcfg for project-specific configuration. The latter one appeared to me more apt for user's personal settings such as per-project selection of TMs. A new entry was added to lokalize.kcfg for global default TMs.

There are also ".kcfgc" files which apparently act as config for the config files. So, the property of the entry added can be controlled there. In my case, it was to have mutators so as to be able to change the selection of TMs.

The setters and getters generated were used to write a method that returns a list of TMs to query across. These will also be used in the upcoming weeks when I finally create a UI for checking and selecting TMs.

Git

I always get to know something new and cool in the git world while working. My mentor told that master is like any other branch, it's just us that we treat it differently. I created a new branch to direct my MRs there since it'll be a long time till everything is ready to be merged into upstream.

Testing

The example provided here is a basic template which the rest of the tests present also follow. An article on the internet said that there's no point in writing tests for getters and setters (another discussion forum had - especially if those are auto generated) so I just took it as a chance to learn something new and get the hang of those methods.

I wasted quite some time only to figure out that I need to run the test from the build dir instead.

GSoC: differences of expectations between students and organizations

Johnny Jazeix — Wed, 28 Jan 2026 00:00:00 +0000

I've been administering KDE's participation in the Google Summer of Code program for the last few years (and mentoring on some). This post is just some personal thoughts on the differences between what the KDE organization expects and what usually the applicants want (I'm not in everybody heads, it's assumptions from my experience). I don't provide any solution (because I don't have any) and there is no judgment (both point of views are valid), just a personal point of view.

Applicants point of view

GSoC is a individual competitive program which can be a huge boost to start a career. There are usually two major reasons for the applicants to participate in GSoC:

the money.
the experience and the line in the CV for real life work.

There is, for a lot of applicants, no genuine interest in the projects (at least at the beginning, the first interaction is often "I want to start contributing to KDE and prepare for GSoC"), and they mostly want a GSoC slot. Small digression, on one of my projects, two people already asked to contribute and if we were doing GSoC, but after telling them that contributions are welcomed and we will only propose a topic if we feel enough confidence that the contributor would stay after, they told us they preferred to choose another project.

Contributors consider GSoC as an end of their studies, not a project they want to contribute after: there is also a change of life to consider between university life and work life and a balance to achieve when starting the latter (which could be in a different town/country) which may be a reason for the drop of interest.

Organization point of view

GSoC is an opportunity to welcome new contributors to our community. The organization usually expects from GSoC:

contributors willing to contribute regularly to their projects.
implementation (partial or total) of the proposed ideas.
having a positive return on investment (is the time spent mentoring worth the result?)

GSoC is mostly a step to have contributors learning about the projects, and contribute in the long-term. Long-term is purposely vague; what we expected for the GCompris project was the contributor would contribute at least one year and mentor for the next GSoC (so a loop was present, and applicants would also gain an experience on mentoring, while giving some relief to the other experienced mentors) but it can vary depending on the project.

For the return on investment, mentors do not consider it good having spent more than three months mentoring for projects they could have done in less time they spent to mentor the contributor. Helping someone grow is always personally rewarding but we still hope this person will also show us the results of the teaching by improving our projects in the future.

Impacts of the differences

There is a huge difference on the expectations. What can we do to reach a common ground where everyone is happy?

Organizations cannot force anyone to contribute after the GSoC end.
If money is the main motivation to stay, most organizations will not have money to hire applicants to work after (and do we want to hire someone only motivated by money? No, it's not OSS values, we love passion).
Find ways to create a real interest for the organization. In KDE, we have the chance to have tons of projects with different topics (astronomy, education, digital painting, video editing, scientific plotting, games, desktop environment, system administration, internationalization, ...) where it is easy to participate to other projects from time to time and learn new things if we are curious enough.
Be stricter on the entry point for organizations: explicitly say in the beginning that we expect a long-term relationship not just the equivalent of an internship. It should reduce the number of applicants and only keep the ones with a genuine interest (if applicants are honest of course).
Organizations/Mentors could reduce their objectives of GSoC and consider that contributors are here to produce and spend less time on training/mentoring, expecting contributors already know the basics, but this would totally spoil the nature of the program.

Another track is to find the projects where contributors stay / don't stay and understand the difference. Most of the big KDE applications don't manage to keep their contributors, while smaller ones do. Maybe as a contributor, it's because it's more difficult to take decisions, feel included/listened on large projects because they have a high maturity level/long-term contributors and a well-defined vision? Whereas on smaller projects, there are fewer constraints from the existing environment and it feels more rewarding and motivating to contribute there?

To conclude, here are the statistics for KDE retention the last years:

Year	Started	Completed	Active after 1 year	Active after 2 years	Active after 3 years
2018	20	17	5	5	4
2019	24	22	9	8	8
2020	21	19	2	2	1
2021	16	15	8	6	3
2022	7	6	5	1	0
2023	9	7	3	3	2
2024	10	10	4	2	-
2025	15	12	6	-	-

That is, an average of 15 people sign up each year, of which

an average of 90% finish
44% continued contributing 1 year later
28% continued contributing 2 years later
22% continued contributing 3 years later

We would of course love having more contributors staying at least one year but it's almost half and a quarter that stay active for a few years!