i18n: Localize Nautilus .py script

[dmatos2012]

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]

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?

[trag1c]

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

[swsnr]

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

[dmatos2012]

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

[swsnr]

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.

[dmatos2012]

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

[dmatos2012]

@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!