My KDE translation workflow

KDE translations are entirely kept within one SVN repository. This repository was once home to all KDE code as well, but nowadays the code has long been migrated to Git repositories, and eventually onto KDE's own GitLab instance called KDE Invent. But translations are still kept in this central repository.

The Subversion repository can be browsed directly in the browser from https://websvn.kde.org, which is kind of like browsing a Git repository with cgit. The read-only repository path that can be accessed without commit rights is svn://anonsvn.kde.org/home/kde/<path>, while the read-write repository path which needs commit rights to access (including reads) is svn+ssh://svn@svn.kde.org/home/kde/<path>. These links are both provided for convenience on Websvn.

Also some possibly surprising stuff about Subversion for the modern Git user:

• How Subversion was typically used was AFAIK kind of like a mix between a monorepo and a self-hosted Git forge: all your projects live in this one place, but you have the option of checking out just one project.
• Subversion branches are just copies of folders. Like, you literally branch with svn copy. The structure of trunk, branches, and tags was apparently managed by convention.

Here's an example path for a translation file:

/trunk/l10n-kf6/zh_TW/messages/ark/ark.po

There are a few types of branches in KDE translations to keep in mind:

• Software type: kf5 for KDE 5 era software (as well as websites and documentations), kf6 for KDE 6 / Qt 6 stuff. When a program is ported from Qt 5 to Qt 6, at some point they get moved to kf6.

  • kf5 lives in trunk/l10n-kf5/<language>, kf6 lives in trunk/l10n-kf6/<language>

• Release version:

  • trunk is for in-development program versions. It tracks the main branches from each program's code repository. New translations here get released when the program gets a major release.
  • stable is AFAIK the latest major version of each program. New translations here get released when the program gets a minor (bugfix) release.
  • trunk lives in /trunk, stable lives in /branches/stable. There are other folders within /branches but I regard them as historical artifacts and we most likely shouldn't be touching those.
• Of course each language can be thought of as a branch.
• There is a difference between messages and docmessages. The former is strings in each program, the latter is the manual for the program (usually written in DocBook) if it has one.

Normally translation is done in trunk. When a major version is released, trunk at that moment gets copied to stable (and the previous stable gets replaced). You can manually copy new translations into stable if you want to see them released earlier, in the next minor / bugfix version.

Again, SVN "branches" are basically just folders, especially if you don't need to worry about merging branches as is the case in our usecase.

One commit can modify multiple branches, just like how in a Git monorepo one benefit is that you can modify multiple projects in one commit. I do this to translate trunk and stable in the same commit (because Lokalize, once set up, is able to automatically synchronize the other branch as you translate), although I still don't know how other people think about this.

KDE translation files are in the Gettext PO format. I use KDE's own Lokalize to translate, because it provides project-wide analysis, search, and translation memory all locally. Some people use / recommend POEdit, but since it edits individual PO files instead of supporting entire folders / projects, I have never been able to get used to it.

KDE's servers will periodically pull strings from each program's Git repository into PO files ("extract") and "merge" them into existing PO files (thus preserving previous translations) on SVN. This process is done by a program called Scripty. Scripty also automatically synchronizes all translations back into each program's Git repositories. All of this is automated, one just has to keep it in mind, I don't really worry about it too much.

The time the synchronization happens seems to be around UTC 00:00 each day, so uhh, remember to pull (svn update) and merge your translations before you push (svn commit) if you have unpushed changes across that moment.

For a while I used git-svn to pull translations.

The reason why I insist on having a Git repository locally is that I can use Magit to review my translations, compared to the latest pull, and even delete extraneous changes caused by Lokalize's format slightly differing from Scripty's format. Scripty will fix the format automatically, but I might as well save that extra commit on the server.

The problem specifically with git-svn is that it seems to want to clone all folders under the path being cloned, so if I want a checkout that includes both trunk and stable it will take very long and require a very large amount of bandwidth.

To use git-svn, do something like:

git svn clone -r HEAD svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5/zh_TW/messages path-to-your-local-folder

• The syntax is git svn clone <source> <target>, just like git clone
• This is Traditional Chinese (zh_TW), kf5, trunk. Checking out both kf5 and kf6 in the same clone requires checking out trunk in its entirety, which has the same issue as cloning the root (it seems to want clone every language and everything else under trunk), so you just have to have multiple checkouts if you want to work on them all.
• -r HEAD tells git svn to not include the whole history, as we just want a local checkout, and we're not doing a Git migration.
• Modifying the remote URL (for instance, to move a checkout from the read-only URL to the read-write URL) takes more effort than a simple git remote command since git-svn does some special stuff. It can be done: Open .git/config, then find the svn-remote section, set the url to the new URL, and set rewriteRoot to the old URL. (The actual section name will include the name of the svn-remote, so editing the config file is just faster.)

Once a translation is done… find some way to pack the newly changed files and send them off to someone in your language team who has commit access. Each team is different, you'll probably have to ask around about this.

I have considered committing the Lokalize glossary I use into Subversion, which seems to be a thing some translation teams do.

There are 23 (as of 2024-01, when I wrote the Mandarin version of this article) .tbx glossary files in the entire KDE Subversion repository.

(This search is a lot harder than on eg. GitHub, but can still kind of be done like this:

svn list -R $(svn info --show-item=url) > /tmp/files

then doing a local search in the /tmp/files that that command writes into.)

Since there's more complicated considerations regarding managing a glossary (I feel), I haven't actually uploaded the glossary I'm using into Subversion. But at least I have saved it to my own cloud to synchronize it between the devices I use to do translations.