Testing translations without compiling an app

There is a way to test a new translation for an application without having to re-compile an app after adding the new language to its Makefile etc.

For example, the current QuickLaunch release (v1.3.3) doesn’t yet support Turkish, though it’s been translated meanwhile (thanks Emir Sarı!). To test the translation we:

  • Export the tr.catkeys (Turkish) of QuickLauch from Polyglot
  • Open a Terminal at the download location.
  • Convert the catkeys to a catalog file with:
    linkcatkeys -o tr.catalog -s "application/x-vnd.humdinger-quicklaunch" -l tr tr.catkeys
    You find the app signature in the first line of the tr.cakeys.
  • Create a folder for the catalog named with the vendor part of the signature:
    mkdir -p ~/config/non-packaged/data/locale/catalogs/x-vnd.humdinger-quicklaunch
  • Move the catalog there:
    mv tr.catalog ~/config/non-packaged/data/locale/catalogs/x-vnd.humdinger-quicklaunch

Now, if you’ve set “Turkish” in the Locale prefs, QuickLaunch will show the translated GUI strings.
Who is going to create a short bash script for this and post it in the comments? :slight_smile:

Here’s a little bash-script that does what’s described above. Save as catkeystest.sh, make executable with chmod +x catkeystest.sh and put it in ~/config/non-packaged/bin/.


# catkeystest.sh
# A script to test new catkeys of an installed application.
# It converts the 'xx.catkeys' to a 'xx.catalog' file and
# puts it in a 'magic' folder where it is picked up when
# the app is launched.

if [ $# -eq 0 ] ; then
	echo "Usage: catkeystest.sh CATKEYS"

if [ ! -e "${1}" ] ; then
	echo "${1} not found!"

appSig=$(head -1 "${1}" | awk '{ print $3; }' | cut -f2 -d"/")
catLang=$(basename "${1}" .catkeys)
localeFolder=$(finddir B_USER_NONPACKAGED_DATA_DIRECTORY)/locale/catalogs

mkdir -p $localeFolder/$appSig
linkcatkeys -o $localeFolder/$appSig/$catLang.catalog -s "application/$appSig" -l $catLang "${1}"

if [ $? -ne 0 ] ; then
	echo "Operation failed."
	echo "Catalog created: $localeFolder/$appSig/$catLang.catalog"

This is neat! Thank you for the tip!

Hopefully, these several line will also be available in Documentation section of the site.

It is in theory possible to use the catkeys file directly without “linking” it. Did someone try that? Did it work? Should we keep that feature?

I’m wondering, because the Locale Kit ends up looking for catalogs in quite many places (app resources, packaged and non-packaged directories, etc), and removing the plaintext catkeys support from there would speed up applications loading time a little. So, if no one uses catkeys directly, I’ll probably remove the feature.

Already created a PR yesterday. :slight_smile:

I just tried putting the tr.catkeys into

  • ~/config/non-packaged/data/locale/catalogs/x-vnd.humdinger-quicklaunch/tr.catkeys
  • ~/config/non-packaged/data/locale/catkeys/x-vnd.humdinger-quicklaunch/tr.catkeys

Both aren’t picked up. Or did you mean putting them somewhere else?

I checked the code for the add-on: https://git.haiku-os.org/haiku/tree/src/add-ons/locale/catalogs/plaintext/Catalog.cpp

It seems it was never updated to look in the non-packaged directories. It uses etc instead.

So that would be /etc/locale/catalogs/x-vnd.humdinger-quicklaunch/tr.catkeys

It will also look for a “locale/catalogs/x-vnd.humdinger-quicklaunch/tr.catkeys” next to the application binary, which I think was the main way we expected catalogs to be tested at the time (but package kit wasn’t in production back then)

KeymapSwitcher use the catkeys files without “linking” it to reduce memory usage I think.

That does not work, neither with tr.catalog nor tr.catkeys.

That does indeed work, but only for tr.catalog, not catkeys.

I haven’t looked deeper into that, but the HPKG in HaikuDepot does come with catalog files.
Oh, or did you mean KeymapSwitcher just doesn’t have the catalogs linked as resources to the executable?

Yes, exactly.

Right. But that means it’s still using ‘compiled’ catalogs instead of plain-text catkeys. I think that was PulkoMandy’s reasoning when saying:

If that helps significantly, why not. But I could imagine the gains to be marginal, esp. since you’ll still have to look in all these locations for any non-text ‘catalog’ files.

The problem is it doesn’t look for both at the same time. The code is in separate add-ons, so the directories are opened and listed twice. I’ll just remove the plaintext add-on if no one uses it, and let people use linkcatkeys to test their translations, it makes things simpler on our side and seems acceptable on the i18n team side, right?

OK by me. Converting to a catalog is easy enough for the very few people that need it.

I just wanted to say nice script you wrote there, i’ve always been fascinated by the magic of bash scripts when doing complicated stuff like these :nerd_face:

I’m very sorry to necropost this one, but I was trying this method to test a different Italian translation replacing unused galego localization, but placing plain catkeys and compiled catalogs in /etc/locale and ~/non-packaged/data/locale it seems that it doesn’t work, is this method usable only with certain applications (I’ve tried with short translations like zipomatic and WPA supplicant preflet) or meanwhile all this mechanism is went deprecated?

Note: I’ve downloaded the sample it.catkeys from pootle, when I try to compile it I receive a bad data error, it seems that hash is wrong so I had to rehash it, and recompiling it I have no errors, could be this the reason?


Still works as described in the top post, i.e. moving the compiled catalog to ~/config/non-packaged/data/locale/catalogs/{vendor-part-of-app-signature}.

I tried successfully with a small app from Polyglot.

Pootle, however, has some issues when exporting catkeys, it appears. The signature is missing in the first line, the hash is wrong (as you discovered as well) and the translation contexts are missing…

If nobody beats me to it, I’ll file a bug report later today or tomorrow.

I don’t know where is the fault but this isn’t working, at least with zip-o-matic’s catkeys

If I use the it.catkeys as basis from zipomatic « tracker « add-ons « catalogs « data - haiku - Haiku's main repository instead of downloading it from Pootle, it works for me.
The hash is different and, as mentioned, contrary to the Pootle catkeys, it has those translation contexts.

1 Like

I thought it was related to the hash, but didn’t think that a rehash couldn’t solve it, thx, :pray: I’ll try soon

For completeness, this is the ticket for this issue:

1 Like