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?
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
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.
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)
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?
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?
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’ll try soon