Mentorship 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.

Season of KDE 2026 – Final Blog

Keshav-Nanda — Tue, 07 Apr 2026 00:00:00 +0000

Greetings to everyone in the KDE community!

As SoK '26 comes to a close, this blog post summarizes the work done in the second half. Please refer to my mid-term blog post for further context.

My SoK task was to ensure all the .pot files generated have source references relative to the project root.

Upon discussion with my mentor, Finley Watson, and my teammate Aviral Singh, we decided to create merge requests to a throwaway repo made by our mentor to ensure that all the messy commits are cleaned up and functioning well. This was also done to ensure that the MRs don't create regressions of any kind.

I created an MR that modifies the createdesktopcontext.pl file. Instead of using lazy regex to manipulate the path string and extract a basename, I used Perl's built-in File::Spec->abs2rel to compute the correct project-root-relative path programmatically.

I also created MR !121 which makes use of Aviral's validation script to ensure that the logs generated match the format of Scripty's existing logs. The MR ensures that there is:

One WARNING in <file>: <message> line per bad path
One self-contained summary line per POT, always printed
Zero noise when everything is clean

Conclusion

Looking back, SoK has taught me a lot of things. I've learnt how to navigate complex codebases, read and write Bash and Perl, and deal with complex version control rather than just git add ., git commit -m and git push ;)

I've also realised how important commit history and messages are (which I never paid much attention to while developing personal projects). Overall, this has been an amazing and enjoyable experience for me and I would like to thank my mentor Fin for the guidance, and Aviral for being a great teammate throughout.

Season of KDE 2026 - Fixing the Glossary in Lokalize (Final)

Jaimukund Bhan — Mon, 06 Apr 2026 00:00:00 +0000

Greetings to the KDE community!

This is a blog which follows my previous post and includes the work I did in the second half of Season of KDE.

Improved manual Glossary term addition

There are two methods to add terms to the glossary. The first one is to highlight the source and target terms in the Editor Tab, and then using the context menu in the Glossary View to Define a New Term. The second is to manually add new terms through the Glossary Tab without any prior text selection. Previously, when a term had to be added manually, a blank entry was made first, which the user could then edit. This meant that multiple blank entries could be accidentally accumulated in the Glossary file. Users are now prompted to enter the source and target terms in a dialog box when trying to add terms manually, removing the need of creating blank entries.

Fixed the shortcut key for Previous Active Tab

The shortcut key for switching to the Previously Active Tab was not working properly as the currentChanged signal updated the current index of the m_mainTabs before the previous index could be saved to the previousActiveTabIndex variable. I updated the event filter to catch tab switches made through mouse clicks and replaced the integer variable with a widget pointer, since it would remain valid even if tab positions change, whereas an index-based would require calculations.

Making Plasma Setup More Mobile-Friendly: A SoK'26 Conclusion

Onat Ribar — Tue, 31 Mar 2026 00:00:00 +0000

Hey everyone! SoK '26 is wrapping up, so here's my final post. If you haven't read the midterm update yet, I'd recommend starting there — this post picks up from where that one left off.

Some relevant links:

TLDR: The project

Plasma Setup is KDE's first-run wizard: it greets you on a fresh install and walks you through account creation, keyboard layout, timezone, and basic system config. It was built with desktop screens in mind, and my project was to make it work properly on phones and tablets running Plasma Mobile without breaking the desktop experience.

Where the midterm left things

By the midterm I had worked through most of the UI issues: overlapping components, wallpaper disappearing on portrait layouts, the wizard not filling the screen on mobile, the hostname field overflowing, the timezone page's OpenStreetMap widget being too fiddly for touchscreens. Two MRs were open, one in plasma-setup and one in plasma-workspace for the timezone selector since that component lives there. The plan was to spend the remaining weeks getting them merged.

That's roughly what happened, though it took longer than expected. I requested a two-week extension so we could handle the review process properly rather than rushing it.

What the second half looked like

Mostly review cycles. Writing the MRs was one thing; getting them merge-readywas another. A fair amount of that time was spent in the terminal, checking diffs, rebasing, keeping the history clean, more than it was actually writing new code. Anyone who's worked on a shared codebase knows how that goes.

The MRs were fairly dynamic throughout. Ideas came up during review that hadn't been in the original scope, some made it in, some got tested and scrapped. The final diff looks quite different from what was there at first open, which is usually a sign the review process is doing its job.

What I did recalibrate to was the specific culture of OSS contribution. The conventions are different from a professional codebase: how commits are structured, how feedback is framed, what a well-scoped MR looks like in this context. Not a harder or easier bar, just a different one, and getting fluent in it is part of the work.

The open threads from the midterm

I flagged two things in the midterm that weren't guaranteed to get done: virtual keyboard handling and the kcm_keyboard dependency decoupling.

Neither got done. The virtual keyboard situation is an open design question for the project, not something I could resolve within this scope. The kcm_keyboard decoupling is something I'd still like to take a crack at. The underlying issue is real: a mobile setup wizard probably shouldn't need to pull in plasma-desktop. But testing showed it wasn't causing visible breakage in practice, so it got deprioritised in favour of getting the UI work properly landed. Worth picking up as a future contribution.

See it in action

Wrapping up

I participated in SoK '25 as well but had to drop out partway through, so finishing this one properly feels good. Plasma Setup on mobile is in a noticeably better state than it was ten weeks ago, and the changes are upstream, which is what matters.

I'm planning to keep contributing to KDE and take on more within the ecosystem. There's plenty left to do and I'd like to have a more permanent stake in it.

Thanks to Kristen McWilliam for the mentorship throughout, and to KDE and the SoK programme for running this. It's a genuinely good way to get people into open source contribution.

You can reach me on Matrix at @onatribar:matrix.org.

Until we meet again!

Season of KDE 2026: Wrapping up

Siddharth Chopra — Wed, 25 Mar 2026 00:00:00 +0000

Greetings!

As we're nearing the end of SoK 2026, I am writing to share my experience and progress since my previous blog.

The second half of my SoK project has been a real learning experience for me, about how contributions to KDE and open-source communities in general work. I also learnt the importance of thorough testing, bug fixing, and polishing that is required before shipping any software.

Technical update and challenges faced

Till the halfway mark, I was able to complete a rough working version of the source mode editor. But after feedback from my mentor, I realized that a lot of work was still left to be done.

Firstly, there were a lot of repeated lines of code in my solution, as I had essentially split the existing editor into two - the rich editor and the raw editor. This meant that a lot of the functionality was common between the two editors, and I had re-used existing code for that. This was true for both the QML pages and the C++ document handlers. As I now realize, that would have been a nightmare for maintainability, as any single fix or change would have to be made in two places.

The fix for the C++ part seemed to be obvious: to use inheritance. So I decided to make the RichDocumentHandler and RawDocumentHandler inherit from a common parent, the DocumentHandler. DocumentHandler now contained all the common methods, significantly reducing repeated lines of code.

Similarly on the QML side, I made a parent component, EditPage, and made the Rich and Raw edit pages inherit from it. This caused some issues (mostly related to property sharing between components) that were eventually fixed.

A major issue I faced was caused by the fact that my MR essentially removed the existing EditPage.qml and documenthandler.cpp (although files with the same name are still present, they serve different purposes). Their contents were divided into two files - the rich and raw versions respectively. But while I was working on my feature, other contributors were still modifying the old files. Git can't handle this automatically, because the old file is in a way completely changed. This meant that I had to manually go through each commit to the old files, and move the changes accordingly to the new files. This proved to be a major headache, and caused me (and even Carl) to spend considerable time manually rebasing. So when finally the feature was merged, it was a sigh of relief, as we wouldn't need to manually maintain it anymore!

Apart from this, I also added a spell-checking capability to the editor, using Sonnet.

Demo

Learning and experience

I was grateful to see my work get published in Marknote 1.5 - and also felt a responsibility at the same time. Source mode is an asset for the app, but at the same time any bugs in my work are also a liability!

I learnt how a professional application is different from a hobby project, and how the quality and rigour of work should reflect that.

It was a really fun experience working with the KDE community and I'd like to thank my mentor Carl Schwan for always being there to help!

SoK has been a great first stepping stone to introduce me to the community, and I'm looking forward to contributing to Marknote and other apps even after the program!

Season of KDE 2026 - Improving mentorship.kde.org for better onboarding of new contributors

Aryan Rai — Sat, 21 Mar 2026 00:00:00 +0000

Greeting everyone! I am Aryan.

I have only just started my open source journey and was glad to be a part of SOK program. I really learned a lot which I think I otherwise would have not. With this blog I will be sharing about the project I worked on and also my learnings and future endeavour.

For the last 2 months me and my fellow partner Advaith SK worked on ways on how to improve the existing mentorship.kde.org so that it is more accessible and user friendly for new contributors as well as we tried to structure the internals of the website for better code readability and resuabililty.

Why was this project relevant

mentorship.kde.org is basically the first page a new contributor visits when exploring about KDE. So it is very important for the website to not overwhelm the new contrbutor but provide all the relevant information and links in a ordered and systematic way.

What problems did I identify

We noticed a gap in the project, KDE organizes many programs throughout the year for mentoring and developing more and more contributors. But we noticed that there was no single page that lists all the relevant programs a candidate might be interested in. Moreover on the developer's side we noticed that the repo of mentorship.kde.org is using many different cards for displaying its data throughout, and each card was schematically different than the others but in the end all of them were pretty much serving the same purpose.

What were the solutions

To solve this, I built a separate /programs page for the website, whose task is to only list all the programs that KDE organizes throughout the year. And to solve the developer's side problem, I standardized the cards. So basically for each component using their own rules for displaying cards, what I changed was I implemented a central card.html and card.scss which governs all cards. In case of some variations required I introduced the $variants feature of Hugo to carefully keep the uniqueness of cards required for each page.

Merge requests

Miscellaneous

I also noticed that in the resoruces page, the resources listed are relatively few, moreover the hyperlinks provided were also not updated. So I added more resources there and also updated the broken links present previously.

Future work

To attract more new contributors, in future we can also extend our project to have a hall of fame section where there is list of blogs of all graduated students of a particular program.

Final thoughts

A big thank you to my mentors, drowsywings and paulb, for thoughtful guidance and constant support throughout the project.

I have grown in this season with more confidence, more curiosity, and even more appreciation for the people behind free software infrastructure. I will be proud even if this work helps just one curious contributor to get onboard with the KDE ecosystem.

[SoK 2026] Appium Testing for Lokalize

Vishesh Srivastava — Fri, 20 Mar 2026 00:00:00 +0000

Hey there! I'm Vishesh Srivastava, and this is the full write-up for my SoK 2026 project: adding Appium-based UI tests to Lokalize.

So what's Lokalize?

It's KDE's translation tool - the app translators use to work with PO files and manage translation projects. It already had unit tests, but no UI tests. So the goal of this project was to setup a UI testing framework using Appium.

The first task: Bug 514468

Before Appium work started, my first task was Bug 514468. The issue was that copyright year strings in PO headers could become very long, like:

2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021

instead of the shorter:

2006, 2010-2015, 2017-2021

I was asked to write a failing test first, so I added a placeholder simplifyYearString function and wrote a unit test for the expected collapsed output. At first it was pushed with QEXPECT_FAIL, since the actual implementation was meant to be done separately.

This was small compared to the main project, but it helped me get comfortable with setting up KDE's build system and how tests are added to Lokalize.

Building the Appium setup from scratch

Lokalize had no Appium setup at all, so this part started from zero.

The first tests were simple:

simple_open.py just opens Lokalize and closes it
file_open.py opens the File menu and checks that the open dialog path works
workflowtest.py simulates an actual translator workflow

That last one was the main test I was aiming for. It opens a .po file with untranslated entries, types translations into the editor, uses "Approve and Go Next", checks that the UI updates properly, verifies the status bar reaches Not ready: 0, and finally saves the file.

That made it a proper end-to-end test.

Problem encountered in the last test

Appium depends on accessibility information to find and interact with widgets. Lokalize's editor fields did not expose accessibility ids for Appium to call them (found using accessibilityinspector).

So I had to make changes in editorview.cpp to add object names and accessible names to the widgets. Without that, the test scripts could open the app and click menus, but they were basically blind when it came to the translation editor.

Other KDE apps with Appium tests, like Dolphin and KCalc, had tests which used these and were useful references here.

Below is a demo of this working:

Making it run with the rest of the test suite

The next step was integrating the Appium tests into CMake so they could run as part of Lokalize's normal test flow.

I added an appiumtests/CMakeLists.txt and a BUILD_APPIUM_TESTS option, so the tests can be enabled and run through the normal KDE tooling:

kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options="-DBUILD_APPIUM_TESTS=ON"

That was important because UI tests are much less useful if they live outside the project's regular test workflow. The BUILD_APPIUM_TESTS option was kept because it was not advised to run Appium tests in the CI/CD.

Another issue: Making the tests independent of the local user setup

One issue was that on opening, Lokalize asked for a name and email address which I was earlier typing manually. This was undesired since tests had to be run without user intervention.

So I added a file test_support.py, that creates a temporary config directory, writes a minimal lokalizerc, and launches Lokalize with that isolated configuration. That way the tests do not depend on my own existing settings or require any user input.

I also reused that helper across the test files so they stopped repeating the same Appium setup code again and again.

Writing a failing bug test

After the main workflow test, I also added another Appium test for a real UI bug: after closing a project, translational tab menus should become disabled.

This test is in project_close.py. It opens a project, closes it, and then checks that menus like Edit, Go, and Sync are disabled.

Fixing how the tests are executed

At first, the Appium tests were being discovered and registered individually in CMake. The next task was to run them from a single run_all.py runner. Now all the tests use a single KWin instance like they do in other projects like Dolphin.

This also makes writing new tests simpler since adding a test just means adding a new line in the run_all.py. So instead of CMake looping over every Python file, it now calls the runner once.

There was also one annoying issue here: --run-tests was reporting success even when one of the Appium tests had failed when run manually. Because of that, I had to return sys.exit(1) explicitly from the runner when the test result was not successful. Without that, the tests looked successful even after failing.

Below is a demo of this working:

Outcomes achieved

By the end of the project, Lokalize had:

a working Appium test setup
basic tests for startup and opening files
a full workflow test covering translation editing and saving
helper files to make tests cleaner and independent of local user config
integration into the normal test system through CMake
a single test runner file
documentation on how to run/write tests.

Final thoughts

This was a really enjoyable project. I got to work on Appium testing, the KDE build system, and a bit of bug hunting.

Many thanks to Finley Watson for his guidance throughout the project and for helping whenever I got stuck.

The best part for me is that the work is extendible. New Appium tests can be added without rebuilding the whole setup from scratch, which was the main point of the project in the first place.

Season of KDE - Midterm Blog

Keshav-Nanda — Fri, 20 Mar 2026 00:00:00 +0000

Hello world!

My name is Keshav Nanda and I had the opportunity to work with Scripty, a KDE bot that extracts translatable strings from various KDE applications and sends them to KDE translators.

I worked on the issue of standardizing translation reference paths across all KDE projects and this blog summarizes my progress up until the 4 week mark.

Week 1 and Week 2

Couldn't get much work done as I was occupied with university exams.

Week 3

Got my feet wet with the actual source code, went through MR 90 and developed a basic understanding of the problem that needed to be solved, that is to ensure that all .po files generated by Scripty are relative to project root.

Week 4

Helped my partner Aviral in testing his implementation of merge request 116 and added to the KDE projects he validated. This MR added a docker environment to standardize the testing process and made changes in extract_metainfo.sh and extract-messages.sh to enforce relative file paths.

Conclusion

The first 4 weeks have been a great learning experience. I got familiar with Scripty's codebase, understood the core problem of inconsistent translation reference paths, and contributed to validating the fix. The goal going forward is to continue testing and work towards getting the changes merged. I want to thank my partner Aviral Singh and my mentor Finley Watson for the guidance and support throughout!

Onwards and upwards!

Season of KDE 2026 - Task - 3 Lokalize

Kumud — Fri, 20 Mar 2026 00:00:00 +0000

Progress Report — Midterm — SOK 26

Mentor: Finley Watson
Project: Lokalize

Week 1

Week one was basically just ensuring that I have a good understanding of the relevant code in the repository. I suggested a good approach would be to write a summary of the behaviour of the classes and functions involved. This turned out to work really well.

Week 2

Now that I knew how things worked in the codebase and the flow of functions, it was the right time to think about solving the issue. I had intuition about that since the entries did not respect the filtering order. This was largely because they used the wrong layer to fetch entries and if we used the proxy model it should work well. However, now the other condition that we had to respect while moving was to only go to unapproved entries. So I had to merge the filtering and condition checking.

The final approach I thought might work was to add a helper function that just gave the correct index to move to and wow, things started working :smile:

It was time to test it. Finley helped me with that. And I have to admit that once I resolved one edge case, there was another. This continued for a while and it was irritating, thinking that this will fix everything finally and boom another case appeared 😅.

We thought about an upgrade in navigation. This was moving to the next entry in navigation in a cyclic order. Finley and navya had a discussion over it on the mailing list and finally concluded that it was not required at all.

Finally the MR was merged. Nothing felt better than seeing it finally being a part of code that people across the globe are using... so cool 🔥

Results

Final MR.

Week 3

While fixing things up in the previous week, I had already seen many shortcuts that required a fix, and that the behaviour sometimes did not made sense.

I started with testing the shortcuts that are supposed to go to the first and the last entry, but somehow showed different behaviour each time. This was because of the widget currently in focus, so the behaviour of many shortcuts depends upon the widget you are using.

This was new information for me, so I researched how widget focusing actually works. Through this, I learned about the order in which applications process keyboard shortcuts and that some shortcuts are handled internally by Qt itself.

Week 4

I went ahead and checked the behaviour of other navigation shortcuts:

next/previous fuzzy entry
next/previous untranslated
next/previous bookmark

Results

Understanding of similarity in the behaviour of these shortcuts.

Weeks 5 and 6

I extended the work from the previous weeks and had my semester exams.

Week 7

I reported a bug in the behaviour of the next/previous bookmark in navigations.
I implemented next/previous bookmark based on navya’s approach

Season of KDE 2026 - Task - 3 Lokalize

Kumud — Fri, 20 Mar 2026 00:00:00 +0000

Week 0 progress Report — SOK 26

I am Kumud, a third year student at IIT Roorkee, and I am working as a mentee under the guidance of Finley Watson for SOK 26.

Over the past few weeks, I have been contributing to the Lokalize project and gaining familiarity with the codebase and the underlying architecture.

Initial setup

The first major task for me was to get the Lokalize code running on my local PC. There were many crashes that I encountered during the setup process. I initially thought that the issue might be related to my operating system, so I decided to try using a different one.

I installed KDE Neon in a virtual machine on Linux, and finally the code started running. However, I was not very happy with using a VM, since I already had limited storage on my PC and now it was being split with the virtual machine as well.

Later, when I joined the Matrix channel, Finley and Navya helped me with the setup. I realized that the main issue was simply that my Ubuntu installation needed to be updated. After updating Ubuntu, I was able to run Lokalize directly on my system.

Finally, I started working on Linux itself, which I was already more accustomed to using.

Getting familiar with the codebase

Before planning the proposal for Lokalize, I had to gain a good understanding of the code and the tools we were going to use.

To become familiar with a general codebase and to get comfortable using Git / GitLab, my mentor assigned me a task. The task was a basic one: adding a package to the repository metadata required to build Lokalize.

Results

Understanding of the codebase and about using GitLab.
Used repology to map different package names across different OSes.
MR approved.

Season of KDE 2026 - Lokalize Glossary Tab Improvements (Midterm)

Aditya Sarna — Thu, 19 Mar 2026 00:00:00 +0000

My name is Aditya Sarna, and I have been working on Lokalize, a translation software, as part of Season of KDE 2026. Along with my fellow mentee Jaimukund Bhan, I have been assigned to work on improvements to the Glossary tab, including both UI/UX enhancements and addressing a substantial list of bugs.

How I got here

I first came across KDE while exploring organizations that had participated in Google Summer of Code (GSoC) in previous years. During this process, I also discovered Season of KDE (SoK), which felt like a great opportunity to get involved. I joined the KDE Mentorship Matrix chat, where Finley Watson was kind enough to guide us. I then explored the list of tasks under Lokalize for SoK in detail and drafted proposals for the first two tasks.

While researching the first idea, I came across the KDE Human Interface Guidelines, which helped form the foundation for the suggestions I put forward in my next proposal. I was delighted to be selected for the second task.

Setting up

We started a little early, getting everything in order. I spent time familiarising myself with the Lokalize codebase and understanding the platform. I also joined an early discussion on the possible direction for creating and saving the glossary file, and that work was subsequently completed by Jaimukund. In the meantime, I began scoping out the necessary UI/UX improvements.

UI/UX improvements

The task involved replacing plain text labels ("+", "-") with proper icon buttons and adding tooltips to all the add and remove buttons on the page. [MR 273].

I also created a Figma design for a redesign of the deletion workflow, which had been suggested by the KDE Visual Design Group. The goal was to improve the workflow for translators.

Engaging with translators

One of the most valuable steps in this project was reaching out to the translators mailing list. The insights we gathered from that discussion helped us uncover more issues and articulate the problems better. The translator's real-world experience gave us a much clearer picture of the pain points in the current Glossary workflow and we subsequently worked through those issues in the weeks that followed.

A bump in the road

Progress slowed for a while as I got caught up with university exams. Balancing coursework alongside an open-source project was challenging.

Simple yet useful

The first issue I worked on after returning was a simple yet useful change that I had also proposed earlier. This involved moving the add and remove buttons to sit next to the search bar.Grouping them together created a clearer call to action, and the button placement now mirrors the Glossary editor pane, helping standardise the UI and match user expectations.

Acknowledgements

A huge thank you to my mentor, Finley Watson, for his constant guidance, patience, and thoughtful feedback throughout this project. Thanks as well to the Visual Design Group and the translator community for their valuable input, and to the KDE community as a whole for being so welcoming. Contributing to software used by translators all over the world has been an incredibly rewarding experience. I look forward to continuing to give back to KDE long after SoK is complete.

Season of KDE 2026: Transforming mentorship.kde.org into a Complete Onboarding System

Advaith Sathish Kumar — Thu, 19 Mar 2026 00:00:00 +0000

Eight weeks ago I was nervously setting up a Hugo project I'd never touched before, reading through someone else's merge requests trying to understand what I was supposed to build on top of. Today, mentorship.kde.org is a meaningfully better place for anyone trying to find their way into the KDE community. That's a good feeling.

I'm Advaith, a second-year Computer Science student from India. This was my first time contributing to open source and I couldn't have picked a better place to start than KDE.

The project

My task for Season of KDE 2026 was to transform mentorship.kde.org into a proper onboarding system for new contributors. The foundation was already there thanks to @drowsywings's GSoC 2025 work, but several pages had placeholder content, buttons went nowhere, and there was no real sense of flow.

I know this because I was that confused visitor. I found this project by experiencing the problem it was trying to solve, which made working on it feel genuinely worthwhile.

I worked alongside my co-contributor Aryan Rai. Aryan handled the /programs and /resources pages, while I focused on the homepage and the /mentees showcase. Splitting things up early was one of the better decisions we made. It kept us from stepping on each other's work and meant we could move independently for most of the program.

What got built

The homepage work was mostly about making things actually work the way they were supposed to: routing buttons to real pages, filling in content that had been sitting as placeholders, making the news section feel like actual news. A lot of it sounds simple when described but the details add up fast.

The /mentees page was the more interesting challenge. It went from being essentially empty to having real data, pagination, and client-side filtering by year, program, and technology. The filtering was originally a stretch goal but I'm glad it made it in.

One decision that took more thought than I expected was how to store the mentee data. I went back and forth between grouping mentees into cohort files (one file per year/program) versus individual Markdown files per mentee. The grouped approach is simpler to manage at first, but individual files make filtering far more straightforward, as Hugo can use front matter fields like year, program, and technology directly as filter parameters without any external code. That made the choice clear.

My mentors Anish Tak and Paul Brown were genuinely great to work with. Paul introduced us to the project and set the direction early on and Anish carried that through the whole program by hosting bi-weekly meets, reviewing all our MRs, and always being available when we we were stuck. I'm really grateful to both of them for making this such a good first experience in open source.

What I take away

The biggest thing I learned isn't a technical skill, it's how to work inside something that already exists. Reading a codebase you didn't write, making changes that fit the patterns already there, coordinating with someone else so your work doesn't clash with theirs. These things don't come up much when you're building projects on your own, and SoK taught me that in a way no tutorial could. I came in knowing how to write code. I left knowing how to write code that other people have to maintain.

I also just really enjoyed it. The KDE community is welcoming in a way that makes you want to stick around, and I intend to.

What's next

There's still work to be done on mentorship.kde.org. The pathway navigator deserves more attention, not all previous mentee data has been added and there's always more mentee data to add, as new program cycles wrap up. I'd like to be part of it.

If you're a student sitting on the fence about contributing, mentorship.kde.org (and in the future join.kde.org) exists to help you take that step. Hopefully it's a little easier to navigate now :)

Season of KDE 2026 - Untangling Scripty's File Paths

Aviral Singh — Sat, 14 Mar 2026 00:00:00 +0000

Hi everyone, Aviral here :)

I have been a past contributor to the KDE ecosystem for a few projects like Okular and Spectacle. KDE was the first organisation I ever worked with in my open source journey and now I am very excited to share the update of my Season of KDE 2026 project.

Over the past few months, I worked on KDE localization infrastructure with a focus on Scripty along with my partner Keshav Nanda, improving how source file paths are recorded for translators.

Scripty supports translation workflows across the very large KDE ecosystem. During this project, a lot of fixes were shipped to Scripty and validation was run across more than 600 projects, which made it possible to test improvements at real KDE scale and confirm that the results are dependable.

Why paths matter

For those unfamiliar, Scripty is the backbone of KDE's localization pipeline. It handles the extraction of translatable strings from source code into .pot files, which are then translated by our amazing community.

Historically, some extraction scripts generated absolute paths or inconsistent relative paths. My mentor, Finley Watson, originally initiated the effort to fix this in MR 90. Without full project relative paths, we ended up with "ambiguous" references in PO files that didn't clearly point to a single source file within a repository. This makes it harder for translators to find context without confident reliance on these references.

Why this work mattered

We discovered the main issue was not missing files (at least for 99+% of the projects). The real problem was path ambiguity.

In parts of the extraction pipeline, source references were sometimes recorded as file basenames or as paths that were not consistently project relative, which made references ambiguous in repositories with duplicate file names. Loads of modern KDE repositories often contain many files with the same name (T-T).

For translators, this creates friction in daily work:

Source navigation in tools such as Lokalize becomes less reliable
Context gets confusing and unreliable when similar file names exist across multiple components
Name collisions make it harder to trust where a string truly comes from

What was improved

Building on the direction already present in the project, I have focused on making path handling consistent and easier to validate.

Normalization and wrappers

To fix this systematically across l10n-scripty, I implemented a set of sanitization wrappers. These extraction wrappers were added and/or improved so source references are kept in project relative form in generated output:

kde_xgettext
kde_extractrc
kde_extractattr

This helps ensure each reference points to a precise location inside a repository.

Metainfo extraction flow

The metainfo extraction path handling was updated so references are resolved in a project relative way rather than relying on short file name matching. This improves clarity for AppStream and related metadata sources too.

Validation improvements

validate_paths.sh -> the prime path verifier script, was strengthened to check not only missing files but also ambiguous references caused by duplicate file names in different directories. This greatly assisted in debugging and understanding where the issues stem from.

Verification results

A full extraction and validation cycle was run in a controlled Docker environment across 600 plus (all) projects. The latest results showed clean and correct path resolution in most projects with just a dozen edge case ambiguities and missing paths not fixed by current improved wrappers.

Although this might be a good enough fix, it isn't complete - the endgame remains.

Remaining work

There are several key areas on the checklist like:

Completing the coverage for the remaining fixable projects by hardening the metainfo extraction logic for complex projects.
Communicating with the community regarding the fixes done by me. As I have still not made an actual MR, there is a great chance that this fix isn't optimised and might have some oversights.
Finalizing the validate_paths.sh suite along with my mentor for integration into CI to prevent path regressions.
Getting the fix verified locally by both my mentor and my mentee partner.

Final thoughts

This project has been a wonderful learning journey through the infrastructure that quietly powers localization for KDE. It was deeply meaningful to contribute improvements that make translator workflows clearer, faster, and more trustworthy.

A big thank you to my mentor, Finley Watson, for thoughtful guidance and constant support throughout the project. Thank you as well to everyone in the KDE community who reviewed ideas, shared feedback, and helped move this work forward.

I have grown in this season with more confidence, more curiosity, and even more appreciation for the people behind free software infrastructure. I am proud that this work would help translators do their best work with better context and fewer obstacles, and I am genuinely excited to keep contributing to KDE.

Happy translating 💙

Follow progress and contribute on KDE Invent and join us in making software more accessible for people everywhere.

Making Plasma Setup More Mobile-Friendly: A SoK'26 Midterm Update

Onat Ribar — Thu, 12 Mar 2026 00:00:00 +0000

Hey everyone! I'm Onat, and I'm a bit past the halfway mark of my Season of KDE 2026 journey. Here's what I've been working on!

For reference, here are some relevant links:

Project proposal
Status report of progress thus far
Project repositories of plasma-setup and plasma-workspace

The project: Plasma Setup

Plasma Setup is the wizard that greets you on a fresh KDE install and walks you through account creation and basic system configuration. When I started, it was very much built with desktop screens in mind, and this shows when you try to run it on a phone.

The project is about making Plasma Setup work properly across tablets and mobile phones running Plasma Mobile, without breaking the expected behaviour of Plasma on desktop. My work so far has been focused on UI and UX, making it adaptive with Kirigami.

Another area of interest was a dependency issue, in which Plasma Setup currently pulls in kcm_keyboard from plasma-desktop, which was awkward for mobile systems. Due to time constraints and priorities, we haven't pursued this yet, but I will make sure to comment on it in my next blog post!

What I've done so far

The first couple of weeks were mostly about getting ready: setting up VMs running both KDE Desktop and Plasma Mobile spins, reading through the codebases of plasma-setup and plasma-mobile, figuring out just how tightly coupled the kcm_keyboard dependency actually is, as well as refreshing my knowledge of QML/Kirigami and testing the GUI to spot any troublesome areas.

One early relief: Plasma Setup already runs on Plasma Mobile without crashing! But "runs" and "looks good" are very different things, and there were plenty of layout issues to address.

From weeks 3 through 7, the main deliverables were:

General fixes for overlapping, overflowing, and misaligned components.
Fixed wallpapers not showing in narrow layouts.
Expanded the wizard overlay to fill the screen on mobile.
Reworked the Time and Date page. The existing OpenStreetMaps map widget was too fiddly for touchscreens to navigate, so I replaced it with a clean region and timezone dropdown pair. This touched plasma-workspace as well as plasma-setup.
Disabled auto-capitalize and autocorrect on username and hostname fields, which are annoying on a phone keyboard.
Hid the landing screen buttons on mobile during wizard navigation to prevent accidental taps.
Endless rounds of testing and reverting changes that didn't make the cut.

There was also a lot of investigative work early on: checking for tight coupling, testing across virtualized Plasma Desktop and Plasma Mobile environments, and verifying behaviour on different CPU architectures. Not exactly glamorous but it was necessary!

One thing that really improved my productivity later on: I'd been avoiding the nested Wayland compositor for development because of this warning in the plasma-setup readme file:

"It is not recommended to install this on your system — you should use a virtual machine instead. Installing this on real hardware will leave behind files not trivially uninstallable and could leave your system in a non-function state."

That warning genuinely spooked me, and I stayed in VMs longer than I needed to. They're safe, but iterating on UI components in a VM was inconvenient and frustrating. My mentor pointed me toward kde-builder and running the applications on a nested Wayland compositor, which upon adoption really sped things up and built my confidence. I wish I'd made the switch sooner!

What hasn't gone so well

Not everything went to plan, but that's expected in a project like this.

The virtual keyboard situation is still on hold. How Plasma Setup should interact with on-screen keyboards is a bit of an open question, and I've put that aside to focus on the layout work first.

The dependency side of things (decoupling kcm_keyboard) is also not started yet; it's been pushed to the later weeks of the project as a side objective, and not only am I running out of time, but it's the part I'm most uncertain about. Refactoring something that touches both plasma-desktop and plasma-workspace without introducing regressions is going to need careful testing. Whether this module should be separated is a different concern as well. I will have more to say about this in my final post.

What's next

The remaining weeks will focus on final UI polishing based on feedback and getting MRs across the line. A well-polished Plasma Setup on mobile would be a meaningful step for Plasma Mobile as a whole; first impressions matter, and the setup wizard is literally the first thing a new user sees.

Special thanks to my mentor Kristen a.k.a. Merritt for their guidance. The regular check-ins and assistance outside of that have made a real difference for keeping things on track.

Cheers!

[SoK 2026] Halfway update: Appium Testing in Lokalize

Vishesh Srivastava — Sun, 08 Mar 2026 00:00:00 +0000

Hey there! I'm Vishesh Srivastava, and we're at the halfway mark of my SoK 2026 project — writing Appium-based UI tests for Lokalize. I was a bit late for the halfway mark, but we're still on track.

So what's Lokalize?

It's KDE's translation tool — the app that translators use to work with PO files and manage translation. It does its job well but it had zero UI tests. None. My job this SoK is to fix that.

The starting days (January)

My first task was Bug 514468 — where copyright year strings in PO headers would be very long like 2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021 instead of the more concise 2006, 2010-2015, 2017-2021.

I was asked to write a failing test first. So I added a simplifyYearString placeholder function, wrote a unit test that expects the collapsed range output, and marked it with QEXPECT_FAIL since the actual implementation was going to be done by someone else. It was updated to expect to pass when the bug was fixed.

More importantly, this got me comfortable with KDE's setup, kde-builder, and how the testing framework works.

The main work: Appium tests (February – March)

This is where the real fun began. Lokalize had absolutely no Appium setup, so everything was built from the ground up.

First steps

My first tests were very simple. simple_open.py literally just opens Lokalize and closes it. That's the whole test. file_open.py was the next step: open the app, click File, click Open, and confirm the dialog shows up. Not much but you have to crawl before you can walk.

A bug I encountered

Here's something I found: Appium finds UI elements through accessibility properties, and Lokalize's editor text fields didn't have any (found using accessibilityinspector). So my test scripts were essentially blind — they could see menus and buttons but couldn't interact with the actual editor. I had to edit editorview.cpp to add object names and accessible names to the widgets to actually get Appium to see them.

Other KDE apps with Appium tests (Dolphin, KCalc) already had these, but nobody had needed them in Lokalize before. These were my reference for writing the code.

The workflow test (the one I'm actually proud of)

workflowtest.py is the test that simulates what a translator would actually do:

Open a .po file with two untranslated entries
Type a translation into the target field
Hit "Approve and Go Next"
Do the same for the second entry
Check if the editor tab UI was updated successfully
Check that the status bar says Not ready: 0 — meaning everything's translated
Save the file

Below is a demo of this working:

It's a proper end-to-end test.

Integrating with CMake

To make it so that these tests run along with all other tests with kde-builder --run-tests, I added a CMakeLists.txt for the appiumtests directory and added it into the project's build system behind a BUILD_APPIUM_TESTS option:

kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options="-DBUILD_APPIUM_TESTS=ON"

Now the tests integrate with the Appium tests just like they do in other KDE apps.

Next steps

Writing failing tests for bugs
Edge case tests

Final thoughts (for now)

It's been a enjoyable experience and many thanks to Finley Watson for offering great help along the way.

Halfway there. Let's see what happens next.

Mentorship on KDE Blogs

Redesigning Lokalize's Translation Memory Tab - GSoC Week 9

Week 7

Week 8

Week 9

GSoC 2026: Building Join.Kde.Org

Intro

Week 6: Contribute/suggest

Week 7: Navbar

Week 8: Work on Projects

Week 9: Incubate projects

Week 10: read page/ suggest page improvement

Week 11: Divulge Page

Week 12: Events Page

Related Merge Requests

My Own Development

Conclusion

How to Reach Me

GSoC Alumni Camp Delhi 2026

GSoC Alumni Camp Delhi 2026 – My Experience

Unconference Session – From GSoC Student to Maintainer/Mentor

Discussion Points (Noted by an org admin)

Leverage Contributors as Subject Matter Experts

Improve Communication Around Pull Request Reviews

Using Organization Stipends for Contributor Retention

Recognizing Mentor Contributions

KDE's Community Support

Lightning Talk

Conversations Throughout the Event

SU2 Foundation

After Party

New Contributors

Overall Thoughts

Event Gallery

Redesigning Lokalize's Translation Memory Tab - Mid-GSoC

Cleaning up TMManager and getting checkboxes working

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

Removing the dbName combobox

Debugging with GDB and Dr Konqi

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

Redesigning Lokalize's Translation Memory Tab - GSoC Week 1

KConfig

Git

Testing

Season of KDE 2026 – Final Blog

Conclusion

Season of KDE 2026 - Fixing the Glossary in Lokalize (Final)

Improved manual Glossary term addition

Fixed the shortcut key for Previous Active Tab

Making Plasma Setup More Mobile-Friendly: A SoK'26 Conclusion

TLDR: The project

Where the midterm left things

What the second half looked like

The open threads from the midterm

See it in action

Wrapping up

Season of KDE 2026: Wrapping up

Technical update and challenges faced

Demo

Learning and experience

Season of KDE 2026 - Improving mentorship.kde.org for better onboarding of new contributors

Why was this project relevant

What problems did I identify

What were the solutions

Merge requests

Miscellaneous

Future work

Final thoughts

[SoK 2026] Appium Testing for Lokalize

So what's Lokalize?

The first task: Bug 514468

Building the Appium setup from scratch

Problem encountered in the last test

Making it run with the rest of the test suite

Another issue: Making the tests independent of the local user setup

Writing a failing bug test

Fixing how the tests are executed

Outcomes achieved

Final thoughts

Season of KDE - Midterm Blog