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 7D17C13829C for ; Wed, 1 Jun 2016 16:04:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AA7D6142AB; Wed, 1 Jun 2016 16:03:51 +0000 (UTC) Received: from mail-oi0-f68.google.com (mail-oi0-f68.google.com [209.85.218.68]) (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 AA6C125402B for ; Wed, 1 Jun 2016 16:03:50 +0000 (UTC) Received: by mail-oi0-f68.google.com with SMTP id x130so4960876oia.3 for ; Wed, 01 Jun 2016 09:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UQVlwCB8Rz0ZLA53cEFkZVR7G/KRvlxK0ztMLJfWCpc=; b=YxSNZmNFC/gRMPelmWcilr2vS6YKtqswn1RR1V+XmWKAY0a9S7iJpw9r+nEDM9gVy3 g1X2T/SvodCOFW0WOr3FfGNSwbaUXjF1F89Vo5PkDB+xgXE0LY2QnJFBoNnDGt13eKFW vrO4OViHIE4qmjNNl3hxAQMgnguCb3clXzyVn5lzkaEg+ssmENB/BAV6pAM7iHilOmqE +PXkpmkC073UhFHM7LY9/FZ+udnqWCkFcYA3ADM6bGRI2uU8apd3B82KkTLwpQlC7uiU Fu8T8T9g3DTOfDhNaeq1Q9HGFp1/MaIAYsYBe98RGKu6+tSq3H8IzbeQapeX3wJUXilc PmOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UQVlwCB8Rz0ZLA53cEFkZVR7G/KRvlxK0ztMLJfWCpc=; b=ahQc0Zq7HaAyZ++yOMUAln9MaV6Rlt8R2ya89JqdDNyrM1LnBLTDRoVJJYxw3PejpF 2hNdHxH+/4re4XXDkFlTXPl0C0JR0wjDdxDckIUa170wiMkut9vpfa6KLSNOWyVYR5Bm xsmTWOhKqk/2UlTOLi3AikeXspzxAfvxOWlQSZQn3TGLYrAusKbp/D4AxWmXKlB/Yxrz 1o8oUGJdVLu3k4Cl1Kxs4h6GeDie6FrJqzW6USBZ+/loILr8PU4J3PCASUW1ce1b8F4v wRAonwguDiJQOVWx9P01WUd4DQm4JvMsjGaJ6otqT5dgmCHgNg1yWb7ivWV85dBhUrBF zGHQ== X-Gm-Message-State: ALyK8tKUsMJQ4LqbIXHUv03eEvSGu+eiVbfeB0kyUb2fZfyXJk7FKcrdREf0z7nAQzWM3zi4zeQ8vg5CJZctoA== X-Received: by 10.157.56.39 with SMTP id i36mr3153799otc.67.1464797029552; Wed, 01 Jun 2016 09:03:49 -0700 (PDT) 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 Received: by 10.202.244.72 with HTTP; Wed, 1 Jun 2016 09:03:09 -0700 (PDT) In-Reply-To: References: <20160531144926.4937d77a.mgorny@gentoo.org> <1464789820.11446.25.camel@gentoo.org> From: Raymond Jennings Date: Wed, 1 Jun 2016 09:03:09 -0700 Message-ID: Subject: Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems To: gentoo-dev Cc: Mart Raudsepp Content-Type: multipart/alternative; boundary=001a113ef5fc9d58f5053439a2f9 X-Archives-Salt: 823c53e9-7025-4f48-a675-7b1a0e624f86 X-Archives-Hash: 49be55996b1224c90eb4641a1c045d98 --001a113ef5fc9d58f5053439a2f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd honestly as a minor issue like ot know why we called it linguas in the first place. Linguas itself is latin/romance based in name, so gentoo at least has been showing a bit of a bias. Personally I think its a bad name on neutrality grounds alone. I think though I should also point out...don't we already have existing ebuilds that expose LINGUAS options in their USE flags? On Wed, Jun 1, 2016 at 7:17 AM, Micha=C5=82 G=C3=B3rny = wrote: > Dnia 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp > napisa=C5=82(a): > >=C3=9Chel kenal p=C3=A4eval, K, 01.06.2016 kell 15:19, kirjutas Micha=C5= =82 G=C3=B3rny: > >> As for LINGUAS, it should be left as a toy for advanced users and not > >> presented as a recommended solution. > > > >There is nothing advanced in it for the user, only the mess we have > >created with package manager behaviour and mis-use of it (the order > >matters case; which I believe is long eradicated). > >We are a source based distribution, and gettext/intltool upstream > >LINGUAS behaviour is perfect advantage for our main use case of > >customizing ones own system and almost always building things from > >source, only using binary packages before an upgrade as a backup, if at > >all. > >So it's natural to use the way that really build only the support you > >want. This is what LINGUAS gives you, when the PM doesn't happen to > >munge it. > > > >Hiding this away under some toy for advanced users is not in our spirit > >of Gentoo, as far as I would judge. > > You forget the important point that it's done silently and implicitly, > with no clear way of knowing which localizations were actually discarded > afterwards. > > And the fact that currently LINGUAS affects both packages listing the > flags and not doing so is causing even more confusion. > > > > >But this is a matter of documentation at this point, in principle I > >agree that SRC_URI extra downloads should be under a different naming. > > > >INSTALL_MASK groups for locales is what I would consider a convenience > >for binary package builders in a wide environment where language choice > >to the end user preferably gets filtered on deployment in a site- or > >machine-specific manner. Or a toy for advanced binary distribution > >creators, if you will. A way for binary packages to provide almost as > >good support for LINGUAS as source packages (but not quite). > >That said, supporting our binary package ecosystem is very important, > >and I applaud these efforts. The proposed INSTALL_MASK improvements are > >very useful for many other cases as well. For source-based users as > >well (openrc init scripts, systemd unit files, gtk-doc documentation, > >etc) > > > >Either way, the masterplan works out, I just don't think we need to > >wait for INSTALL_MASK groups here in any way. The reminder is a matter > >of documentation, a matter of perspective. > >This l10n.eclass PLOCALES nonsense needs to go ASAP. > > > > > >Mart > > > -- > Best regards, > Micha=C5=82 G=C3=B3rny (by phone) > > --001a113ef5fc9d58f5053439a2f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd honestly as a minor issue like ot know why we call= ed it linguas in the first place.=C2=A0 Linguas itself is latin/romance bas= ed in name, so gentoo at least has been showing a bit of a bias.

Personally I think its a bad name on neutrality grounds alone.

I think though I should also point out...don't we= already have existing ebuilds that expose LINGUAS options in their USE fla= gs?

On= Wed, Jun 1, 2016 at 7:17 AM, Micha=C5=82 G=C3=B3rny <= mgorny@gentoo.org> wrote:
Dnia= 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp <leio@gentoo.org> napisa=C5=82(a):
>=C3=9Chel kenal p=C3=A4eval, K, 01.06.2016 kell 15:19, kirjutas Micha= =C5=82 G=C3=B3rny:
>> As for LINGUAS, it should be left as a toy for advanced users and = not
>> presented as a recommended solution.
>
>There is nothing advanced in it for the user, only the mess we have
>created with package manager behaviour and mis-use of it (the order
>matters case; which I believe is long eradicated).
>We are a source based distribution, and gettext/intltool upstream
>LINGUAS behaviour is perfect advantage for our main use case of
>customizing ones own system and almost always building things from
>source, only using binary packages before an upgrade as a backup, if at=
>all.
>So it's natural to use the way that really build only the support y= ou
>want. This is what LINGUAS gives you, when the PM doesn't happen to=
>munge it.
>
>Hiding this away under some toy for advanced users is not in our spirit=
>of Gentoo, as far as I would judge.

You forget the important point that it's done silently and impli= citly, with no clear way of knowing which localizations were actually disca= rded afterwards.

And the fact that currently LINGUAS affects both packages listing the flags= and not doing so is causing even more confusion.

>
>But this is a matter of documentation at this point, in principle I
>agree that SRC_URI extra downloads should be under a different naming.<= br> >
>INSTALL_MASK groups for locales is what I would consider a convenience<= br> >for binary package builders in a wide environment where language choice=
>to the end user preferably gets filtered on deployment in a site- or >machine-specific manner. Or a toy for advanced binary distribution
>creators, if you will. A way for binary packages to provide almost as >good support for LINGUAS as source packages (but not quite).
>That said, supporting our binary package ecosystem is very important, >and I applaud these efforts. The proposed INSTALL_MASK improvements are=
>very useful for many other cases as well. For source-based users as
>well (openrc init scripts, systemd unit files, gtk-doc documentation, >etc)
>
>Either way, the masterplan works out, I just don't think we need to=
>wait for INSTALL_MASK groups here in any way. The reminder is a matter<= br> >of documentation, a matter of perspective.
>This l10n.eclass PLOCALES nonsense needs to go ASAP.
>
>
>Mart


--
Best regards,
Micha=C5=82 G=C3=B3rny (by phone)


--001a113ef5fc9d58f5053439a2f9--