Localization support

[pluiedev]

For the 1.0 release, I think we should at least have a foundation for localization support so that Ghostty can appeal to users whose native language is not English. As of now, all user-facing strings, names, labels, etc. are all hardcoded in English in the source code, which greatly limits what we could do for these users.

[jcollie]

Is there a "state-of-the-art" localization for Zig code? This could be an interesting project as a lot of Ghostty's documentation is generated from Zig documentation comments. The documentation comments inside src/config/Config.zig being a major source.

[pluiedev]

After a cursory search, there appears to be literally only four libraries¹ that deal with localization for Zig, and all of them are dormant, incomplete, and more proofs of concept than mature libraries we can use off-the-shelf.

• https://github.com/Vexu/i18n-experiment to me appears to be the most flexible and fleshed out implementation, but it's very clearly experimental and uses a seemingly custom syntax for defining strings;
• https://github.com/Beyley/zig-i18n is an attempt at using gettext-style .po files for translations, which could help simplifying the workflow;
• https://github.com/PhantomUIx/i18n is similar but uses Flutter .arb files instead;
• I have no idea what https://github.com/SeedyROM/locus is doing. There's no examples on how to define strings, and the code looks like an absolute mess. I wouldn't consider using it at all.

And of course, none of them handles translating doc comments for automated documentation purposes.

...Looks like we have to NIH this, then!

Footnotes

1. I tried searching for all repositories on GitHub with the Zig language filter and a couple of different keywords, including "i18n", "l10n", "internationalization", "internationalisation", "localization" and "localisation", and these are the only relevant results. ↩

[mitchellh]

I'm interested in this but probably not for the 1.0 release. I'm only saying this out of time available and effort.

[rcalixte]

I could be wrong but I don't believe we need to reinvent the wheel here. I'd actually implemented something similar to this for my own personal Zig playground just last week. The code below could be modified to fit Ghostty. Once the strings are properly encased in gettext function calls, we could generate a .pot (translation template file) that translators could use to create .po (language translation) files. Non-translated strings in Ghostty wouldn't be affected unless there was a matching translation object with matching strings installed.

const std = @import("std");
const c = @cImport({
    // libraries for translation support
    @cInclude("libintl.h");
    @cInclude("locale.h");
    @cInclude("gettext.h");
});

pub fn main() !void {
    // We use __ instead of _ for Zig because _ is a reserved identifier
    const __ = c.gettext;

    const UUID = "com.mitchellh.ghostty";
    const bind_path = "/usr/share/locale";
    const msgid = "About Ghostty";
    // locale.h
    _ = c.setlocale(c.LC_MESSAGES, "");
    // libintl.h
    _ = c.bindtextdomain(UUID, bind_path);
    // libintl.h
    _ = c.textdomain(UUID);
    // both are valid if we don't want to use a custom keyword
    const gettext = c.gettext(msgid);
    const same_gettext = __(msgid);

    const stdout_file = std.io.getStdOut().writer();
    var bw = std.io.bufferedWriter(stdout_file);
    const stdout = bw.writer();

    try stdout.print("gettext: {s}\n", .{gettext});
    try stdout.print("same_gettext: {s}\n", .{same_gettext});
    try bw.flush(); // don't forget to flush!
}

The xgettext string extraction will be a little bit messy since there is not support for Zig (yet) but we can work around that pretty easily for now. The .pot file and the .po files could live in a top-level po/ directory. We can modify the build.zig so that the .po files are compiled into .mo files and placed into zig-out/share/locale.

One caveat is that I know that this will work for the Linux ecosystem. I'm actually not sure if having the translations and possibly compiled objects will suffice elsewhere. And then there's the overall question of whether C imports would be preferred for this as an alternative to something more native in Zig. The GNU gettext package and its dependencies are well-established though. (The libintl.h and locale.h headers shipped with Zig 0.13.0 under libc(/musl) as well.)

If desired, I could probably have something working within a few days along these lines.

[00-kat]

For the record, cross-referencing to @pluiedev's draft PR #5214 here.

[Aaron-212]

I'm curious about the macOS half of this feature, since GTK half is merged in #6004.
What's the technology will be used to localize the macOS app? Using libraries like https://github.com/microsoft/LocalizedStringKit or https://github.com/hulab/POLocalizedString? Or using Xcode to extract localizable strings into .strings or .xcstrings files?

[pluiedev]

See #6619