Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Raymond Jennings]

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ł Górny <mgorny@g.o> wrote:

> Dnia 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp <leio@g.o>
> napisał(a):
> >Ühel kenal päeval, K, 01.06.2016 kell 15:19, kirjutas Michał Górny:
> >> 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ł Górny (by phone)
>
>