Package Details: localepurge

Git Clone URL: (read-only, click to copy)
Package Base: localepurge
Description: Script to remove disk space wasted for unneeded localizations.
Upstream URL:
Keywords: locales
Licenses: GPL
Submitter: None
Maintainer: stig124
Last Packager: stig124
Votes: 259
Popularity: 0.083694
First Submitted: 2007-07-08 16:29 (UTC)
Last Updated: 2021-07-26 18:51 (UTC)

Latest Comments

vinibali commented on 2021-04-10 06:05 (UTC)

Hi! Is there any chance for the URL change? As others mentioned previously it's broken atm. Regards

adlerweb commented on 2020-11-07 10:49 (UTC)

Note that is now 404ed in favor of, however arch-patches would have to be updated for this version first. You can still get the previous version by changing the PKGBUILD source to

I second the idea of Ruben for a script to simplify transition, however - if I understand correctly - this can only replace a part of localepurge since it will not remove locales from already installed packages and is as such not able to instantly free up space.

RubenKelevra commented on 2020-04-16 22:10 (UTC) (edited on 2020-04-16 22:11 (UTC) by RubenKelevra)

I think we should remove this package, for discussed reasons.

But a simple script replacement would be nice, which starts once after installation/update and which will automatically generate the NoExtract rules based on your /etc/locale.conf and add an Include in the pacman.conf to the generated NoExtract rules-file.

This would allow rewriting this config file when there are new paths or new locales added/removed.

Sausad commented on 2020-04-11 16:19 (UTC)

As a simple basic user, localepurge is far more convenient and I am glad to use it. I went to see how to use NoExtract : All I see is an far more complicated way to configure. And no clue about how to keep multiple locale. And a Warning advising against. On another side, localepurge use the same simple syntax as locale.gen ...

Archange commented on 2019-08-08 15:08 (UTC)

I’ll remove it, but I would like to find a place in the wiki for the NoExtract rules to use instead of it.

hcartiaux commented on 2019-08-08 14:42 (UTC)

I orphan this pack, if we get a consensus here, I think we should file a removal request for localepurge.

cmcc commented on 2019-06-19 14:39 (UTC)

@ArchangeGabriel: ok, thanks for your reply

Archange commented on 2019-06-19 14:20 (UTC)

@cmcc: This package is legacy on Arch. Please read comments below.

cmcc commented on 2019-06-19 13:38 (UTC)

This package was flagged out-of-date almost 3 weeks ago, is it there any plan to update it? Thanks!

Archange commented on 2017-04-27 11:29 (UTC)

@kozaki: Well, you did not even use my example as-is, because it wouldn’t have led to this issue. But yes, my example is to be adapted obviously, would it be only because your locale might not be fr, and you might also have other softwares, etc. Regarding your vim rule, it’s outdated, because vim74 was for vim 7.4, but we’ve been on 8.0 for a while now. So it’s vim80 now. Maybe we should start a wiki page listing rules for different kind of packages? For instance, you made me discover /usr/share/i18n/locales.

kozaki commented on 2017-04-26 17:24 (UTC)

Just a note to you guys interested in cleaning your system of unused locales: Do not use as they are the pacman NoExtract rules that ArchangeGabriel posted above. Rather adapt them to your case to avoid e.g.: « I18N - X Window System doesn't support any locale »[1] [1]:

Archange commented on 2017-01-31 21:29 (UTC)

@hcartiaux I don’t want this package to be removed, nor to be updated (unless to make it useless), because I want people stumbling on this to use NoExtract. ;)

hcartiaux commented on 2017-01-31 16:53 (UTC)

As I said, it's a "legacy" PKGBUILD, use whatever you want, but I will not remove, break or let random users break and/or compromise this PKGBUILD and its huge patch ;)

Archange commented on 2017-01-31 14:03 (UTC)

@hcartiaux: Especially on a SD card, you should be concerned about extracting useless files just to remove them right after. ;) And like I said, if you have any gnome or kde app installed, you’re missing half of them with localepurge. :(

hcartiaux commented on 2017-01-31 09:14 (UTC)

Fyi, I've used localepurge on my raspberry pi, set up a couple of years ago on a 8GB SD card. I understand it is "legacy" now and that there are better method to achieve the same result, but I would prefer to keep control on it for safety reasons :) I can review any request for changes but I will not add support for an infinity of proprietary softwares...

Archange commented on 2017-01-30 15:53 (UTC) (edited on 2017-01-30 15:57 (UTC) by Archange)

@Florian: I was sure we could link AUR comments, but apparently not. Just look at comments below (those around 2016-05), though the blog post link seems dead. :( And regarding other distros, I still think this is the job of package managers, that should all have a NoExtract-like feature. It’s way more powerful than localepurge because first it acts before hand and second supports much more than just locales. ;) I’m also using NoExtract for other things, like avoiding Firefox system addons.

Florian commented on 2017-01-30 15:49 (UTC)

I admit I haven't used or even heard of the NoExtract functionality before. Which blog article are you referring to? However, the NoExtract functionality is still Arch-specific. Maybe someone should fork localepurge or bring it up to date, so that the entire community can benefit from it. In the meantime, I'll be using your rules. Thanks!

Archange commented on 2017-01-30 15:20 (UTC)

I think you might have not looked at the wiki and blog article. ;) The “exhaustive” list is quite tiny, my pacman.conf is like this: NoExtract = usr/share/help/* !usr/share/help/en* !usr/share/help/fr* NoExtract = usr/share/locale/* !usr/share/locale/en/* !usr/share/locale/en_GB/* !usr/share/locale/en_US/* !usr/share/locale/fr* !usr/share/locale/kde4* !usr/share/locale/kf5_all_languages !usr/share/locale/locale.alias NoExtract = usr/share/man/* !usr/share/man/man* !usr/share/man/fr* NoExtract = usr/share/doc/HTML/* !usr/share/doc/HTML/en/* !usr/share/doc/HMTL/fr/* NoExtract = usr/share/X11/locale/* !usr/share/X11/locale/compose.dir !usr/share/X11/locale/locale* !usr/share/X11/locale/en_US.UTF-8/* Change fr to your preferred locale or remove it altogether for only en support. There is no need for update on any new package or locale. Note that this is more up-to-date than upstream localepurge (and even this AUR package which doesn’t patch for this), which still list: – /usr/share/doc/kde/HTML/, while the kde part has been removed (just look at /usr/share/doc/HTML/ and tell me how many undesired locales you have there); – same thing in the GNOME world with /usr/share/gnome/help/ from which the gnome part has been removed (once again, just look at /usr/share/help/ and tell me how many undesired locales you have there). I’ve also included X11, which isn’t in localepurge. I have a vim one if you want too. Also they are some items specific to kde you might not want. With this setup, it would be way easier for lazyboy to add its directories (which wouldn’t be added upstream btw, since they’re in /opt). And if purging locales isn’t pacman’s job indeed, not extracting them in the first place definitively is. ;) There is no point in writing all those files to your disk just to remove then right after. :)

Florian commented on 2017-01-30 14:53 (UTC)

Purging locales isn't pacman's job. Besides needing to have an exhaustive list in your pacman.conf, you'd have to update it every time there is a new package or a package introduces a new locale. Unix philosophy: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Archange commented on 2017-01-30 14:40 (UTC)

Just curious, people who still use this rather than pacman’s NoExtract, could you tell why?

Florian commented on 2017-01-30 14:23 (UTC)

This website is only for Arch Linux packages. If you want functionality integrated into localepurge, you should contact upstream [1]. [1]

lazyboy commented on 2017-01-30 13:03 (UTC)

May you please add: /opt/google/earth/free/lang/ /opt/vivaldi/locales/ /opt/masterpdfeditor/lang/

Archange commented on 2016-05-24 12:10 (UTC)

A good article on that:

Archange commented on 2016-05-24 09:14 (UTC)

Nice, NoExtract is definitively the right way to do this. Switching to it right now (remember to do a localepurge before ;)).

symen commented on 2016-05-24 08:17 (UTC)

@meskarune I switched to using NoExtract in pacman.conf, following someone's advice on the Arch BBS. For this use-case it is cleaner and the setup is documented on the ArchWiki:

meskarune commented on 2016-05-22 23:01 (UTC)

@symen maybe you can add your hook to the arch wiki so other people can make use of it?

Archange commented on 2016-03-27 20:09 (UTC)

I would love to see this feature in. The code to be reviewed is this one? Plus your patch, right?

hcartiaux commented on 2016-02-12 09:08 (UTC)

That's a good idea, but if there's a bug in localepurge, the hook could cause a "delayed disaster", difficult to diagnose and debug... I agree to include the hook only if we take the time to review the full code of localepurge and my diff.

symen commented on 2016-02-12 02:29 (UTC)

A new feature (hooks) in pacman 5.0 (freshly released) would allow localepurge to run after each install/update containing locales. I quickly wrote a hook file that seems to work fine (but may spit too much output): Do you plan to bundle a similar hook with localepurge ? I think this would make localepurge much nicer to use, but I don't know if this should be bundled with localepurge or installed as an additional package.

kozaki commented on 2014-12-09 15:20 (UTC)

This makes a difference in disk's utilisation Thanks a lot hcartiaux for adopting it!

hcartiaux commented on 2014-02-04 20:49 (UTC)

I had to recreate the patch localepurge.config.diff. I've tested and it should be ok, you can read my diff here:

hcartiaux commented on 2013-10-30 12:06 (UTC)

I adopt (unexpectedly) this package because I use it on 5 archlinux systems and ~ 100 small debian servers ;)

fgr commented on 2013-05-31 17:41 (UTC)

@eworm and Fred: Fixed, many thanks.

FredBezies commented on 2013-05-31 10:43 (UTC)

Just replace : install -D -m755 ${srcdir}/${pkgname}/usr/sbin/localepurge ${pkgdir}/usr/sbin/localepurge by install -D -m755 ${srcdir}/${pkgname}/usr/sbin/localepurge ${pkgdir}/usr/bin/localepurge And install -D -m755 ${srcdir}/${pkgname}/debian/localepurge.config ${pkgdir}/usr/sbin/localepurge.config by install -D -m755 ${srcdir}/${pkgname}/debian/localepurge.config ${pkgdir}/usr/bin/localepurge.config

eworm commented on 2013-05-29 09:53 (UTC)

Please install scripts to /usr/bin (not /usr/sbin) to prepare for /usr move. Thanks a lot!

d_adler commented on 2012-11-10 01:02 (UTC)

Validity check not passed for all files except localepurge_0.6.3.tar.gz

eworm commented on 2011-11-17 12:41 (UTC)

It got even worse... Now everything but localepurge_0.6.2+nmu2.tar.gz fails the validity check.

eworm commented on 2011-11-16 15:25 (UTC)

localepurge.8.patch and locale.nopurge fail the validity check.

fgr commented on 2011-11-13 15:00 (UTC)

From localepurge(8): "All locale directories containing a subdirectory named LC_MESSAGES which are either commented out or not even listed at all in /etc/locale.nopurge will be irreversibly deleted." If some locale directory doesn't contain the LC_MESSAGES subdirectory, I think that issue is not related to the localepurge script. But it could be a patch to add :-)

dlin commented on 2011-11-11 04:47 (UTC)

I found there are some other locale in gvim. How to remove them? /usr/share/man/pl.ISO8859-2/* /usr/share/man/ru.KOI8-R/* /usr/share/man/it/* /usr/share/man/fr.ISO8859-1/*

yegorius commented on 2011-07-13 23:33 (UTC)

> pacman -Qo /usr/share/locale/currency/eur.desktop /usr/share/locale/currency/eur.desktop is owned by kdebase-runtime 4.6.5-1 > pacman -Qo /usr/share/locale/l10n/de/entry.desktop /usr/share/locale/l10n/de/entry.desktop is owned by kdebase-runtime 4.6.5-1 But I also have DONTBOTHERNEWLOCALE set in /etc/locale.nopurge, maybe this is the cause?

fgr commented on 2011-07-10 09:30 (UTC)

Do you know any PKGBUILD that copies '.mo' file in /usr/share/locale/{l10n,currency}?

yegorius commented on 2011-06-29 13:48 (UTC)

Maybe taht's because KDE packagers in Arch save KDE specific locales in /usr/share/locale/{l10n,currency}, while other distros use another locations for this files.

fgr commented on 2011-06-18 09:25 (UTC)

It's strange that nobody haven't got any problem so far (given that it has been four years since it first submitted ;-) Anyway, I can't update anything at this time.

yegorius commented on 2011-06-18 01:25 (UTC)

if l10n directory is purged by localepurge, then KDE users can not set timezones, calendar and language preferences in KDE.

fgr commented on 2011-06-07 20:25 (UTC)

I'm using K3b (Italian localisation). So, I don't know what is the issue.

yegorius commented on 2011-06-07 17:27 (UTC)

By default localepurge deletes all KDE locales and currency info. To avid this add "l10n" and "currency" to /etc/locale.nopurge Like this: C en en_GB en_GB.UTF-8 l10n currency Should I report this upstream?

fgr commented on 2011-05-15 19:21 (UTC)

hmm, you are right! I use Emacs with pkgbuild-mode -- surely I didn't do all the right steps. Perhaps, there was some old source file in my $ABSROOT that was in conflict with the directory contains my localepurge PKGBUILD. Sorry. Fixed.

commented on 2011-05-15 18:40 (UTC)

I concur with FredBezies and enzolatina! I copied the patch straight away and used two different md5sum programs and both came out as "5b926906daddf0269ba70d8d1451876c" just to be sure.

FredBezies commented on 2011-05-15 17:26 (UTC)

Here is what makepkg -g gave me : md5sums=('6a1e13f32cd5f7ca842db9acdf1b9cb4' '57a5be0f64e6873807d3664b468cb001' '5b926906daddf0269ba70d8d1451876c' '24340f0218d225d2510eee94a77ad676' '5ab92139004dcd282d6ee82e39ba0ffb')

commented on 2011-05-15 16:31 (UTC)

same here, localepurge.8.patch failed... this is the right md5sum: 5b926906daddf0269ba70d8d1451876c

fgr commented on 2011-05-15 13:19 (UTC)

@harryNID: it's odd, because I've just done a diff and the md5sums seems OK. The md5sums are: md5sums=('6a1e13f32cd5f7ca842db9acdf1b9cb4' '57a5be0f64e6873807d3664b468cb001'\ '9de6d8f46e4d2d1be46d3781ab8764f5' '24340f0218d225d2510eee94a77ad676'\ '5ab92139004dcd282d6ee82e39ba0ffb')

commented on 2011-05-15 11:31 (UTC)

@fgr - Could you please check the md5sums in the PKGBUILD. I'm getting a "One or more files did not pass the validity check!" on "localepurge.8.patch ... FAILED". Thanks

fgr commented on 2011-05-15 10:01 (UTC)

There are no updates for localepurge script, but I've revised localepurge man page and the PKGBUILD (replaced bash '[[' with sh '[').

fgr commented on 2010-12-18 12:41 (UTC)

I've just moved my patches to another host, renamed the ones from '*.diff' to '*.patch' and changed my email address in the localepurge.8.patch file.

schivmeister commented on 2010-11-14 10:53 (UTC)

Ahh OK. Anyway I wanted to bring this to [community], but I've decided it's best left here and under your care. So keep up the work with this :)

fgr commented on 2010-10-23 13:55 (UTC)

Updated PKGBUILD to apply the hint by schivmeister. Note: I'm going to update pkgrel (starting from 1) since a new upstream version will be released.

fgr commented on 2010-10-16 09:29 (UTC)

Hi schivmeister, sorry for the delay in replying. About first point: I haven't decided to release a fork of the localepurge original version. However, as you rightly say later in your comment, the GPL doesn't grant me permission to redistribute a work with another license. About second point: probably, I'll follow your hints. Thanks. > One final note is that I don't know whether your licensing is valid, since you are deriving GPL work. GPL dictates copyleft for derived works. The Gentoo adaptation of localepurge is also GPL. Why go through the trouble of changing the license (to an invalid one) when all you're doing is patching the program for redistribution? IMO, my license is like CPL <> or WTFPL <>. Obviously, only my code is released with my custom license (that is for my patches). Just a note about my license: I think the GPL is not truly free. Moreover, it doesn't reject intellectual property. I don't give a damn about some silly laws. My license hasn't approved by any institutions or state laws. It's just for this that, IMO, one is very permissive. And people aren't able to use the law to enforce the rights given by the license. But this is philosophy and off topic here.

schivmeister commented on 2010-10-12 16:56 (UTC)

Hello One thing: the copyright notes on the debian page tells me this is GPL software. Why is the license here custom? edit: nevermind..i see this is your own patched tarball it's downloading. edit2: you can go 2 ways.. 1) You should just pre-patch the files and release the tarball. In this case you would be "upstream". So the PKGBUILD should only need to move files around. As you would be deriving an existing work, you are free to bump or add revision numbers. A "localepurge-arch-0.6.2_$customrel" looks good to me and the underscore is friendly with our package management (ie. $pkgver). OR 2) Release only your patches. The PKGBUILD should download the deb src or whatever it is that gives you the original files. It will also download your patches, and the steps would be pretty much the same as they are now. If your patches change, there will be pkgrel updates only. One final note is that I don't know whether your licensing is valid, since you are deriving GPL work. GPL dictates copyleft for derived works. The Gentoo adaptation of localepurge is also GPL. Why go through the trouble of changing the license (to an invalid one) when all you're doing is patching the program for redistribution?

fgr commented on 2010-09-15 14:24 (UTC)

> why don't you simply make and host an Arch-release of this package? > It is totally annoying to check the diffs everytime this package updated! it could be a good hint... > And once again, the pkgrel describes the Arch _package_ release number, not the version of the updated sources! oh yes, I think it must be so, because the upstream author doesn't release any package-0.0.0"-0"... > If you don't make it right, please disown this package. You should better calm down... Just propose your hint at aur-general mailing list, then mail me (or leave a comment on this page) what the community says on the issue. Not just what you like.

donvla commented on 2010-09-14 13:17 (UTC)

I brought this up before, but why don't you simply make and host an Arch-release of this package? It is totally annoying to check the diffs everytime this package updated! And once again, the pkgrel describes the Arch _package_ release number, not the version of the updated sources! If you don't make it right, please disown this package.

donvla commented on 2010-09-14 13:03 (UTC)

"==> Validating source files with md5sums... localepurge-arch-0.6.2.tar.gz ... FAILED ==> ERROR: One or more files did not pass the validity check!"

fgr commented on 2010-09-04 16:08 (UTC)

updated README.txt; fixed a typo in the man page.

fgr commented on 2010-08-23 20:00 (UTC)

@Stebalien fixed, thank you.

Stebalien commented on 2010-08-23 17:10 (UTC)

The patches have already been applied (your PKGBUILD is trying to repatch them).

commented on 2010-05-28 09:30 (UTC)

Ah ok. Thanks for the info, I'll have a look. It might be good to reflect the change in the source package (0.6.2.arch1, 0.6.2.arch2 or something) rather than just bumping the package rel. As it stands old PKGBUILDs point at a "localepurge-arch-0.6.2" that doesn't exist anymore because it's changed without it's name changing.

fgr commented on 2010-05-28 09:21 (UTC)

You can see the reason for that by taking a look at "localepurge.config.diff" file. If I do a new rebuild that means there's some reason. :-) For example: in the past I've changed the license for my patch scripts (2-clause BSD license -> ISC -> WTFPL ->; now I've written my license).

commented on 2010-05-28 07:04 (UTC)

What is the reason for the latest rebuild? The only difference seems to be the md5sum, but the source package has the same number. Has the source changed somehow?