Home Forums Mac Software Mac Operating Systems Get Info / Languages

I just upgraded to Snow Leopard. Prior to Snow Leopard I could use the 'Get Info' window to removed unwanted languages from applications.

Apple seems to have removed Languages from the Get Info window.

Any way to view what Languages are in an Applications now?

I don't think that so much as removes them as it disables them?

Use either Spotlight (but I don't know how reliable it is) or EasyFind, and enter "lproj" (No quotes.) into its search field. (Note that although VersionTracker's EasyFind page specifies OS X 10.5 despite the fact that one new feature specifies "Mac OS X 10.5 'Leopard' or later," Devon's website specifies "Mac OS X 10.4 or later.") (Emphasis added)

I recently ran Macaroni>Remove Localized Files on a fresh Snow Leopard installation during which I "customized" out all languages, and it found absolutely nothing to remove.

By the way... How did you remove languages "using the 'Get Info' window?"

That's only if we merely uncheck the boxes.

What Apple had added in Leopard (which Tiger didn't have) was an ability that allowed us to *select* the languages in the app's Get Info window... and then command*delete* would remove them from the app! [into the trash, iirc.] EDIT: wait a minute... i just looked at a Tiger, and the feature is there too [guess i just forgot]. Tiger has a button named "Remove..." while Leopard uses the [+|-] list item widgets. Interestingly, the "+" function in Leo also exists in Tiger (in the form of an "Add..." button). I wonder if anyone has actually added back localizations that way... and how it would work. [I guess we'd just need the original app on the dmg, or maybe it will even extract from an installer package?]

--

So that's gone in Snowy then?   Odd.

I thought i had read that 10.6. was supposed to finally usher in a way for us to take control of our own localizations. Like perhaps some checkboxes in System Prefs somewhere which would enable users to designate which languages we wanted... and which we didn't. And in so doing, we thereby could *prevent* Installer.app from writing any localizations to disk that we designated as excluded.

If there's nothing like that in 10.6, i'd say Snowy is starting to sound a little sucky.

> What Apple had added in Leopard (which Tiger didn't have) was an ability that allowed us to *select* the languages in the app's Get Info window...

Well, I'll be durned...never noticed.

> I thought i had read that 10.6. was supposed to finally usher in a way for us to take control of our own localizations. Like perhaps some checkboxes in System Prefs somewhere which would enable users to designate which languages we wanted... and which we didn't. And in so doing, we thereby could *prevent* Installer.app from writing any localizations to disk that we designated as excluded.

Maybe the languages option in Installer>Customize sets a flag somewhere?

Anybody know what happened with 10.6.1, i.e. were languages opted out of during Snow Leopard installation installed with the update?

From a MacWorld article on installing Snow Leopard:

You can opt out of specific language translations. Click the disclosure triangle to reveal the individual languages and then check only the languages you'll actually use.

I corrected their punctuation and sentence construction errors, so don't quote me.

I guess I wasn't totally clear. When I said upgraded I meant that I bought a new Mac Mini 2.53GHz. The factory install included the languages.

I have to say it's a real pain using the 'package contents' and then searching for the languages to delete. So much easier and quicker using the 'Get Info' window.

Well, upgraded is past tense, so that technicality (new Mac) is moot. The info from MacWorld will help if you reinstall. I guess I assumed you would interpret that from what I wrote between the lines.

Congrats on getting a new Mac! I also have a MIni, and it's great!

If finding and removing unused language files is the goal, the fastest way is to use some utility intended for that purpose. There have been several floating around for years now (DeLocalizer, Monolingual, Youpi Optimizer), some of which are now extinct. I've been using Terminal to run a custom shell script (that removes everything except English and Swedish), part of which looks like this:

find -x /path/to/folder -type d -name '*.lproj' -not -iname 'en*' \
-not -iname 'swe*' -not -iname 'sv*' -print0 |sudo xargs -0 ls -ld

Notes: Replace /path/to/folder with a real path... and ls -ld with rm -fr  (i.e., ls just lists, while rm removes)
The "sudo" is only needed for special items to which we lack sufficient write permissions.
If Swedish isn't particularly useful, then take out the "-not -iname 'swe*' -not -iname 'sv*'" stuff.

Warning: Back at MFI, we discovered some apps don't like to be cleaned that way... and will thus refuse to run. Anything by Adobe and also FontExplorerX come to mind. Therefore, the idea of cleaning the entire /Applications folder -- though entirely possible -- is potentially risky.

Also noteworthy perhaps: let's say that we have no Adobe or FontExplorerX (or any other apps that care about their languages being removed), and so running a utility (or Terminal command) can easily trim our entire /Applications folder in under 4 minutes. Though we gain back a lot of HD space... Time Machine (or any backup app) will view the situation differently, and proceed to backup every changed app.

Finally, note that apps in the /Applications folder aren't the only items with multi-languages. Both the /System and /Library (as well as user ~/Library folders) contain all sorts of bundle types which often contain such unnecessary junk.

I've been using Macaroni for years with no issues, including with Pacifist.

Pacifist 2.6.3 has finally fixed the issues i vigorously complained about in 2.5 (both at MFI and at MacNN). [so, you're welcome. ]

BTW, languages are one thing, and useless nib files are quite another. In fact, one of the great improvements in Snowy is supposedly a reduction of such waste.

How to measure space wasted by useless designable.nib files...

• ...on the HD:
  sudo find -x / -name designable.nib -exec du -sch {} +
   
• ...in the Time Machine backup:
  mdfind -0 -onlyin /Volumes/*/Backups.backupdb 'kMDItemDisplayName == "\.nib"' |xargs -0 du -sch
  mdfind -0 -onlyin /Volumes/*/Backups.backupdb 'kMDItemDisplayName == "designable.nib"' |xargs -0 du -sch |grep $'\ttotal$'
  

[i assume that last command should work... but i have no designable.nib items backed up to verify it.  i.e., mdfind uses Spotlight... and Spotlight may choose to not catalog such items. in that case, just use the 1st command and point it at /Volumes/*/Backups.backupdb instead of / --- but expect it to take ages, as it weaves through every multi-linked directory.] -- EDIT: it works... now. [helps to have the right command though, doesn't it? ] Note that (along with fixing the \.nib part) i also added an extra filter on the end:

|grep $'\ttotal$'

because sometimes there are so many files, that Unix runs out memory in the pipeline. So it calculates the current total thus far, and starts a new measurement... and we might miss all the totals. So try my new 2nd command on the Time Machine backup... it's really fast. And add up all the totals! [remove the final filter to see the actual filenames.]



--

Do you have FontExplorerX?
Which Adobe apps or suites?

If so, then perhaps Macaroni is informed enough to skip certain apps. Hats off to the developer in that case.

Oops! I just remembered that I keep Pacifist on a partition, with (more or less) all of my other 3rd party apps, so Macaroni doesn't touch it.

I've always used EasyFind to clear Pacifist's lproj files with no repercussions.

(Your command returned 42Mb of designable.nib files on my HD...hardly worth worrying about with a 250Gb drive.)

Well... if you're gonna repeat that, then i'm gonna (have to) repeat this:
> BTW, languages are one thing, and useless nib files are quite another.
[you have brought up Pacifist in the wrong context, so i'm not sure what the point is.]


That's because you have already cleared out lots of languages. What you probably don't know is that: for every single designable.nib in English, there's another one in every other language the bundle contains. [There was more than 42MB of designable.nib files in Mail.app *alone* at one point.]

Now consider your Time Machine backup. iTunes 6.5, iTunes 6.5.1, iTunes 7.0, iTunes 7.0.1, iTunes 7.1, iTunes 7.2, iTunes 8.0, iTunes 8.0.1, iTunes 8.1, iTunes 8.2, iTunes 8.2.1 (shall i continue?). And that's just iTunes. Now do that for every Mac OSX update, every QuickTime update, every iWork update, every... (shall i continue?).

Try this (if you have Leopard):
mdfind -0 -onlyin /Volumes/*/Backups.backupdb 'kMDItemDisplayName == "designable.nib"' |xargs -0 du -sch |grep $'\ttotal$'

...and imagine what it might be if you hadn't already cleared out so many languages.

EDIT: something's not right... Spotlight mdfind isn't showing everything... not even close. CURSES!

If i run a search for "keyedobjects.nib" it does show stuff in various /System/Library and /Library locations --- but it does not show anything from /Applications. So it must be rigged somehow. --- Yup; not a single *.app in the bunch. <sigh> Either mdfind won't go there or Spotlight isn't recording it.

Nevermind mdfind.

delicata:~ dkmarsh$ sudo find -x /Applications/Mail.app -name designable.nib -exec du -sch {} +

<snip>

202M total

(And that's out of a total of 718 MB found on the entire boot volume.)

Ahh, thank you.

Yes, the truth can't hide from good-old "sudo find". It's mdfind that seems to be (deliberately?) crippled.

The problem with "find" is, it would probably take all night to weave through that maze inside Time Machine's Backups.backupdb folder. To many programs, it *appears* to be roughly 30 (or more) of our HDs.

Just to clarify: since I don't use Time Machine, I can't test either command on a Backups.backupdb folder. However, it's my understanding that mdfind doesn't look inside packages, which would explain the dearth of results in /Applications.

If I point mdfind inside an application bundle, I get the expected result:

Well, perhaps "packages" is putting it too generally. It seems to me that application bundles (and several others types, like ".prefPane" for example) are being specifically excluded... which i didn't realize or expect until tonight (so you're right). But it does seem like a few types are still searchable...

$ mdfind -0 -onlyin /Applications 'kMDItemDisplayName == "keyedobjects.nib"' |xargs -0 ls -d

0 items

$ mdfind -0 -onlyin /System 'kMDItemDisplayName == "keyedobjects.nib"' |xargs -0 ls -d

411 items

So it seems to be finding "keyedobjects.nib" files inside of .device and .framework bundle types... but perhaps that's just an oversight on Apple's part. [i.e., you're right i guess... they probably wanted those excluded as well, but somehow they're sneaking through.]




Aha... a chink in the armor?  
Let me play with that for a while.

Thanks.

I get no results from that command, just a return to the prompt as with the /Applications argument.

> [you have brought up Pacifist in the wrong context, so i'm not sure what the point is.]

After realizing that Macaroni has never touched Pacifist I thought it might be helpful to mention that clearing its localizations with EasyFind never resulted in any of the issues others reported after clearing them with various de-localization apps.

> Now consider your Time Machine backup.

No Time Machine backups.

> [There was more than 42MB of designable.nib files in Mail.app *alone* at one point.]

Mail accounts for 11Mb of my current total of 42Mb.

Your point about the cumulative amount of .nib files is well taken, though.

There are a number of apps/utilities that can find and remove language packages. My personal favorite is CleanApp which sorts the packages by language and then by application. This makes it easy to very specifically target the language you want to remove and which apps you want to remove the package from.

A real feather in your hat!

...slower on the repartee than on the uptake...

That's a dandy one, Gregg; ...took me a few secs to get it.

That's bizarre... because that command not only produces (seemingly proper, albeit incomplete) output on my MacBookPro (10.5.8) but also on a nearby iMac G5 (10.4.11), though, with less than 411 items. (BTW, the item count will vary depending on which languages users may have erased or left intact, etc).

I wish i could figure out why, because mdfind does seem wacky at times. But i employed that approach you found to come up with a way of using mdfind to find stuff inside bundles. I am working on a shell script called fbi ("Find Bundle Items"), but parts of it lend themselves to 'one-liners' suitable for this forum exchange we're having. If you're into it, see how these perform on your delicata...

# DUAL MDFIND + XARGS:

mdfind -0 -onlyin /Applications 'kMDItemContentTypeTree == com.apple.bundle' |
xargs -0 -n1 -I% mdfind -0 -onlyin % 'kMDItemDisplayName == designable.nib' |
xargs -0 du -k |awk '{ siz+=$1; print } END { if (NR > 0)
printf("=====\n%.2f megs total for %d items.\n", siz/1024, NR) }'


# WHILE-READ DO LOOP:

mdfind -onlyin /Applications 'kMDItemContentTypeTree == com.apple.bundle' |
while IFS= read -r b; do mdfind -0 -onlyin "$b" 'kMDItemDisplayName == designable.nib' |
xargs -0 du -k; done |awk '{ siz+=$1; print } END { if (NR > 0)
printf("=====\n%.2f megs total for %d items.\n", siz/1024, NR) }'

In both cases, all 4 lines can be copy/pasted as a whole. If the long listing gets tiresome, take out the first 'print' command. The basic variables are the folder to search (/Applications) and the name to match (designable.nib). [i have been using "keyedobjects.nib" for my tests here, because every single designable.nib has been purged from my disks since mid-to-late April 2008.]

--

Those two pipelines work perfectly fine on my HD. However... changing the folder path from /Applications to /Volumes/*/Backups.backupdb reveals some really strange mdfind behavior. Instead of finding files by kMDItemDisplayName like it should, it starts returning all sorts of stuff with different names. I'm still trying to crack that egg... but it sure looks like a bug to me. Here is a summary showing the flaw (compares mdfind on HD, mdfind on TM backup, and regular Unix find on TM backup):

mdfind -onlyin /Applications/Mail.app 'kMDItemDisplayName == keyedobjects.nib' -count
161

mdfind -onlyin /Volumes/L_d100g/Backups.backupdb/santa-rosa/2009-11-07-002555/MacX/Applications/Mail.app 'kMDItemDisplayName == keyedobjects.nib' -count
488

find -x /Volumes/L_d100g/Backups.backupdb/santa-rosa/2009-11-07-002555/MacX/Applications/Mail.app -name keyedobjects.nib |wc -l
161

As i said, that 488 is wrong because the results list has all sorts of wrong hits (tiff files, plists, you name it). EDIT: actually i just noticed something that didn't happen earlier: it's returning a different count for each run!

[in case it's been lost in translation, my goal is to quickly and accurately measure designable.nib waste inside Time Machine's backup. While deleting languages does simultaneously reduce the designable.nib problem drastically, i think the *accumulated* (English) nibs inside TM's incremental backups (containing multiple software update versions) is something worth measuring at least.]

I used to use Youpi because it could scan folders or applications and do it quickly. Then you could look at the individual languages in each application and delete only those you didn't want. Very elegant.

Unfortunately Youpi does not work with Snow Leopard. Says I don't have authorization to delete languages even after signing in as Administrator.

So now I am scan with Youpi and then do a 'SnowPackageContents' and search for the languages.

This is a real step backward for Apple IMHO.

Yes, Youpi Optimizer used to be my favorite at one time too. But the program joemikeb describes in post #5649 sounds a lot like Youpi to me. I haven't tried it (since i use Terminal now), but perhaps you should check it out.