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.

CleanApp is similar to Youpi except that it costs money,$15, oh well. . .

I just discovered MacPilot will also remove localization files.

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) }'

488.13 megs total for 3376 items.

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) }'

488.13 megs total for 3376 items.

Things appear to have improved somewhat with Snow Leopard.....

=====
159.24 megs total for 1353 items.
=====

was the result I got and it was from only 5 apps.....iWeb, iPhoto 8.1, Skype, HP Setup Assistant, and the Bluetooth Firmware Update (which I think is a legacy from past OS's....).

Looks great... until we point it into a Time Machine backup subfolder. i have indexing enabled on that volume... and using mdls shows plenty of metadata on various items there. Just that mdfind produces what i can only call "imaginary" output. I give up. [i can still play with my fbi script on regular disks though, but that wasn't the end i was meaning to reach.]

I have tinkered briefly with 2 GUI tools, so that looks like the way to go. File Buddy would have been promising (especially since it can total the size of found files). Unfortunately it tries to build and sort its list before displaying any items (like the dual xargs). EasyFind works nicely, as it builds its list on the fly (à la while-read-do). Unfortunately, i don't see any way for it to report the total size. When i selected 3000+ items in a limited /Applications folder search, it tried to open 3000+ individual Get Info windows... so i had to force quit.

HOWEVER, I'm starting to understand that we cannot select the "Backups.backupdb" folder itself as the source to search. It's too big, and it actually represents many versions of our HD. But something like Backups.backupdb/computername/2009-11-11-001247/MacHD (or use the "Latest" symlink) is the way to go for calculating ... no wait, that would miss some designable.nib files in outdated backups. Perhaps "walk" across all backups and capture the found items along with their *inode* numbers. Then sort that list and remove duplicate inodes.

Hmm, it's quite a puzzle actually. [a special tool would be needed... i.e., neither EasyFind nor anything not specifically designed to walk through all those multi-linked directories and then remove duplicate inodes will ever produce truly accurate results.]

Nah. Finder may show you a bundle as if it were a file, but to Time Machine it's just another folder. Time Machine will treat it just like any other folder with some items deleted: it has to create a new directory with a shorter list of contained items, but none of the unchanged files would be copied again.

That's why Time Machine gets along so well with .sparsebundle disk images. It sees each 8MB band as a separate file, and only copies those bands that changed.

True. But it still did some sort of backing up action to "record" everything that changed (even if it was done with a clever use of links). My intended point wasn't so much that free space on the backup disk would decrease (or increase for most other backup types), but simply that the story doesn't end the instant a ton of languages are removed... and that there will be a ripple effect of some sort [since backup apps will perceive a mass change, and then do whatever it is they're configured to do (depending on the type of backup), in response to that change.] Just wanted to remind readers (or otherwise make them aware) that their next backup will be considerably busier than usual.

i like using exclusions in rsync (and GUI utils that provide them), to see to it that certain items don't ever get backed up in the first place.


Don't get me wrong... i am in absolute awe of Time Machine. I think that whole snapshot business is brilliant (was that Rubel's concept in the beginning?... or, where/when did it originate then?). It does get bizarre at times though, if/when we try to approach "Backups.backupd" as if it were an ordinary folder... because it's a lot 'hairier' than that.



There are situatons however where TM is not quite as efficient as some users might expect. Say we have a huge folder with a zillion items... and we decide to rename (or move) that folder. Instead of recording just that renaming (or moving) "event" somehow... this time, all that recopying (i.e., total duplication of data) does occur.  Does it not?


--

BTW, in case anyone thought of it... i did try substituting kMDItemDisplayName above (including all the stuff on page 1) with kMDItemFSName the other day, but it makes no difference [where anything inside Backups.backupd is concerned.]

It is. However, I saw a comment on, I believe, MacOSXHints to the effect that Snow Leopard's Finder will copy "Backups.backupd" correctly in response to a simple drag and drop. I couldn't find a reference to that anywhere in the release notes, but as it turned out I had a virgin disk drive that I had just gotten with the specific intention of backing up my Time Machine backup. (I had just had my second Time Machine drive die on me, and while I didn't lose any data either time it irks me to lose all that history.)

So I tried it. Finder warned me I might have to authenticate afterwards, but then went ahead and did the copy. I checked the copy every which way I could, and found no problems with it. du says it was exactly the same number of sectors as the original. All the permissions were correct, including all the ACLs. The extended attributes (including com.apple.metadata:_kTimeMachine{Old,New}estBackup) were copied faithfully.

And when I told Time Machine that I now wanted to back up to the copy instead of the original, it obligingly accepted the copy as a legitimate backup, copying over only the files that had changed in the meantime.

The final test was when I told SuperDuper to copy it again, and SuperDuper (which is certified to clone TM backups correctly) reported the same differences as TM had.

It does. And if you then move the folder back where it was, TM will copy the whole thing again, even though that folder is already present at that location in an earlier backup. TM only compares NOW with "Latest good backup".

I've also noticed that TM does not preserve hard links. If you have two files hard-linked together, TM copies it as two separate files. (You can check this by using (appropriately enough)
ls -li {,/Volumes/*/Backups.backupdb/*/Latest/*}/bin/{ln,link}
to verify that /bin/ln and /bin/link are hard-linked to each other, but their TM backups are not.