Notifications only in English?

[xesarni]

Notifications only in English?

[bkw777]

I think just switching that setlocale() to ALL fixed it.
I just installed the pl language pack and ran:
$ LANGUAGE=pl_PL.UTF-8 setsid -f bash ~/.config/mainline/mainline-notify.sh --autostart

Update coming shortly!

[bkw777]

Which language? cat /etc/default/locale

The strings in AppConsole.vala notify_user() are translatable, but maybe those particular strings are not translated for whatever language you tried, or maybe there isn't even any XX.po for that language at all.
As far as I can tell, nothing should be messing up the LANG* or LC_* variables.
I have also verified that set_locale() happens before notify_user() during mainline --notify

It's several annoying steps to rig things up to debug notifications so I'll come back later with a set of steps to follow to kick off notifications on demand and generate log files from both mainline and notice.sh to see why it's choosing English.

[bkw777]

to debug, in this order:

First, update to 1.4.1.
I fixed up some holes in the process management in mainline-notify.sh, and it's simpler to debug this after that fixup.

Use the app to uninstall or un-hide as necessary, and reboot if necessary, to make it so that there is at least one available valid un-hidden kernel that is not installed, and you are running something older than the latest. Don't expect to see any notifications yet while doing this. You might, you might not, but we don't care yet.

If you didn't have to reboot above just to downgrade, then reboot now regardless. It's just to ensure that there are no old notify.sh or sleep or notice.sh processes from before the 1.4.1 fixup.

in a terminal run:
$ DEBUG=true setsid -f bash ~/.config/mainline/mainline-notify.sh --autostart
This emulates a new login, and tells -notify.sh to kill any other instances of itself, clear out all the state files, and send one fresh notification just like after a reboot. This is a repeatable command. You can up-arrow and re-run the same thing and it will send another notification.
DEBUG=true doesn't affect notify.sh or mainline, but it is picked up by notice.sh and causes it to create those *.e files.

A notification should appear. You can leave it up or dismiss it.

Go look in /var/run/user/1000/ for files named _usr_lib_mainline_notice.sh.#####.e

There will likely be two *.e files and one *.p file. You are interested in the lower PID#.e file, aka the larger size one.
Don't paste the full contents here, it contains a copy of your full environment which might include things you don't want public.
But it shows the commands that were run and all env variables, and something in there should show why it's outputting in English. ex: LANG=... LANGUAGE=..., LC_ALL=..., LC_*=...

You can then delete all 3 files and re-run the exact same command above and it will do another notification each time as though you never saw that yet or as though you were logging in after a reboot.

You can paste the whole log here if you look it over and decide there is nothing like a password or anything in there.

[xesarni]

OK, I will wait for 1.4.1 in the PPA. In the meantime, visual confirmation of the issue:

[xesarni]

Here's the log file: _usr_lib_mainline_notice.sh.1638.e.zip

[bkw777]

Thank you.

This shows that definitely there is nothing like a LANG=C in effect at the time either mainline --notify or notice.sh is run.
And also shows that notice.sh was handed that English string by the parent executable (ie it wasn't somehow being changed within notice.sh or gdbus or something)

The gui app is mainline-gtk and is built from AppGtk.vala which immediately includes Main.vala which immediately does set_locale() from l.misc.vala.
But notifications come from mainline --notify which is a different binary mainline, which is built from AppConsole.vala, but which also immediately includes the same Main.vala and does the same set_locale() very early in app startup.

So in both cases, the gui and the cli apps, all the language environment settings are the same and Intl.setlocale() is called the same before anything else, including when mainline --notify is building the strings to form the command line for Process.spawn_command_line_sync()

But I think I see a couple things to investigate.

Could you please run just mainline in a terminal? No args, and just mainline not mainline-gtk.
It will print the help message, and most of that text is all localized, so it should all be in Polish.
This would show that set_locale() is in effect and working for the cli mainline app the same as mainline --notify, not just the gui app.

What I noticed and what I suspect is this:
Most translated strings eventually go through some flavor of printf() on their way to the console stdout, or whatever GLib or Gtk does internally with strings that end up getting displayed in buttons etc. But the string that becomes part of the exec() command is just a concattenated built string. it's never printf()'ed nor used in any gui widget.

Another thing, or I guess probably this is the same thing, is the gettext manual says for vala:
"Programmer must call Intl.setlocale (LocaleCategory.ALL, "")"
While l.misc.vala set_locale() has:
Intl.setlocale(LocaleCategory.MESSAGES,BRANDING_SHORTNAME);

That MESSAGES vs ALL is sure suspicious considering this observed behavor. Especially if you can tell me that the help output comes out localized. Maybe it means that gettext is only translating strings that it thinks are messages? IE, only things that end up getting fed into printf() or any other functions it thinks are "message handlers" which could include all the gui widget display things, all probably handled by the Intl binding library for vala probably.

So maybe there are two possible fixes to try, either pass that string through sprintf() or similar just so that it goes through a printf() of any flavor and "looks like a message", or maybe that ALL parameter would cause it to start being translated just where it is without changing anything else because it would no longer limit itself to "things that look like a message"?

I'm poking at it now.

[bkw777]

Wait, it literally is exactly printf(): title = _("Kernel %s Available").printf(available);
But still, I think somehow this is the basic nature of the problem. Maybe that use of printf() somehow "doesn't count" since it's not going to stdout or something like what vprint() does.