Opened 9 years ago
Closed 9 years ago
#50724 closed defect (fixed)
audacity: mixed localization issues
Reported by: | dbevans (David B. Evans) | Owned by: | RJVB (René Bertin) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | haspatch | Cc: | |
Port: | audacity |
Description
When running audacity on my machine (configured for US English, LANG=en_US.UTF-8), most menus, dialogs, etc display in English as expected. However, a few menu items, dialogs, display, at least partially, in French. Examples are the File->Open, File->Export dialogs and the top item in the Help menu. Screenshots attached.
Attachments (4)
Change History (17)
Changed 9 years ago by dbevans (David B. Evans)
Attachment: | audacity-file-open-dialog.png added |
---|
comment:1 Changed 9 years ago by RJVB (René Bertin)
Hmmm, can you check
- if this is still the case if you pick, say, en_GB or even another language (that you're familiar enough with to know who to get back out ;))? In particular, does this always concern the same elements and the same unexpected language?
- do you get the same with the official build?
- do you have an en.lproj directory in audacity.app/Contents/Resources?
- does anything change if you move audacity.app/Contents/Resources/en_GB.lproj out of the way, as well as ${prefix}/share/locale/en_GB/LC_MESSAGES/audacity.mo ?
I've been giving so much attention to providing an en_GB translation that I didn't even notice that there isn't an explicit US English translation. Probably because it's the default; I guess you're using the "System" translation setting?
Changed 9 years ago by dbevans (David B. Evans)
Attachment: | audacity-file-open-dialog-ru.png added |
---|
File->Open dialog (Russian)
comment:2 Changed 9 years ago by dbevans (David B. Evans)
I did the additional testing as you suggested.
- Switched to Russian and everything worked as expected -- no French (screenshot attached)
- Switched back to US English. Still unexpected language but now it's Russian!! (I had switched to French and back a few weeks ago to debug a different problem)
- Ran the "official" Audacity app (2.1.1) -- works fine, no unexpected languages
- Compared Contents/Resources of your app vs official -- eureka!
The official app has an empty en.lproj directory in Resources. Yours does not. Manually adding the empty en.lproj directory permissions 0755 fixes the issue.
comment:3 Changed 9 years ago by RJVB (René Bertin)
Hah, now that's funny. I don't generate those .lproj directories myself, so it beats me why I'm not getting the en.lproj one. I'll fix this in my Portfile (after syncing with the one that got committed, haven't gotten around to that yet ...)
comment:4 Changed 9 years ago by dbevans (David B. Evans)
Probably due to MacPorts not the app. MacPorts automatically removes empty directories in destroot unless you declare them in a destroot.keepdirs
directive.
comment:7 Changed 9 years ago by RJVB (René Bertin)
Yeah, I sent one to Mojca and incorporated it in my own git repo. I haven't heard back from her so presume she's been busy.
comment:8 Changed 9 years ago by dbevans (David B. Evans)
Well, if you have a tentative patch, go ahead a post it here and I'll give it a try.
comment:9 Changed 9 years ago by RJVB (René Bertin)
It's possible she hasn't acted on what I sent her because I also implemented a -devel subport (on request ;))
Anyway, this should do the trick:
--- /opt/local/site-ports/audio/audacity/Portfile 2016-03-08 16:44:01.000000000 +0100 +++ /opt/local/site-ports/audio/audacity/Portfile/opt/local/var/macports/sources/svn.macports.org/trunk/dports/audio/audacity/Portfile 2016-03-08 16:46:59.000000000 +0100 @@ -155,9 +196,11 @@ CPPFLAGS=-I${prefix}/include \ WX_CONFIG=${wxWidgets.wxconfig} +set aud_app_path ${applications_dir}/Audacity.app +destroot.keepdirs ${destroot}${aud_app_path}/Contents/Resources/en.lproj + post-destroot { # create the app bundle infrastructure - set aud_app_path ${applications_dir}/Audacity.app xinstall -m 755 -d ${destroot}${aud_app_path}/Contents/MacOS xinstall -m 755 -d ${destroot}${aud_app_path}/Contents/Resources # the BundleExec:
comment:10 Changed 9 years ago by dbevans (David B. Evans)
Keywords: | haspatch added |
---|
Your patch addresses the issue of retaining the missing directory once it's created but ${destroot}${aud_app_path}/Contents/Resources/en.lproj is never created by your post-destroot script because there is no corresponding ${destroot}${prefix}/share/locale/en. This latter directory doesn't exist because there is no en translation -- it's the default.
Attached is a patch that adds the extra line necessary to install ${destroot}${aud_app_path}/Contents/Resources/en.lproj as well as increment the revision of the port to force the necessary rebuild.
I've tested this switching to French and Russian and back to English as before with good results. English is English, French is French, etc.
If this works for you, I'll commit it and close the ticket.
Changed 9 years ago by dbevans (David B. Evans)
Attachment: | patch-audacity-en.diff added |
---|
Revised patch
comment:11 Changed 9 years ago by RJVB (René Bertin)
That's interesting, because for some reason I have an en.lproj directory in my audacity app bundle. I just rebuilt from scratch, and I got the directory. Empty, so it's not created by my post-destroot. Are you certain destroot.keepdirs
doesn't have (aka never had) the side-effect of creating the indicated directories?!
From my logfile:
:info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/Resources/zh_CN.lproj :info:destroot :info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/Resources/zh_TW.lproj :info:destroot :debug:destroot system: echo "#!/bin/sh :debug:destroot exec \"/Applications/MacPorts/Audacity.app/Contents/MacOS/Audacity\" \"\$@\"" > /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/opt/local/bin/audacity :debug:destroot system: chmod 755 /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/opt/local/bin/audacity :debug:destroot Executing portdestroot::destroot_finish :debug:destroot Fixing glibtool .la files in destroot for audacity :info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/Resources/en.lproj :info:destroot :info:destroot xinstall: /dev/null -> /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/Resources/en.lproj/.turd_audacity :info:destroot :info:destroot ---> Compressing man pages for audacity :debug:destroot Scanning man1 :debug:destroot system: cd /opt/local/var/macports/build/_opt_local_site-ports_audio_audacity/audacity/work/destroot/opt/local/share/man && /usr/bin/gzip -9vf man1/audacity.1 :info:destroot man1/audacity.1: 54.5% -- replaced with man1/audacity.1.gz :info:destroot man1/audacity.1.gz: changing permissions from 00644 to 00444 :debug:destroot checking for mtree violations :debug:destroot port installs files in /Applications/MacPorts
Just for the sake of future compatibility I'd create the en.lproj directory last, checking if it doesn't already exist (which could be due to audacity itself but also due to wxWidgets).
comment:12 Changed 9 years ago by dbevans (David B. Evans)
Yes, it looks like you're right. Declaring a path in destroot.keepsdir should create the corresponding directory and place the ".turd" file in it if they don't already exist. It's the presence of this ".turd" file in the folder that keeps it from getting deleted.
Here's the relevant code from portdestroot::destroot_finish which is executed after any post-destroot sections:
# Prune empty directories in ${destroot} foreach path ${destroot.keepdirs} { if {![file isdirectory ${path}]} { xinstall -m 0755 -d ${path} } if {![file exists ${path}/.turd_${subport}]} { xinstall -c -m 0644 /dev/null ${path}/.turd_${subport} } } fs-traverse -depth dir ${destroot} { if {[file type $dir] eq "directory"} { catch {file delete $dir} } }
I'll double check my results when I get a chance (long build currently running) and, if all works out as expected, commit your original suggestion.
comment:13 Changed 9 years ago by dbevans (David B. Evans)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Maintainer's fix committed in r146484.
File->Open or File->Export dialog