i18n: Localize Nautilus .py script by dmatos2012 · Pull Request #9976 · ghostty-org/ghostty

dmatos2012 · 2025-12-19T21:25:56Z

Closes #9266.

Big Note: I noticed that this worked properly under NixOS, but on my Ubuntu VM it didnt.

The reason is in src/build/GhosttyI18n.zig because the locale is expected in the <lang>_<region> without the encoding suffix. <lang>_<region>_<encoding>

        // There is no encoding suffix in the LC_MESSAGES path on FreeBSD,
        // so we need to remove it from `locale` to have a correct destination string.
        // (/usr/local/share/locale/en_AU/LC_MESSAGES)
        const target_locale = comptime if (builtin.target.os.tag == .freebsd)
            std.mem.trimRight(u8, locale, ".UTF-8")
        else
            locale;

If i force it to always trim the encoding it works, but I am guessing its there for a reason ,so maybe some of the maintainer can shed some light in the best way forward, as I am not an expert in how other systems deal with it. Here you see Open in Ghostty -> Abrir con Ghostty

I wanted to format the py file with ruff but didnt want to drown the changes, so maybe something that could be worth doing so that also our py files have std formatting.

Note

Used AI only for helping me debug where the locales could be and why was it not detected, but no code help whatsoever

swsnr

I'm not a member of the ghostty project, so please excuse me for leaving a review, but as the original author of this script (albeit for Wezterm originally), and being somewhat familiar with xgettext and Python, I'd like to leave two remarks concerning this pull request 🙂

swsnr · 2025-12-29T20:38:57Z

dist/linux/ghostty_nautilus.py

+import gettext

+DOMAIN = "com.mitchellh.ghostty"
+share_dir = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))


I think this would be more readable with pathlib:

from pathlib import Path locale_dir = Path(__file__).absolute().parent.parent.parent / "locale"

And does the Ghostty build system even guarantee that the locales always end up at this path, relative to the nautilus extension directory?

I'll note that you can use .parents[2] instead of .parent.parent.parent =)

@trag1c Oh, thanks 🙏 I learn a new thing every day 🙂

@swsnr As far as I can see, the nautilus extension is here
GhosttyResources

try steps.append(b.allocator, &b.addInstallFile( b.path("dist/linux/ghostty_nautilus.py"), "share/nautilus-python/extensions/ghostty.py", ).step);

and the locale is relative to share so share/locale/....

README

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` ....

The only issue is what I mentioned in the original comment where some other platforms put the locale with a different suffix and then it doesnt work, so it just fallbacks.

I guess it'll work then. However, I think a comment which explains this rationale would help for future understanding 🙂

swsnr · 2025-12-29T20:40:46Z

src/build/GhosttyI18n.zig

        "-",
    });
+    // Silences the "unknown extension" errors
+    _ = xgettext.captureStdErr();


I don't think that that's a good idea.

I believe the proper way to handle different types of sources with different flags in xgettext is to use separate xgettext invocations to extract messages into intermediate pot files, and then use a final xgettext invocation to merge the intermediate pot files into the final one.

Yeah thanks, I have edited it now. Much cleaner this way.

You're welcome. Can't review the zig code tho, as I'm entirely unfamiliar with the language 🙂

dmatos2012 · 2026-01-22T11:16:21Z

@swsnr Even though it seems you are not an official maintainer, I saw emoji reactions by at least a maintainer, so I assume these changes were approved as well from them. I made those changes, lmk and thanks for the review!

swsnr · 2026-01-24T08:41:09Z

src/build/GhosttyI18n.zig


+    // Collect to intermediate .pot file
+    xgettext.addArg("-o");
+    const gtk_pot = xgettext.addOutputFileArg("gtk.pot");


I'm entirely unfamiliar with zig and its build system, so pardon me if this is a stupid question, but shouldn't you cleanup these temporary POT files after the xgettext_merge down below has finished?

No, since it would only be output to Zig's output cache (./.zig-cache) and not the final prefix

Thanks 🙏

swsnr

Looks sound now, but being unfamiliar with zig I can't really comment on the zig code changes. The general idea of the zig changes looks good to me, but I can't really review the details 😇

pluiedev

Code looks good sans all the merge conflicts. My apologies for letting this sit for too long — looks like the translators would need to do extra work since most of the new strings are already localized as part of #10632.

pluiedev · 2026-02-14T16:30:34Z

src/build/GhosttyI18n.zig


+    // Collect to intermediate .pot file
+    xgettext.addArg("-o");
+    const gtk_pot = xgettext.addOutputFileArg("gtk.pot");


No, since it would only be output to Zig's output cache (./.zig-cache) and not the final prefix

00-kat · 2026-02-14T16:50:39Z

Should these wait until after #10632 is done, or should we try to sneak these into 1.3?

pluiedev · 2026-02-14T17:13:02Z

If it's not too much work for the translators then I think we should try to squeeze these in 1.3. It's partially my fault this PR has stalled for this long

00-kat · 2026-02-15T02:03:20Z

It's a single short string, so I don't expect it to be too hard on the translators; I'm more concerned about the administration nightmare, since:

This PR needs to be merged, and it conflicts with every file in po/, but even after those are fixed every translations update merged would conflict again. So translations merging would have to be put on hold after this is rebased.
After merged, sixteen translation teams need to be pinged again since they already updated their translations. Not sure if we reuse Ghostty 1.3 Translation Tracking Issue #10632 or make a new one, but this probably isn't too hard.
Two translation teams haven't created a PR yet, so they may or may not decide to include this translation alongside their 1.3 PR. Assuming they base their branch off tip at the time of creation, they are likely to.
Three translation teams have an open PRs and are halfway through a review; if they rebase now, the situation will be confusing for everyone involved.
Four translation teams have an open PR, but don't have a review yet; I don't expect all of them to rebase, so we'd need to ask them to rebase, hopefully before they get a review.

It's not like it's too difficult though, it's just really easy to get confused with the translations that haven't been updated yet. On the contrary, nothing says we have to get every translation for this in before 1.3, so we could just prioritize the sixteen already updated translations.

dmatos2012 · 2026-02-15T10:05:41Z

@00-kat @pluiedev Merged, and I updated it with latest main translation files, and then included the new string. Thx

00-kat · 2026-02-17T16:17:09Z

#9904 was merged recently which adds two strings, which means we have to deal with the problem anyway. At the moment there's been three PRs which add those two strings (#10788 #10792 #10794). It's probably best to merge this as soon as possible, so that we don't have to deal with the same problem twice and with an extra division.

(This needs another merge/rebase since it conflicts with every translation file again apparently…)

dmatos2012 · 2026-02-17T22:17:54Z

@00-kat done! Hope no more new strings are added 😛

jcollie

Small nit, otherwise LGTM.

src/build/GhosttyI18n.zig

jcollie

LGTM

i18n: Localize Nautilus .py script

35779be

dmatos2012 requested a review from a team as a code owner December 19, 2025 21:25

swsnr reviewed Dec 29, 2025

View reviewed changes

dmatos2012 added 3 commits January 21, 2026 14:28

Merge branch 'main' into localize-nautilus-script

4f0f464

Merge pot files

c755720

remove comment

d03b074

dmatos2012 requested a review from swsnr January 22, 2026 11:26

swsnr reviewed Jan 24, 2026

View reviewed changes

swsnr approved these changes Jan 24, 2026

View reviewed changes

pluiedev approved these changes Feb 14, 2026

View reviewed changes

00-kat added the translations Translations of the Ghostty app label Feb 14, 2026

00-kat approved these changes Feb 14, 2026

View reviewed changes

dmatos2012 added 3 commits February 15, 2026 11:00

Update po/* from main

db02dbc

Merge branch 'main' into localize-nautilus-script

4525dd5

Update po for new localized string

be5a1c4

dmatos2012 added 3 commits February 17, 2026 23:16

Update po/* again from main

9a3df7e

Merge branch 'main' into localize-nautilus-script

aff4348

Update po for new localized string

2860dd2

jcollie approved these changes Feb 17, 2026

View reviewed changes

src/build/GhosttyI18n.zig Show resolved Hide resolved

dmatos2012 added 3 commits February 17, 2026 23:46

Add back comment

1ec54be

Remove extra space

3779e46

Fix typo

6d71f40

jcollie approved these changes Feb 18, 2026

View reviewed changes

jcollie merged commit a3aa9fa into ghostty-org:main Feb 18, 2026
54 checks passed

github-actions bot added this to the 1.3.0 milestone Feb 18, 2026

00-kat mentioned this pull request Feb 18, 2026

Ghostty 1.3 Translation Tracking Issue #10632

Open

25 tasks

Comments

Conversation

dmatos2012 commented Dec 19, 2025

Uh oh!

swsnr left a comment

Choose a reason for hiding this comment

Uh oh!

swsnr Dec 29, 2025 • edited by trag1c Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmatos2012 commented Jan 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swsnr left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pluiedev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

00-kat commented Feb 14, 2026

Uh oh!

pluiedev commented Feb 14, 2026

Uh oh!

00-kat commented Feb 15, 2026

Uh oh!

dmatos2012 commented Feb 15, 2026

Uh oh!

00-kat commented Feb 17, 2026

Uh oh!

dmatos2012 commented Feb 17, 2026

Uh oh!

jcollie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jcollie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

swsnr Dec 29, 2025 •

edited by trag1c

Loading

swsnr left a comment •

edited

Loading