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 4E7E713829B for ; Sun, 29 May 2016 13:04:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 885651435F; Sun, 29 May 2016 13:03:50 +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 7E0EE14355 for ; Sun, 29 May 2016 13:03:49 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 52045340B3B; Sun, 29 May 2016 13:03:46 +0000 (UTC) Date: Sun, 29 May 2016 15:03:42 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Mart Raudsepp Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess? Message-ID: <20160529150342.23864767.mgorny@gentoo.org> In-Reply-To: <1464333440.13834.12.camel@gentoo.org> References: <20160521094128.0a7c7766.mgorny@gentoo.org> <20160521151907.GA6619@waltdnes.org> <1464333440.13834.12.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) 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-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/lj=EHJLh3zeGLDg6l.g6vY9"; protocol="application/pgp-signature" X-Archives-Salt: 9bbde40f-4974-41d4-9340-c61c1e7a6485 X-Archives-Hash: 8561534b2c44121b06d3a04da960d74a --Sig_/lj=EHJLh3zeGLDg6l.g6vY9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 27 May 2016 10:17:20 +0300 Mart Raudsepp wrote: > =C3=9Chel kenal p=C3=A4eval, L, 21.05.2016 kell 11:19, kirjutas > waltdnes@waltdnes.org: > > On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? G=C3=B3rny wrote =20 > > > 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]. =20 >=20 > Short of making an exception to LINGUAS in the USE_EXPAND rules, I > think this is the only way. >=20 > > 5. An reversed variant of INSTALL_MASK in make.conf, e.g. > > LOCALE_ALLOW=3D"foo bar fubar" > >=C2=A0 > > 6. Integrate localepurge into Portage, and run it post install > >=20 > > =C2=A0 There are some lazy programmers out there who *DO NOT* respect t= he > > LINGUAS setting, and splatter files throughout /usr/share/locale/* > > and > > /usr/share/man/* regardless.=C2=A0=C2=A0That's the reason "localepurge"= was > > written in the first place.=C2=A0=C2=A0Any proposed solution should tak= e that > > problem into consideration, and handle it too. =20 >=20 > For both of these cases, I have to point out that e.g > LINGUAS=3D"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. Just to be clear, I don't think we care that much about filtering those. I can understand people not wanting to install a dozen translation files because of their potential size, especially when filesystem can't handle small files efficiently. But stripping extra descriptions from .desktop files doesn't seem like a major use case. > 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. That's yet another reason not to extend the abuse of LINGUAS. I don't really see adding another rule to PMS that attempts to enforce this. > 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) >=20 >=20 > 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. Well, this is certainly something that can be done. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/lj=EHJLh3zeGLDg6l.g6vY9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXSuiuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO8K8QALZhYduEhd/JNitDBxXOwFip j2WtqQkygA4Amx2IOLdN4yCnofkCNpmDKfQtYsRqYwzGrrUcDzcZ3RGhskB/LVCh ph0BZkw6MXMXutV/oNlj3NNPO3OefdZ+7De+WINXTnCBnmDjUBEO0trc2LlGIjhi IHJEpo5Kj1aR1WxQWKDZdNyFgnCR7zRrwZOJZd7xah+00pCyAxXWQS6pjVFgDRm6 5S/uRTbs9F8nWelEW2aYx2riQI/IWgX68YesWBptaDy1YVAOs8Q/TIoVdoStUlgO 2fOM3Txv7cmiydOni/RY5z8Zjbb6uYFNRjW85tzWSBJy7rNzSkPtp5Bnc3LMJRvR mOWinDYwMElQL2L3kJsOVFECd1MAIFntBeh7As+mnKtUKvW3AGodlbF3yyXPvE43 jaO8dCONoeD/GueRfPhh9JPwB5MRXqZ9AQ04y/2cKBGDyBtAZvS38/JOYtJxLzxs sCoSmLzIk8P63wcxF5PYUdEZEFld6dzu5akV16n6l0yrzn4JkgI6tUxAEyVN8HBv 0fIUzwl36icu29TvOG++YNE4IehoFj0BLR+A0Q1PLcB2uGScm/+gDt3JMneu9jql fXuzu1tEdNQinVun4vDzq1797p5+NFHXFq+OmcfEUt73MxBPueWnGKP7wfE67C46 GFxhQbCuoeoghKSKknU/ =QEw9 -----END PGP SIGNATURE----- --Sig_/lj=EHJLh3zeGLDg6l.g6vY9--