From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RvAxI-00079n-DV for garchives@archives.gentoo.org; Wed, 08 Feb 2012 17:05:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AB3E6E075B; Wed, 8 Feb 2012 17:05:03 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.43]) by pigeon.gentoo.org (Postfix) with ESMTP id E3004E05F2 for ; Wed, 8 Feb 2012 17:04:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vm-relay7.estpak.ee (Postfix) with ESMTP id 2C66D5EA for ; Wed, 8 Feb 2012 19:04:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at vm-relay7.estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (vm-relay7.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7gN09kmOeiQ for ; Wed, 8 Feb 2012 19:04:16 +0200 (EET) Received: from mail.neti.ee (neti-relayhost2.estpak.ee [88.196.174.199]) by vm-relay7.estpak.ee (Postfix) with ESMTP id 6F5D419F for ; Wed, 8 Feb 2012 19:04:16 +0200 (EET) Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom; client-ip=90.191.204.24; helo=[192.168.1.80]; envelope-from=leio@gentoo.org; receiver=gentoo-dev@lists.gentoo.org X-SMTP-Auth-NETI-Businessmail: no Message-ID: <1328720665.16022.8.camel@daedalus.lan> Subject: Re: [gentoo-dev] Understanding the LINGUAS variable and use-expand From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Wed, 08 Feb 2012 19:04:25 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit 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 X-Archives-Salt: ac7ec1b5-2036-4a1b-8e72-aecb0dc1ac22 X-Archives-Hash: d5f68a7c861ddd4c5fd47202efa81910 On K, 2012-02-08 at 11:32 -0500, Mike Gilbert wrote: > I just want to sanity-check my brain here. > > LINGUAS seems to be mainly a variable to control the behavior of > gettext's autoconf code, installed as /usr/share/aclocal/po.m4. > > If LINGUAS is set to a list of language codes, the build system will > only build/install MO files for those languages. If LINGUAS is unset, > the build system will build/install MO files for all available > languages. > > Portage will also use-expand LINGUAS, so an ebuild *can* make use of > it where USE flags are needed. For example, in SRC_URI, where the USE > flags may be used to control downloading of extra language packs. > > Given this information, I come to a few conclusions: > > 1. There is technically no need to define IUSE="linguas_$x" if an > ebuild is not using the USE flags in other ebuild metadata (like > SRC_URI). I'm not sure, but it is not feasible to list them for exposing languages a package has been translated to via gettext/intltool. That's completely unmaintainable and unnecessary. Each version bump could change it, hard and time consuming to validate, etc. > 2. In cases where the USE flags are needed, they should be enabled by > default to emulate the "default-all" behavior of the autoconf macros. > For example: IUSE="+linguas_fr_FR +linguas_de_DE". I would like that, but I don't think any or many packages do so when they use it in SRC_URI > 3. An ebuild could use LINGUAS to control installation of translation > information which does not come from gettext PO files. It does not > necessarily need to make use of the linguas_$x USE flags to do so. One such widely used way is to use intltool, which amongst other things handles PO files as well (of course via gettext tools in the end), but also other things. > Does all of that make sense? > > I am considering simplifying www-client/chromium from the current mess > based on the linguas USE flags to basically just this: > > if [[ ${LINGUAS} ]]; then > for x in *.pak; do > mylang=${x%.pak} > mylang=%{x/-/_} > has $mylang $LINGUAS || rm $x > done > fi It would perhaps be nicer if upstream honored LINGUAS itself too or so... I think users could be surprised a bit about cases where you have variants or dialects, e.g currently as IUSE=linguas_fr_FR, when users only have LINGUAS=fr - in gettext they often don't have a fr_FR.po, just fr.po; if locale has LC_MESSAGE and LANG at fr_FR, it will look at "fr" if more specific fr_FR not found. I define things like LINGUAS="en en_US et et_EE" to be really sure, but I doubt many users do that (but that's just a guess). If it's exposed via IUSE, then they can at least have some visual cue of that. I guess it wouldn't be a concern if we had a tool to set the LINGUAS that handled this variant logic nicely, or just educating users in documentation, make.conf.example comments and so on. > As well, there are probably a few other places in the tree where > conclusion #1 and #2 should be applied. Best, Mart Raudsepp