Forum › Forums › Official Releases › antiX-19 “Marielle Franco, Hannie Schaft, Manolis Glezos” › Desktop folder submenu in languages other than English
Tagged: desktop translation
- This topic has 20 replies, 6 voices, and was last updated Dec 30-11:42 pm by BobC.
-
AuthorPosts
-
December 27, 2020 at 6:58 pm #48212Member
marcuscf
Hello all, new user here.
I’ve been trying antiX 19.3 on an old computer for the last few days and I noticed that the menu accessible by “Menu -> Desktop -> Desktop Folder” only works when I run/install antiX in English and not when running in Brazilian Portuguese.
I’ve found out that the root cause is the /usr/local/bin/icewm-menu-Desktop.sh script, which has hardcoded TOP_DIR=~/Desktop.
On top of that, the Brazilian Portuguese name for that folder contains spaces (it’s called “Área de trabalho”) and that requires careful quoting in shell scripts.
The end result is that instead of showing desktop items, the menu shows a single line with the names of home folder files (and subfolders) concatenated to each other. Clicking on that menu item does nothing.
An informal patch to fix that would be:
Line 78 near the end of the script:
-TOP_DIR=~/Desktop +TOP_DIR="$XDG_DESKTOP_DIR"
(-1 line removed, +1 line added)
Another issue is that when the desktop folder is empty the script reverts to that buggy behavior of concatenating all file names into a single menu item.
In order to solve that I’ve made another informal patch:
At the beginning of the walk_dir() function, add an if:
walk_dir() { if [[ -z $(ls -A "$1") ]]; then # Empty dir return fi
The use of brackets and quotes is tricky, but it seems that I’ve found a way to support folders with spaces.
The last related issue is that the deskopt doesn’t come with the standard files if the Desktop folder has a translated name. That’s noticeable only if you choose the SpaceFM file manager, because the Deskop becomes empty. When using ROX this problem is not visible (unless you explicitly navigate to the Desktop (Área de trabalho) folder and you know that something was supposed to be there). I haven’t found what script populates the desktop yet.
- This topic was modified 2 months ago by marcuscf.
- This topic was modified 2 months ago by marcuscf. Reason: formatting
December 27, 2020 at 10:01 pm #48220Memberskidoo
what script populates the desktop
ROX, when it launches, consults
~/.config/rox.sourceforge.net/ROX-Filer/pb_*upon launch, rox checks if the launchstring instructs loading a named pinboard:
rox -p pinboardname
or
rox ––pinboard=pinboardnameIf not, rox will populate the
desktoppinboard items as specified in ~/.config/rox.sourceforge.net/ROX-Filer/pb_Default___________________________________________
When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specsDecember 27, 2020 at 11:55 pm #48229Memberskidoo
provided by package “desktop-defaults-rox”, localized pb_* files are installed to directory
/usr/share/antiX/localisation/[NN]/config/rox.sourceforge.net/ROX-Filer/but I haven’t found any installed “script” which automatically detects locale and would copy
into place the locale-specific pb_{fluxbox,icewm,jwm} filesThis could (would?) be handled by the desktop-session startup script?
Sniff locale and… and what?
It would be unsafe to blindly overwrite the content of any existing (and probably user-customized) pb_ files.___________________________________________
When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specsDecember 28, 2020 at 12:20 am #48232ModeratorBobC
Hi Marcuscf,
The bugs are my fault. I submitted the original code, but I wasn’t aware that the folder had multiword names in other languages, but I understand the problem.
Thanks for supplying solutions. I’ll give them a try, and if they work, I’ll submit the fix.
PS: my comments refer to the two code bugs. I’m not familiar with how the files initially get loaded there.
- This reply was modified 2 months ago by BobC.
December 28, 2020 at 3:23 am #48240Forum AdminDave
provided by package “desktop-defaults-rox”, localized pb_* files are installed to directory
/usr/share/antiX/localisation/[NN]/config/rox.sourceforge.net/ROX-Filer/but I haven’t found any installed “script” which automatically detects locale and would copy
into place the locale-specific pb_{fluxbox,icewm,jwm} filesThis could (would?) be handled by the desktop-session startup script?
Sniff locale and… and what?
It would be unsafe to blindly overwrite the content of any existing (and probably user-customized) pb_ files.Hmm good question. I know the applications menu and spacefm desktop files are localized/copied in desktop-session upon first run of a session by the user (absence of ~/.desktop-session/finished-first-run) by running the first run script (/usr/local/lib/desktop-session/first-run-script). So theoretically you could place all functions here. Then when the locale needs to be regenerated remove the ~/.desktop-session/finished-first-run file logout/login (Of course that script can be run outside of desktops-session as well) I would *guess* that currently the locale is set upon init by the “antiX live system” in /etc/skel and /home; then copied over at install. (This is probably why it is advised to choose your locale on live boot).
There used to be a way via the control centre to change to a limited number of locales which would also do this copy and set the keyboard. I think this has since been removed and the keyboard set by fbxkb (which does not set the console IIRC and therefor again advisable to set on live boot) and the rest done during live boot.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
December 28, 2020 at 4:11 am #48241Memberskidoo
/etc/live/README
lang=*
In antiX and MX this option sets more than just the language. It also
sets the keyboard layout, the Debian mirror, the antiX/MX mirror and the
timezone. If you set any of these others explicitly then that setting
will over-ride the value set via “lang”./usr/local/bin/desktop-session:
local new_lang=$(sed -nr 's/^WM_LANG="([^"]+)".*/\1/p' $new_lang_file) [..] rox) echo_bg_cmd rox --pinboard=antiX-$wm ;;
? ? ?
if $new_lang != NULL
mkdir -p ~/.config/rox.sourceforge.net/ROX-Filer/$new_lang
cp /usr/share/antiX/localisation/$new_lang/config/rox.sourceforge.net/ROX-Filer/ \
~/.config/rox.sourceforge.net/ROX-Filer/$new_lang/pb_antiX-icewm/pb_antiX-icewmrox ––pinboard=~/.config/rox.sourceforge.net/ROX-Filer/$new_lang/pb_antiX-icewm/pb_antiX-icewm
fiNot just first-run.
The user may have specified (via bootmenu or bootline) an alternate locale for this boot session.___________________________________________
When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specsDecember 28, 2020 at 4:56 am #48246Forum AdminDave
Yep should have checked… I do not remember that code being there (only the first run script) but it has been for over 3 years… Do you know how the other locale items are set? For example the root menu file / toolbars in /usr/share/antiX/localization/icemw/.
Maybe there is a script/program already built that can be called within the test for locale change.
If such a script does not exist maybe it is worthwhile to consider consolidating the various locale changes into a common script (that can be called as a whole or broken into functions).Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
December 28, 2020 at 5:18 am #48249Memberskidoo
your latest arrived while i was editing my earlier post
Beyond tackling the specific problem mentioned by the OP, I did “look around”
(recursively grepped /etc, /usr/local, /bin, /usr/bin )
lang=
lang_
locale_file
and found nothing other than the live README file quoted above.Because SLiM provides no locale chooser (and, even if it did, or swap in LightDM instead)
and
considering that LANG= is not exported by an antiX user’s ~/.profile and/or ~/.bashrc
…I wonder where could a “chooser” be presented, and wouldn’t the user need to logout for the change to take effect?Yeah, it’s a hairball. The overall (debian-based) system supports NN locales, and LightDM chooser presents ALL the configured locales… or would the antiX maintainers curate the LightDM config, cut it down to only those locales for which locale-specific ROX pinboards are onhand?
___________________________________________
When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specsDecember 28, 2020 at 11:38 am #48259Membermarcelocripe
Olá Marcuscf,
Seja bem-vindo ao antiX e ao fórum do antiX Linux.
Eu agradeço por você iniciar no fórum de forma colaborativa.
marcelocripe
(Texto original em idioma Português do Brasil)———-
Hi Marcuscf,
Welcome to antiX and the antiX Linux forum.
I thank you for collaboratively starting the forum.
marcelocripe
(Original text in Brazilian Portuguese)December 28, 2020 at 4:02 pm #48274ModeratorBobC
Marcuscf,
Does the problem occur only after the system is installed?
I tried changing to Portuguese Brazil on the flashdrive, but the folder is named “/home/demo/Desktop”, so the problem didn’t occur.
I tested it from a terminal by creating a folder manually, setting the variable, and then testing with and without contents, but wasn’t able to test from IceWM because the XDG variable is not set to the Portuguese name.
I think it will work, based on the output to the terminal, but had hoped for a better test.
December 28, 2020 at 6:31 pm #48288ModeratorBobC
On the flashdrive, I booted as Portuguese BR, and then added a new user, and when I did that it named the folder as you described.
Rox’s “Desktop” where the icons are is not in the ~/Desktop folder.
SpaceFM’s “Desktop” is actually in the ~/Desktop folder, but there is something wrong with my menu building script when it runs in Portuguese. SpaceFM’s Desktop actually did display the items I put into the folder, but my menu did not. This does work correctly in English, so I’ll have to do more testing to figure it out.
Question: Should the menu’s “Desktop” folder list always display what is in the ~/Desktop (or its translated value)? That was what I had intended originally, but if not I can look into displaying the Rox location? The problem I see is that if I add something to the desktop folder, I wish it would appear everywhere the same, regardless of which desktop I have selected at the moment. I created the desktop folder option so people that couldn’t afford the memory to run Rox or SpaceFM, but still wanted to run or open files they put in their desktop folder, could still easily run them.
Question for skidoo and Dave: Could we use a link of some kind to merge them?
December 28, 2020 at 6:45 pm #48289MemberXecure
Rox uses a pinboard (so it doesn’t read the files on the Desktop folder). you place things there and its only use is for launching things that are pinned on the desktop (but it is not used to “store” files/folders).
SpaceFM reads the contents of the Desktop folder, so it should mirror what is inside the Desktop folder. If using SpaceFM to manage the desktop, adding/removing things to/from the desktop will also add/remove them from the folder.Pay attention to using spaces, as marcuscf points out. That is why they recommend using quotes for paths.
December 28, 2020 at 9:42 pm #48326ModeratorBobC
I added a link to the desktop folder and a couple of apps to the Rox pinboard. The link to the folder works great and might be a way to have it make sense to people. With SpaceFM you get what you would expect, now.
Attachments:
December 28, 2020 at 10:40 pm #48335Membermarcuscf
Looking good! I like the Desktop folder on the pinboard. If the pinboard must be independent from the Desktop folder, this is the next best thing. And when my desktop is full of windows, the dynamic menu lets me access desktop files easily.
Does the problem occur only after the system is installed?
I guess you already figured it out (by creating another user) but it happened to me in the live (just tested on a VM) and installed systems, I just had to choose the language at boot time or during the installation. The default user (demo) had the “Área de trabalho” folder (and it was empty).
December 28, 2020 at 11:06 pm #48344ModeratorBobC
Marcuscf,
Actually, you can solve that part of this on your machine just by dragging and dropping a copy of your “Área de trabalho” folder onto the Rox desktop pinboard like I did.
We’ll have to see if the Devs will be able to do that as part of setup to make the desktops more consistent or not, but at least you have an easy way to create it yourself in the meantime.
-
AuthorPosts
- You must be logged in to reply to this topic.