Ports Ghostty's build-data helpers (main_build_data.zig, src/extra/*, build/mdgen) as the ghostty-build-data binary: bash/zsh/fish completions, Vim syntax/ftdetect/ftplugin/compiler, Sublime syntax (also used by bat), terminfo source and ghostty(1)/ghostty(5) markdown. With the version set to the installed 1.3.1-arch2, all generated files are byte-identical to the installed Ghostty's. - `just docs` renders man pages and HTML with pandoc. - po/: Ghostty's 29 translation catalogs; `just locales` compiles them into the com.mitchellh.ghostty gettext domain. - `just install PREFIX FLATPAK SYSTEM_PACKAGE` installs everything incl. terminfo text/termcap outputs and mirrors GhosttyResources.zig install modes (Flatpak D-Bus template without systemd; lib/systemd/user for system packages). - Build metadata (version, tip/stable channel, commit, build mode) is derived at build time like build_config.zig; GTK/libadwaita compile-time versions come from pkg-config instead of constants. Test Plan: - cargo run -p ghostty-build-data -- +bash | diff - \ /usr/share/bash-completion/completions/ghostty (same for zsh/fish/vim) - just install /tmp/prefix
3.0 KiB
Localizing Ghostty: The Contributors' Guide
Ghostty uses the gettext library/framework for localization, which has the
distinct benefit of being able to be consumed directly by our two main
app runtimes: macOS and GTK (Linux). The core would ideally remain agnostic
to localization efforts, as not all consumers of libghostty would be interested
in localization support. Thus, implementors of app runtimes are left responsible
for any localization that they may add.
GTK
In the GTK app runtime, translatable strings are mainly sourced from Blueprint
files (located under src/apprt/gtk/ui). Blueprints have a native syntax for
translatable strings, which look like this:
// Translators: This is the name of the button that opens the about dialog.
title: _("About Ghostty");
The // Translators: comment provides additional context to the translator
if the string itself is unclear as to what its purpose is or where it's located.
By default identical strings are collapsed together into one translatable entry. To avoid this, assign a context to the string:
label: C_("menu action", "Copy");
Translatable strings can also be sourced from Zig source files. This is useful
when the string must be chosen dynamically at runtime, or when it requires
additional formatting. The i18n. prefix is necessary as _ is not allowed
as a bare identifier in Zig.
const i18n = @import("i18n.zig");
const text = if (awesome)
i18n._("My awesome label :D")
else
i18n._("My not-so-awesome label :(");
const label = gtk.Label.new(text);
All translatable strings are extracted into the translation template file,
located under po/com.mitchellh.ghostty.pot. This file must stay in sync with
the list of translatable strings present in source code or Blueprints at all times.
A CI action would be run for every PR, which checks if the translation template
requires any updates. You can update the translation template by running
zig build update-translations, which would also synchronize translation files
for other locales (.po files) to reflect the state of the template file.
During the build process, each locale in .po files is compiled
into binary .mo files, stored under share/locale/<LOCALE>/LC_MESSAGES/com.mitchellh.ghostty.mo.
This can be directly accessed by libintl, which provide the various gettext
C functions that can be called either by Zig code directly, or by the GTK builder
(recommended).
Note
For the vast majority of users, no additional library needs to be installed in order to get localizations, since
libintlis a part of the GNU C standard library. For users using alternative C standard libraries like musl, they must use a stub implementation such asgettext-tinythat offer no-op symbols for the translation functions, or by using a build oflibintlthat works for them.
macOS
Note
The localization system is not yet implemented for macOS.