Understanding gettext-domain entry in the metadata.json

I have recently made my first translation with one of the extension I authored for gnome-shell v45.

I followed the gnome documentation on translation. Documentation says, have an entry in the metadata.json file with gettext-domain as the key for initializing translations. However without this key the translations are working. How is this possible. I tried it in two different OS without this gettext-domain key and translations are working.

This is triggering me that gettext-domain is only useful for creating pot file from the extension. Once it is done, the extension will use the mo file irrespective of gettext-domain entry. Can anyone help me understand this mechanism please.


If you have gettext-domain in you metadata.json, translations are setup up automatically. Otherwise, you must call Extension.initTranslations() manually and pass your domain.

but without that (Extension.initTranslations()) or text domain in metadata.json. Evertying is working fine with translations.

I am just doing xgettext to get pot file, then convert to po then to mo and all working fine.

GNOME Shell will also try the extension UUID as the gettext domain, if translation methods are called without initializing manually or defining gettext-domain.

1 Like

Then either you are using a translation domain that matches the UUID, or you are changing the default gettext domain. The latter “works” as far as your extension is concerned, but it breaks translations for gnome-shell itself. So don’t do that :slight_smile:

I accidentally removed gettext-domain key from metadata.json file. And everything working good. Then I curiously tried in another OS with gnome 45. This means its easy to have the mo file named as UUIDofExt.mo and forget about gettext-domain entry in metadata.json unless you decide to have a different value for textdomain other than UUID.

Yeah, if you are using the UUID as gettext domain, then you don’t have to do anything.

1 Like