Navya Sai Sadu on KDE Blogs

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.

Mid-SoK Blog

Navya Sai Sadu — Wed, 04 Mar 2026 00:00:00 +0000

I'm half-way through the Season of KDE 2026 and wanted to share the journey so far.

I had subscribed to the kde-soc mailing list after I returned from IndiaFOSS'25, where I met KDE contributors who really encouraged me to join the community and told me that one can always learn while building. The first step, always, is to start. Then I got carried away with life until I saw "call to action" in my mailbox in January. It was about SoK'26. I had then recently set up Kubuntu and was in awe about what people can build out of passion and by collaborating with others. I felt mentorship was the way to get started. I explored the projects and found Task-3 under Lokalize as something that I can contribute to while learning new skills- programming in CPP, debugging, and exploring an old repo.

Here's everything i did before the season officialy began.

Before Proposal

I installed ==Lokalize== and reproduced the bug.
Cloned the repo. Used grep to find “Approve and go next” in codebase. Turned out EditorTab::gotoNextFuzzyUntr() is the origin of bug. I thought about "Approve and go prev" and tried that. It was buggy too!
Wrote proposal

After Proposal

kde-builder failed due to missing libraries. So after lot of fixes, i did ubuntu update to 25.10(has qt6). *Created a test branch and added debug log in forementioned method.

Before 23rd

Got myself acquainted with Kate.
Fidgeted around files to understand architecture.

Got to know about

qDebug()
why use .h and .cpp files
LSP

The weekly status reports contain links to supoorting documents, commits and MRs.

Week 1

Spent more time understanding the repo, the files,classes and methods which were involved in the bug using debug logs, grep and manual look-over.
Wrote a few comments to document better.
Had an introductory call, was nice to know the contributors.

Week 2

Researched past commit to understand the intent of navigational shortcuts.
Added SPDX license headers( did not know it was being actively developed in GSOC too). Aided Kumud by sending an email to the KDE i18n mailing list regarding the cyclic traversal on entries for keyboard shortcuts in the Translation Units View. Typically, KDE applications don't use that, as followed from the replies and was not needed.
Had a group call for understanding rebase but i still mess up sometimes.

Week 3

While Kumud's implementation addressed gotoNextFuzzyUntr(), analyzed their approach to generalise it to make it work for gotoPrevFuzzyyUntr() and added a parameter to move in either direction for which a new Enum was used instead of magic numbers(they have a name for it T-T). I could see magic numbers used previously in the code and do get it why it isn't preferred.

Week 4

Continued with the week-3's work

Week 5

Worked on fixing other navigational shortcuts in editortab.cpp which implied generalising the function furthermore to take another parameter for entry state. StackOverflow is a saviour(Of course, after my mentor). Throughtout this time, it felt as if things were unravelling themselves to me. New bugs were found and worked upon. Looking back, I mostly improvised upon Kumud's solution but still got to learn a lot on the way.

Week 6

Will work on other bugs identified on the way or scout for new ones! See if I make past this which was primarily the task for SoK.