CMake and GNU Gettext

I wanted to add translation support to my personal project using CMake and Gettext. CMake itself contains a module to find and work with Gettext translation files. It looked simple, but not everything goes according to plans.

It is always easy to blame someone else. I got confused by different examples. First example showed a file structure as locale/${language}/MyApp.po, which failed me when I was trying to integrate it into my program. This in combination with me playing with it cause the CMake generation fail in error basicaly saying The target with the name "MyApp" already exists.. That is because the basename is the same between multiple languages.

Second example is showing a different file folder structure locale/${language}.po. This one worked like a charm, but it looks ugly, I wanted the first variant and was keeping at it for hours to give up in the end.

A short note on my failure to realize that I should debug the CMake itself instead of blindly searching online for hours without a proper solution since there is not that much information online, which means it either others are much smarter than me or that this is underused module / feature in CMake.

Example Configuration

Example of the CMake configuration I used:

Messages.sh

#!/bin/sh

xgettext --keyword=gttr --from-code=utf-8 -p locale -o MyApp.pot `find . -name '*.cpp' -o -name '*.hpp'`

CmakeLists.txt

find_package(Gettext)

if (Gettext_FOUND)
	add_custom_target(
		ExtractTranslations
		ALL
		WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
		COMMENT "Extract translations from the source code."
		COMMAND Messages.sh
	)

	gettext_create_translations(
		locale/MyApp.pot
		ALL
		locale/sk_SK.po
	)
endif()

Articles from blogs I follow:

What's the best programming language for coding agents?

This somewhat widely cited post (I keep seeing it cited, anyway) suggests that dynamic languages and/or languages that represent things more concisely are more token efficient. It seems to be cited enough that LLM search results agree. For example, when I…

via danluu.com August 9, 2026

Stop telling people to sanitize user input

Whether you're dealing with a web application or some other application, all user input should always be considered "hostile" and "dangerous", but you should not just universally sanitize user input.

via Unix Digest - Articles March 7, 2026

GPG Update 2026

A recent toot of mine got the response “friends don’t let friends use GPG” which, I suppose, is true enough. It certainly isn’t the attestation-friendly thing to use, and the opsec failures that are so easy with GPG-encrypted mail make it a hazard there. …

via [bobulate] February 3, 2026

Generated by openring