Thanks!

I know this is unrelated to that PR, but is it fine if we change the name of the function that runs Arch-Update from "update" to "run", or something?

I know this is a minor detail, but I think I would prefer the name of that function to reflect better what it is actually doing (namely running Arch-Update) rather than "update" (which is one of the functions of Arch-Update). What do you think?

Makes sense, done.

Good point too, should be easier to understand

I'm currently testing this. Will merge right after if everything works as intended :)

Quick testing can be done with LANG=fr arch-update-tray for anyone not using French by default

The right click menu works perfectly and is really great! 😄
However, I can't make the FR translation work for some reason... Running the script and the man pages with LANGUAGE=fr works as intended but it does not for the systray. 🤔

Running LANG=fr arch-update-tray reports Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale., despite the fr_FR.utf-8 locale being enabled in my test env. Am I missing something? Any idea?

Well, I even set my test system in french completely and the menu still is in english. So there definitely something missing, either on my side or in this PR ^^ I'm investigating.

Double check you're installing a newer .mo file. I'll have another look shortly, but it should be automatically accounting for prefix using xdg

Ok found the issue! The python script is looking for the .mo file in the default TEXTDOMAINDIR under /usr/share/locale, while I'm installing Arch-Update via the Makefile with the default /usr/local prefix in my test env.

The main script looks both at /usr and /usr/local for the .mo file/TEXTDOMAINDIR. Can something similar be achieved?

(Sorry for mistakenly closing the PR... I miss clicked once again 😅)

Can something similar be achieved?

It absolutely can, give me a while to look into this

Give this a test

I might add, it specifically checks for a French translation, as that is almost guaranteed in this project,

Give this a test

Woops, neither the /usr nor the /usr/local prefix have translation working now 😅

Also, I see the code looks explicitly for the "fr" translation. Would it be possible to look for "*" somehow instead (like it's done in the main script)? This is in the eventuality that we ever get more translations than the french one.
Ideally we would just act on the prefix/TEXTDOMAINDIR env var at our level and let gettext fallback to the default english translation if there's no translation for $LANG/$LANGUAGE.

I might add, it specifically checks for a French translation, as that is almost guaranteed in this project,

Oh! Yeah okay, smart! I missed the logic here. Ignore my previous comment.

fallback is set, and I'd be very worried about systems with neither XDG_DATA_DIRS and XDG_DATA_HOME.

In my case it covers
/home/trigg/.wayfire/share:/home/trigg/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share

BTW, I'll also update the main bash script to look for XDG_DATA_DIRS/XDG_DATA_HOME for the .mo file (in addition of /usr | /usr/local). I think this is the last thing where the script assumes /usr or /usr/local without looking into XDG dirs as well so the script should be all clean on that front after that \o/

fallback is set, and I'd be very worried about systems with neither XDG_DATA_DIRS and XDG_DATA_HOME.

Well, I have neither defined 👼

Impressive! One moment then

It will now iterate above XDG dirs, but ensure that the two expected directories are on the end of the list.

paths starts empty.

If XDG_DATA_DIRS is set, it's appended

if XDG_DATA_HOME is set, it's appended

regardless of both, /usr and /usr/local are appended.

We then iterate over this list until the first positive match comes up, and use that one.

In your case it'll end on the 2nd element /usr/local, in my case it'll end up on 5th element /usr. Either way we should both be covered by this now

Uh, I didn't catch that path was an array with all the potential paths appended to it. My bad!

It was placed after to allow user to override it intentionally

Still not working on my side for some reason (both with the /usr/local and /usr prefixes) 🤷

I gotta go right now, I'll make some more testing/investigation either this evening or tomorrow :)
Thanks once again for all the work!

I made some more tests and I can't make the translation works with the current code... I tried to play a bit with the script but I can't seem to find the issue.

I can confirm the translation (.mo) file works though, as replacing the whole current "# Find translations" part of the script by the following makes the translation works when using the /usr prefix:

t = gettext.translation('Arch-Update', fallback=True)
_ = t.gettext

My guess is that there's something wrong with the localedir definition, as if the script was not looking into it/using it. But that's just an assumption...

@trigg any idea?

I'll keep investigating on my side as well.

My apologies, something else is taking all my time recently. I'll look into this again ASAP

No problem :) Thanks!

It is concerning to me that my setup works before and after this edit.

This post-fixes 'locale' to the path, as that is what the python docs state is expected

Works as expected on my side now 🎉

@trigg How does that look (syntax wise)? 5f4209b

Woops, gotta get rid of the .split(":") part right?

I've merged the parts into one path and appended that

the extend adds each segment of that path as if it was an entire path alone