From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 16EA1138283 for ; Fri, 27 May 2016 07:17:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 549D0142A1; Fri, 27 May 2016 07:17:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4F89E22404E for ; Fri, 27 May 2016 07:17:26 +0000 (UTC) Received: from [192.168.2.63] (85.253.84.66.cable.starman.ee [85.253.84.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 085E4340C24 for ; Fri, 27 May 2016 07:17:24 +0000 (UTC) Message-ID: <1464333440.13834.12.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess? From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Fri, 27 May 2016 10:17:20 +0300 In-Reply-To: <20160521151907.GA6619@waltdnes.org> References: <20160521094128.0a7c7766.mgorny@gentoo.org> <20160521151907.GA6619@waltdnes.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 0560515a-ee88-4ef9-a0d7-58741610d014 X-Archives-Hash: 408b1d29e05a9ecb99a1f2f13503d1e3 Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas waltdnes@waltdnes.org: > On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote > > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds > > have > > a good reason to use flags for localization, we introduce a new, > > non-colliding USE_EXPAND for that. We also ask users to replace > > LINGUAS > > with the new flag in their make.conf files. LINGUAS gets the > > original > > upstream behavior back, and we eventually discourage it in favor of > > new > > INSTALL_MASK features (WiP) [2]. Short of making an exception to LINGUAS in the USE_EXPAND rules, I think this is the only way. > 5. An reversed variant of INSTALL_MASK in make.conf, e.g. > LOCALE_ALLOW="foo bar fubar" >  > 6. Integrate localepurge into Portage, and run it post install > >   There are some lazy programmers out there who *DO NOT* respect the > LINGUAS setting, and splatter files throughout /usr/share/locale/* > and > /usr/share/man/* regardless.  That's the reason "localepurge" was > written in the first place.  Any proposed solution should take that > problem into consideration, and handle it too. For both of these cases, I have to point out that e.g LINGUAS="en et pl" does not mean "keep only /usr/share/locale/{en,et,pl}/*", it means have support for only these languages. This means for example that *.desktop files will have translations in them only for those language. Same for dconf schema files. Same for many other things. MO Translation files and manuals aren't the only thing here, especially with intltool (and many of these intltool features are now part of gettext proper). In short, LINGUAS affects the content of files too, not only the existence of files. See any file in /usr/share/applications/ for example. I always put "en" as my first in LINGUAS, due to historical abuse of the first value there, I think e.g mplayer or vlc used to do this. LINGUAS is an unordered list, but some packages used to took the first value as meaning the default and switch the UI to that by default, instead of honoring LC_* variables. Another reason I put "en" there, is because of IUSE_EXPAND and packages that might not be natively english, but do have english translations (I think I've seen some french ones like that :D) And no, localepurge is not capable of stripping these translations out of existing files. To my knowledge at least. Though it could be improved to do so in some cases. Mart