RFC: l10n.eclass
 

Today I would like to present to you my proposal for a new eclass with
helper functions for treating localizations: l10n.eclass (see the
attached file or [1]). Its functionality can be used in other eclasses
(such as qt4-r2 and cmake-utils) as well as directly in ebuilds.

In order to keep the code simple, and prevent double loops and extra
variables (such as currently used in the media-video/smplayer ebuild),
I am proposing that we should add any missing long-form locales to
profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
This also means that users may have to expand their LINGUAS setting in
make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
cover the different variants used in packages.

If you have any comments, spot any mistakes, or have proposals for
improvement, I would love to hear it! I would especially love from
maintainers of complicated packages such as libreoffice-l10n, if there
is any additional functionality that we could include in this eclass
to make their job simpler.

1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

RFC: l10n.eclass
 

On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
>
> In order to keep the code simple, and prevent double loops and extra
> variables (such as currently used in the media-video/smplayer ebuild),
> I am proposing that we should add any missing long-form locales to
> profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
> This also means that users may have to expand their LINGUAS setting in
> make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
> cover the different variants used in packages.
>
> If you have any comments, spot any mistakes, or have proposals for
> improvement, I would love to hear it! I would especially love from
> maintainers of complicated packages such as libreoffice-l10n, if there
> is any additional functionality that we could include in this eclass
> to make their job simpler.
>
> 1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.

Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.

for locale in ${PLOCALES}; do
if use linguas_${locale}; then
enabled_locales+=" ${locale}"
else
disabled_locales+=" ${locale}"
fi
done

First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.

RFC: l10n.eclass
 

On 19 July 2012 21:14, Ralph Sennhauser <sera@gentoo.org> wrote:
>
> I assume the P in PLOCALS stands for package. Not that obvious if you
> ask me. L10N_LOCALS would at least tell me which eclass this variable
> belongs to.

Yes, as P is widely used to refer to the package. I wanted something to
reflect that these are the locales offered by the package.

> Instead of using LINGUAS you should make use of the use function to get
> your cross sections. ie.
>
> for locale in ${PLOCALES}; do
> if use linguas_${locale}; then
> enabled_locales+=" ${locale}"
> else
> disabled_locales+=" ${locale}"
> fi
> done
>
> First, this is guaranteed by PMS and so independent of package manager
> and second, you do not have to care about locales in LINGUAS which are
> invalid for the package. Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

This is a good suggestion, as it makes things simpler and more along
expected lines.

I got a few more suggestions on IRC, and I have updated the eclass
accordingly. Please check the attached new version, also available at
https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

RFC: l10n.eclass
 

On Thu, 19 Jul 2012 15:14:22 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:
> First, this is guaranteed by PMS and so independent of package manager
> and second, you do not have to care about locales in LINGUAS which are
> invalid for the package. Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

With EAPI 5, LINGUAS will be intersected with IUSE (but with the
linguas_ bit stripped off).

--
Ciaran McCreesh

RFC: l10n.eclass
 

On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

Portage does sanitize it if there are any linguas_* flags in IUSE,
otherwise it lets the variable pass through without sanitizing it.
--
Thanks,
Zac

RFC: l10n.eclass
 

On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> Could be that Portage re-exports a sanitized
>> LINGUAS tough, but I doubt it.
>
> Portage does sanitize it if there are any linguas_* flags in IUSE,
> otherwise it lets the variable pass through without sanitizing it.

That's good; we definitely don't want to "sanitize" it if there are no
linuguas_* flags in IUSE. This would break LINUGUAS support for many
autotools/gettext based packages, where the autotools code parses
LINGUAS directly and the ebuild does nothing with it.

RFC: l10n.eclass
 

On Thu, Jul 19, 2012 at 2:45 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
>

In a previous thread, I proposed that the linguas_* use flags should
default to enabled (IUSE="+linguas_en_US ...").

This would cause LINGUAS use-expand behavior to more closely mimic the
behavior of the gettext autoconf macros (/usr/share/aclocal/po.m4).

If LINGUAS is unset, all translations are installed.
If LINGUAS is set a subset of translations are install.
If LINGUAS is set to the empty string, no translations are installed.

RFC: l10n.eclass
 

On Thu, 19 Jul 2012 18:34:41 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
> wrote:
> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> >> Could be that Portage re-exports a sanitized
> >> LINGUAS tough, but I doubt it.
> >
> > Portage does sanitize it if there are any linguas_* flags in IUSE,
> > otherwise it lets the variable pass through without sanitizing it.
>
> That's good; we definitely don't want to "sanitize" it if there are no
> linuguas_* flags in IUSE. This would break LINUGUAS support for many
> autotools/gettext based packages, where the autotools code parses
> LINGUAS directly and the ebuild does nothing with it.

If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
and will be in future EAPIs. Without that, USE dependencies on
USE_EXPAND variables don't work.

--
Ciaran McCreesh

RFC: l10n.eclass
 

On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> I got a few more suggestions on IRC, and I have updated the eclass
> accordingly. Please check the attached new version, also available at
> https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

Pseudo inlining

> # Add linguas useflags
> if [[ -n "${PLOCALES}" ]]; then
> for u in ${PLOCALES}; do
> IUSE+=" linguas_${u}"
> done
> fi

no need to guard the loop against empty $PLOCALES.

> l10n_for_each_locale_do() {
> local locs x
> locs=$(l10n_get_locales)
> if [[ -n "${locs}" ]]; then
> for x in ${locs}; do
> ${@} ${x} || die "failed to process enabled
> ${x} locale" done
> fi
> }

same here, no guarding required and "${@}" should be quoted as it may
contain args with spaces. Also in l10n_for_each_disabled_locale_do.

> # ones. This function is normally used internally in this eclass, not
> by # l10n.eclass consumers.
> l10n_get_locales() {

I'd mark this function @INTERNAL then, at least until someone can
presents a use case.
If you are sufficiently sure this function shouldn't be used by
consumers you could remove the function in favour of 'use linguas_${x}
|| continue' in l10n_for_each_locale_do resp 'use linguas_${x}
&& continue' in l10n_for_each_disabled_locale_do.

RFC: l10n.eclass
 

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> wrote:
>> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> Could be that Portage re-exports a sanitized
>> >> LINGUAS tough, but I doubt it.
>> >
>> > Portage does sanitize it if there are any linguas_* flags in IUSE,
>> > otherwise it lets the variable pass through without sanitizing it.
>>
>> That's good; we definitely don't want to "sanitize" it if there are no
>> linuguas_* flags in IUSE. This would break LINUGUAS support for many
>> autotools/gettext based packages, where the autotools code parses
>> LINGUAS directly and the ebuild does nothing with it.
>
> If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
> and will be in future EAPIs. Without that, USE dependencies on
> USE_EXPAND variables don't work.

How do you figure that?

The current portage behavior works well enough; if linugas_* is in
IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
fine.

Otherwise, it is treated just like a normal environment variable, and
portage doesn't touch it.

For most gettext packages, there is absolutely no reason that the
ebuild maintainer should have to keep track of every translation
available in a given package across version bumps. If you change this
behavior in a future EAPI, you will break this.