Polish language Manpages not working (paths problem?)

Works here in Cooker and Rock.


`

Might be a good idea if users would actually provide the information in their first post in Support that we ask for. That is disrespectful to those that would help you.

Edit: That said the other threads on this do not make clear if the problem is resolved and if so how was it resolved.

@ben79 I think this is the same issue that @grafi had, where updates do not overwrite the configs that point to the manpages in Polish. I believe @grafi fixed his with a clean install. On this one, I don’t know.

Thanks @WilsonPhillips for your reply.

It is very frustrating to have multiple threads on something and apparently I am not smart enough to tell from all those threads if there is some problem that needs to be fixed? Is there a workaround? Was the issue resolved? I don’t like this and it seems a disservice to our users if we don’t clear this up.

I don’t know and I find it just as frustrating. At the announcement, you posted that the preferred way was a clean install. That an Upgrade to 6.0 may or may not work. I spent days before trying to get people to get their backups done. This appears to me, to be another case of ā€œjust do a clean installā€ and everything should work fine.

This seems like a simple path problem and should be fixable, but I don’t know how to do it. I use US English, and it is the default. I have no experience dealing with language packs and the issues that causes.

So my goal involves our Polish language users I want to find out if this a real problem with something that needs to be fixed or not. It is taking care of our users that is important.

I think for this I am asking if there are new packages that write new configurations and those new packages are not re-writing those configurations do we not need to correct that? To me, if this is the case, and I do not know that part yet, then to me this is an important bug that needs to be fixed.

Edit: In other words if users have to reinstall their systems to correct this that is a workaround and the ā€œrealā€ problem has not been resolved. But I need confirmation of this.

1 Like

Thanks for bringing up the topic and I know there is no workaround and no fix yet (I am currently on Debian 12 until the problem is solved)

  1. My installation was from the official iso 22/30 April rock 6.0
  2. ā€œI want to find out if this is a real problem with something that needs to be fixed or notā€ Rather yes.
  3. You definitely need to install groff so that there is 1 less error and I installed man-pages-pl, which did not help at all.

Then someone that has this issue needs to file a bug report and provide us with enough information so we can fix whatever it is that is wrong. It really does need the input of someone that has this issue.

I believe we should merge this thread with this one. This is to confusing for users.

1 Like

So now let’s get to some details on this:

What does it actually take to get the Polish man pages to work in OMLx, everything step by step?

Or is there no way to get these man pages working? If not does anyone know why not?

Let’s get this fixed! This is just to important.

2 Likes

Well, let’s figure out what we can do with it for now
Packages that need to be installed (after installing the system)
sudo dnf in groff
Installing man-pages-pl and locales-extra-charsets won’t help.
Just as I was looking for a similar thread and found it on the arch forum [SOLVED] Error with man pages for regular users / Newbie Corner / Arch Linux Forums if it can be helpful

As far as I know, it is only happening to Polish, but can’t say that with certainty.

Arch Forum helped with a workaround! :sweat_smile:
What to do?

  • Adding this in .bashrc
export MAN_DISABLE_SECCOMP=1
man man
  • And install it just in case

sudo dnf in groff man-pages-pl

  • What should .bashrc look like
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# User specific environment and startup programs

export MAN_DISABLE_SECCOMP=1
man man

I am making the incredible sacrifice of trying to use a ā€˜Live’ Rock iso in Polish. I am freaking lost language wise…

And on the ā€˜Live’ iso man-pages-pl and locales-pl are installed as expected. Note: Since these are on the ā€˜Live’ iso I expect them to be on any installed Plasma6 OMLx system, probably on Gnome also. I had to install groff and locales-extra-charsets and man dnf shows no dnf man page available which can not be correce.

Aside: If in fact groff and locales-extra-charsets are needed then they should be installed as dependencies of man-pages-pl. If, I can’t be sure until we see what actually works which seems unknown at this point.

So I posted about this in the OM Cooker chat room and the Polish Prince @AngryPenguin confirmed that this is broken. We now need to see if out devs can fix this.

I still wish someone that has this issue would file a bug report. We need someone with the issue to do this.

1 Like

The devs think the problem is that the pl man pages are not UTF-8, there is an upgrade, we will see if that upgrade includes adding UTF-8 so these can work. And we go from there…

So far I have not been able to get this to work in the Rock ā€˜Live’ iso.

Edit: And I don’t seem to be smart enough to get the language to change in a OMLx VM. I used localectl set-locale LANG=pl_PL.UTF-8 and rebooted but in Konsole I am still very English. That is supposed to set the system language so I don’t get this. There is the problem that I don’t or can’t change kbd so:

$ localectl status
System Locale: LANG=pl_PL.UTF-8
    VC Keymap: us
   X11 Layout: us

So this leaves me kind of stuck trying to sort this out.

I speak redneck English. I know what Polska kielbasa is, but that is my limit. We need you guys to help on this.

I got it. First problem is that I had to run sudo localectl set-locale LANG=pl_PL.UTF-8 instead of as user.

$ man man

Works and is in Polish. man dnf works and is in English, don’t understand that. man less and man more appear to be in Polish.

So thanks @FernPolskaOriginal for this workaround and thanks to the Arch Linux folks. FWIW I do use their docs a good bit, more than I use Fedora these days.

I passed this workaround along to developers @AngryPenguin and @bero so we will see where this goes. We should get some fix soonish. They will of course want to do what is the ā€œbestā€ fix from a technical standpoint as always.

1 Like