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

#!/bin/sh

# 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"
	exit
fi

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

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."
else
	echo "Catalog created: $localeFolder/$appSig/$catLang.catalog"
fi
4 Likes

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.