Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 06 Jun 2016, Mart Raudsepp wrote:

> First draft of news item for proceeding with LINGUAS USE_EXPAND rename
> to L10N independently of the INSTALL_MASK feature additions.

> I hope English natives will improve the sentence flow and grammar here
> :)
> Perhaps there's also a better title than with the technical USE_EXPAND
> mention.

Since I've seen no objections against using BCP 47 (aka IETF language
tags) for L10N, find my attempt of an updated wording below.

Ulrich


Title: L10N USE_EXPAND variable replacing LINGUAS
Author: Mart Raudsepp 
Author: Ulrich Müller 
Content-Type: text/plain
Posted: 2016-06-19
Revision: 1
News-Item-Format: 1.0

The L10N variable is replacing LINGUAS as an USE_EXPAND, to avoid a
conceptual clash with the standard gettext LINGUAS behaviour.

L10N controls which extra localization support will be installed.
This is commonly used for downloads of additional language packs.

If you have set LINGUAS in your make.conf, you most likely want to add
its entries also to L10N. Note that while the common two letter language
codes (like "de" or "fr") are identical, more complex entries have a
different syntax because L10N now uses IETF language tags. (For example,
"pt_BR" becomes "pt-BR" and "sr@latin" becomes "sr-Latn".) You can look
up the available codes in profiles/desc/l10n.desc in the gentoo tree.
A detailed description of language tags (aka BCP 47) can be found at: 
https://www.w3.org/International/articles/language-tags/

After a transition time for packages to be converted, the LINGUAS
environment variable will maintain the standard gettext behaviour and
will work as expected with all package managers. It controls which
language translations are built and installed. An unset value means all
available, an empty value means none, and a value can be an unordered
list of gettext language codes, with or without territory codes. Usually
two letter language codes suffice, but can be narrowed down by territory
codes with a "ll_CC" formatting, where "ll" is the language code and
"CC" is the territory code, e.g., "en_GB". Some rare languages also have
three letter language codes. Note that LINGUAS does not only affect
installed gettext catalog files (*.mo), but also lines of translations
in an always shipped file (e.g., *.desktop).

If you want English with a set LINGUAS, it is suggested to list it with
the desired country code, in case the default is not the usual "en_US".
It is also common to list "en" then, in case a package is natively
written in a different language, but does provide an English translation
for whichever country. A list of LINGUAS language codes is available at:
http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes

If you have per-package customizations of the LINGUAS USE_EXPAND, you
should also rename those. This typically means changing linguas_* to
l10n_*, and possibly updating the syntax as described above.

https://wiki.gentoo.org/wiki/Localization/Guide has also been updated to
reflect this change.


pgpObTv_cg_aO.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 13 Jun 2016, Mart Raudsepp wrote:

> This was just my random set of thoughts, so Ulrich knows them while
> writing a new version of the news item tomorrow ;)

Yeah, sorry, but I haven't found the time yet. I was wondering though,
maybe we should have two news items? One now, announcing L10N and
outlining that the plan is to retire LINGUAS (as a USE_EXPAND) after a
transition period. The second item could be send when the transition
is complete, and could explain behaviour of LINGUAS as a gettext
variable.

Ulrich


pgppetIbNjZG6.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Mart Raudsepp]

Ühel kenal päeval, T, 07.06.2016 kell 20:28, kirjutas Michał Górny:
> 
> So here's how I would word it. I think if we combine a few different
> texts, we may end up with something good ;-).
> 
> ---
> The LINGUAS USE flag group has been renamed to L10N, in order to
> avoid
> a conceptual clash between the Gentoo use of the name, and a standard
> environment variable used by multiple gettext-based packages. 

Where "multiple" is pretty much the whole tree of autoconf based
packages (and probably cmake too?). Pretty much anything that has a
translation :)

> Therefore,
> from now on filtering localizations is supported on three independent
> levels: L10N, LINGUAS and INSTALL_MASK.
> 
> The L10N flags affect built and installed localizations of the
> packages
> listing those flags explicitly. They are fully controlled by
> the package manager, and their values are defined globally. They do
> not
> affect the packages not listing them explicitly.
> 
> The LINGUAS variable is now verbosely passed through to the build
> system.

If we have a transition phase for the USE_EXPAND, where we'll have both
for a while, then this is not strictly true immediately. It also means
we can't roll out your portage changes to stop the special casing
before we are finished with the transition and LINGUAS is removed from
the USE_EXPAND set.


> It controls the localizations built and installed by packages
> that use it, and that do not override it using L10N flags.

Packages should not be exporting some LINGUAS values based on L10N
USE_EXPAND anyways in my opinion; I'd make such approach a QA violation
maybe even, though we have some odd cases in a very limited set of
packages, iirc.

> Note that
> due to the design, the localization stripping is done implicitly
> and the package manager can not determine which localizations were
> actually provided.


> Additionally, the INSTALL_MASK improvements available in Portage
> 2.3.0
> make it possible to filter localizations at package merge stage. In
> this
> case, the filtering is done on installed directories transparently,
> and the build process and binary packages are not affected.

So I take it that these install_mask groups are in for upcoming 2.3.0.
Before that, you can still do it though, just need to list paths
manually yourself.
Info on what groups are pre-shipped or whatnot would have to be on the
wiki page then, I suppose.

> If you were using LINGUAS before, you most likely want to replace it
> with L10N. If you need to strip localizations more (e.g. for embedded
> systems), you may also want to set LINGUAS and/or INSTALL_MASK.
> However, if you intend to provide or use binary package, you will
> most

I don't like this shunning of LINGUAS feature and shunning to some sort
of embedded systems use case still.
Most of us build systems used by only ourselves, I believe, and there
is nothing wrong in getting a gettext feature applied for free, which
reduces translation lines in .desktop, .schema and other files, and
reduces the runtime mmap caches of those with it for free.
It being clear in the appropriate place that this is a build time thing
and whatnot is of course quite fine.

If we go with BCP47, then users will want to revise their values based
on the available options in the new l10n.desc I suppose.

> likely want to leave L10N and LINGUAS unset in order to build most
> portable binary packages, and use INSTALL_MASK to transparently strip
> installed localizations on the hosts using them.

L10N unset would mean no language packs at all, unless we have a wide
default set in base profile. So unless we set a default set of all of
them in profile, this would mean opposite behavior for L10N and LINGUAS
when unset.

> For more information, please see:
> https://wiki.gentoo.org/wiki/Localization/Guide
> ---
> 
> Of course, we'd need to update the guide to explain all three layers
> in detail.


This was just my random set of thoughts, so Ulrich knows them while
writing a new version of the news item tomorrow ;)


Mart

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:

POSIX.1-2008[2] as you mentioned defines a slightly different format
for locales



language[_territory][.codeset]



Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and
LC_TIME additionally accept specification of a modifier.



[language[_territory][.codeset][@modifier]]



Where territory is implementation defined and the modifier
"select[s] a specific instance of localization data within a single
category". Which I think does not match what we want with "valencia"
variant of the "ca" language.


As I understand it:

1. Gettext documentation says that locale names can be LL_CC or
LL_CC@VARIANT. The natural mapping to the (implementation defined)
format mentioned by POSIX seems to be that LL, CC, and VARIANT
correspond to language, territory, and modifier, respectively.

2. Language codes are taken from ISO 639, namely the two-letter code
if one exists, otherwise the three-letter code.


Yes.


3. Territory codes are taken from ISO 3166-1, usually the two-letter
country codes.


Yes.


4. According to Gettext documentation, "'@VARIANT' can denote any kind
of characteristics that is not already implied by the language LL and
the country CC." (So IIUC the BCP-47 variant "valencia" would become
"@valencia".)


This I think is wrong and collides with POSIX.
POSIX modifiers are not allowed for LANG or LC_ALL in POSIX.1-2008[1]
Section 8.2 says you can have at most one modifier field to "select a 
specific instance of localization data within a single category", which I 
don't think applies because it is its own locale, not an instance of an 
existing one. Furthermore (but that doesn't apply in our use case), POSIX 
spec lists the example

LC_COLLATE=De_DE@dict
So what if you want Catalan Valencian with dictionary order? Or if someone 
hypothetically came up with a different script?



Hence I think POSIX locale cannot handle Catalan Valencian, unless
territory is made accept ISO3166-2 region subdivisions.


I haven't found any mention or usage of ISO 3166-2 region subdivisions
in the context of locale. Can you provide any references for this?


As I wrote before, it is not used. But I think it is the only spec-compliant 
way to marry POSIX locales with Catalan Valencian. BCP-47 does it in a more 
natural way.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Michał Górny]

On Mon, 06 Jun 2016 03:22:34 +0300
Mart Raudsepp  wrote:

> First draft of news item for proceeding with LINGUAS USE_EXPAND rename
> to L10N independently of the INSTALL_MASK feature additions.
> 
> I hope English natives will improve the sentence flow and grammar here
> :)
> Perhaps there's also a better title than with the technical USE_EXPAND
> mention.
> 
> 
> Title: LINGUAS USE_EXPAND renamed to L10N
> Author: Mart Raudsepp 
> Content-Type: text/plain
> Posted: 2016-06-06
> Revision: 1
> News-Item-Format: 1.0
> 
> The LINGUAS USE_EXPAND has been renamed to L10N, to avoid a conceptual
> clash with the standard gettext LINGUAS behaviour.
> L10N controls which extra localization support will be installed.
> This is usually used in case of extra downloads of language packs.
> 
> If you have set LINGUAS in your make.conf, you should either copy or
> rename it to L10N, depending on if you want to filter the supported
> languages at build time or not via the gettext LINGUAS environment
> variable behaviour as described below. Note that this filtering does not
> affect only installed gettext catalog files (*.mo), but also lines of
> translations in an always shipped file (e.g *.desktop).
> 
> LINGUAS maintains the standard gettext behaviour and will now work as
> expected with all package managers. It controls which language
> translations are built and installed. An unset value means all
> available, an empty value means none, and a value can be an unordered
> list of gettext language codes, with or without country codes.
> Usually only two letter language codes suffice, but can be limited with
> country codes with a 'll_CC' formatting, where 'll' is the language code
> and 'CC' is the country code, e.g en_GB. Some rare languages also have
> three letter language codes.
> If you want English with a set LINGUAS, it is suggested to list it with
> the desired country code, in case the default is not the usual en_US.
> It is also common to list "en" then, in case a package is natively
> written in a different language, but does provide an English translation
> for whichever country.
> A list of LINGUAS language codes is available at
> http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes
> 
> Note that LINGUAS affects build time, and thus filters what ends up
> in binary packages. If you are building generic binary packages that
> should support all available language, you should not set LINGUAS.
> 
> If you have per-package customizations of LINGUAS USE_EXPAND, you
> should also rename those from LINGUAS to L10N. This typically means
> renaming linguas_* to l10n_*.
> 
> https://wiki.gentoo.org/wiki/Localization/Guide has also been updated
> to reflect this change.

So here's how I would word it. I think if we combine a few different
texts, we may end up with something good ;-).

---
The LINGUAS USE flag group has been renamed to L10N, in order to avoid
a conceptual clash between the Gentoo use of the name, and a standard
environment variable used by multiple gettext-based packages. Therefore,
from now on filtering localizations is supported on three independent
levels: L10N, LINGUAS and INSTALL_MASK.

The L10N flags affect built and installed localizations of the packages
listing those flags explicitly. They are fully controlled by
the package manager, and their values are defined globally. They do not
affect the packages not listing them explicitly.

The LINGUAS variable is now verbosely passed through to the build
system. It controls the localizations built and installed by packages
that use it, and that do not override it using L10N flags. Note that
due to the design, the localization stripping is done implicitly
and the package manager can not determine which localizations were
actually provided.

Additionally, the INSTALL_MASK improvements available in Portage 2.3.0
make it possible to filter localizations at package merge stage. In this
case, the filtering is done on installed directories transparently,
and the build process and binary packages are not affected.

If you were using LINGUAS before, you most likely want to replace it
with L10N. If you need to strip localizations more (e.g. for embedded
systems), you may also want to set LINGUAS and/or INSTALL_MASK.
However, if you intend to provide or use binary package, you will most
likely want to leave L10N and LINGUAS unset in order to build most
portable binary packages, and use INSTALL_MASK to transparently strip
installed localizations on the hosts using them.

For more information, please see:
https://wiki.gentoo.org/wiki/Localization/Guide
---

Of course, we'd need to update the guide to explain all three layers
in detail.

-- 
Best regards,
Michał Górny



pgpAp60cT4I1J.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 6 Jun 2016, Ulrich Mueller wrote:

> On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:
>> I'm not totally convinced yet.
>> Following the BCP-47 spec the format is

>> Language-Tag  = langtag ; normal language tags
>> langtag   = language
>> ["-" script]
>> ["-" region]
>> *("-" variant)
>> *("-" extension)
>> ["-" privateuse]

>> [...]

> As I understand it:

> 1. Gettext documentation says that locale names can be LL_CC or
> LL_CC@VARIANT. The natural mapping to the (implementation defined)
> format mentioned by POSIX seems to be that LL, CC, and VARIANT
> correspond to language, territory, and modifier, respectively.

> 2. Language codes are taken from ISO 639, namely the two-letter code
> if one exists, otherwise the three-letter code.

> 3. Territory codes are taken from ISO 3166-1, usually the two-letter
> country codes.

> 4. According to Gettext documentation, "'@VARIANT' can denote any
> kind of characteristics that is not already implied by the language
> LL and the country CC." (So IIUC the BCP-47 variant "valencia" would
> become "@valencia".)

Of course, we could also say that Gettext/POSIX syntax (especially its
variant/modifier part) is ill-defined, and use BCP-47 syntax for the
L10N USE_EXPAND instead (except that the separator would be an
underscore instead of a hyphen).

AFAICS, there would be no change at all for any of the LL or LL_CC
entries. The only ones that would change would be the (about 10) ones
containing an @ sign. For example, ca@valencia would become
ca_valencia, and sr@ijekavianlatin would become sr_Latn_ijekavsk.

Not sure how much additional code for remapping would be required.
However, my impression is that upstream usage of @VARIANT is not at
all standardised, so some remapping would be required in any case if
we want unique entries for L10N.

Ulrich


pgpX6YOzUkd3k.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:

> I'm not totally convinced yet.
> Following the BCP-47 spec the format is

> Language-Tag  = langtag ; normal language tags
> langtag   = language
>   ["-" script]
>   ["-" region]
>   *("-" variant)
>   *("-" extension)
>   ["-" privateuse]

> So using the language ca, region es, and variant valencia, the
> BCP-47 language tag is ca-es-valencia (or ca-valencia if you omit
> the region).

Right. Or rather, ca-ES-valencia for the former, because all caps are
preferred for the region tag.

> POSIX.1-2008[2] as you mentioned defines a slightly different format
> for locales

> language[_territory][.codeset]

> Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and 
> LC_TIME additionally accept specification of a modifier.

> [language[_territory][.codeset][@modifier]]

> Where territory is implementation defined and the modifier
> "select[s] a specific instance of localization data within a single
> category". Which I think does not match what we want with "valencia"
> variant of the "ca" language.

As I understand it:

1. Gettext documentation says that locale names can be LL_CC or
LL_CC@VARIANT. The natural mapping to the (implementation defined)
format mentioned by POSIX seems to be that LL, CC, and VARIANT
correspond to language, territory, and modifier, respectively.

2. Language codes are taken from ISO 639, namely the two-letter code
if one exists, otherwise the three-letter code.

3. Territory codes are taken from ISO 3166-1, usually the two-letter
country codes.

4. According to Gettext documentation, "'@VARIANT' can denote any kind
of characteristics that is not already implied by the language LL and
the country CC." (So IIUC the BCP-47 variant "valencia" would become
"@valencia".)

> Hence I think POSIX locale cannot handle Catalan Valencian, unless
> territory is made accept ISO3166-2 region subdivisions.

I haven't found any mention or usage of ISO 3166-2 region subdivisions
in the context of locale. Can you provide any references for this?

Ulrich


pgpqOl6MMcnlA.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:

On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:

Ulrich Mueller schrieb:

Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some
don't.

What do we do with locales that don't fit into this scheme? Catalan
Valencian is one such locale.
Packages currently use modifiers (ca@valencia) or ISO 3166-1
reserved area (ca_XV) or something entirely different (ca_valencia).

According to [1], "valencia" is a valid variant subtag, therefore
ca@valencia should be fine.


ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would
be best. Though a quick Google search didn't find any major usage of
that either.

Neither XV nor ES-VC are registered as a subtag though, so presumably
these should be avoided.


I'm not totally convinced yet.
Following the BCP-47 spec the format is

Language-Tag  = langtag ; normal language tags
langtag   = language
 ["-" script]
 ["-" region]
 *("-" variant)
 *("-" extension)
 ["-" privateuse]

So using the language ca, region es, and variant valencia, the BCP-47 
language tag is ca-es-valencia (or ca-valencia if you omit the region).


POSIX.1-2008[2] as you mentioned defines a slightly different format for 
locales


language[_territory][.codeset]

Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and 
LC_TIME additionally accept specification of a modifier.


[language[_territory][.codeset][@modifier]]

Where territory is implementation defined and the modifier "select[s] a 
specific instance of localization data within a single category". Which 
I think does not match what we want with "valencia" variant of the "ca" 
language.


Hence I think POSIX locale cannot handle Catalan Valencian, unless 
territory is made accept ISO3166-2 region subdivisions.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://tools.ietf.org/rfc/bcp/bcp47.txt
[2] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:

> Ulrich Mueller schrieb:
>> Question related to this, do we take the opportunity to standardise
>> the values? Looks like the vast majority follows
>> language[_territory][@modifier] specified by POSIX [1] but some
>> don't.

> What do we do with locales that don't fit into this scheme? Catalan
> Valencian is one such locale.
> Packages currently use modifiers (ca@valencia) or ISO 3166-1
> reserved area (ca_XV) or something entirely different (ca_valencia).

According to [1], "valencia" is a valid variant subtag, therefore
ca@valencia should be fine.

> ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would
> be best. Though a quick Google search didn't find any major usage of
> that either.

Neither XV nor ES-VC are registered as a subtag though, so presumably
these should be avoided.

Ulrich

[1] 
http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry


pgp4kuUvSb3by.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:

On Mon, 06 Jun 2016, Mart Raudsepp wrote:



Usually only two letter language codes suffice, but can be limited with
country codes with a 'll_CC' formatting, where 'll' is the language code
and 'CC' is the country code, e.g en_GB. Some rare languages also have
three letter language codes.


s/country code/territory code/g

Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some don't.


What do we do with locales that don't fit into this scheme? Catalan Valencian 
is one such locale.
Packages currently use modifiers (ca@valencia) or ISO 3166-1 reserved area 
(ca_XV) or something entirely different (ca_valencia).
ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would be best. 
Though a quick Google search didn't find any major usage of that either.



Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Ulrich Mueller]

> On Mon, 06 Jun 2016, Mart Raudsepp wrote:

> Usually only two letter language codes suffice, but can be limited with
> country codes with a 'll_CC' formatting, where 'll' is the language code
> and 'CC' is the country code, e.g en_GB. Some rare languages also have
> three letter language codes.

s/country code/territory code/g

Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some don't.

Also there are a few duplicates, like sr@Latn / sr@latin and uz@Cyrl /
uz@cyrillic. I suggest that we adhere to the BCP 47 [2] names if
possible (which would be Latn and Cyrl for the examples mentioned).

Ulrich


[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
[2] http://www.rfc-editor.org/rfc/bcp/bcp47.txt


pgpB_tZMQVJkR.pgp
Description: PGP signature

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Michał Górny]

On Mon, 06 Jun 2016 03:22:34 +0300
Mart Raudsepp  wrote:

> First draft of news item for proceeding with LINGUAS USE_EXPAND rename
> to L10N independently of the INSTALL_MASK feature additions.
> 
> I hope English natives will improve the sentence flow and grammar here
> :)
> Perhaps there's also a better title than with the technical USE_EXPAND
> mention.
> 
> 
> Title: LINGUAS USE_EXPAND renamed to L10N
> Author: Mart Raudsepp 
> Content-Type: text/plain
> Posted: 2016-06-06
> Revision: 1
> News-Item-Format: 1.0
> 
> The LINGUAS USE_EXPAND has been renamed to L10N, to avoid a conceptual
> clash with the standard gettext LINGUAS behaviour.
> L10N controls which extra localization support will be installed.
> This is usually used in case of extra downloads of language packs.
> 
> If you have set LINGUAS in your make.conf, you should either copy or
> rename it to L10N, depending on if you want to filter the supported
> languages at build time or not via the gettext LINGUAS environment
> variable behaviour as described below. Note that this filtering does not
> affect only installed gettext catalog files (*.mo), but also lines of
> translations in an always shipped file (e.g *.desktop).
> 
> LINGUAS maintains the standard gettext behaviour and will now work as
> expected with all package managers. It controls which language
> translations are built and installed. An unset value means all
> available, an empty value means none, and a value can be an unordered
> list of gettext language codes, with or without country codes.
> Usually only two letter language codes suffice, but can be limited with
> country codes with a 'll_CC' formatting, where 'll' is the language code
> and 'CC' is the country code, e.g en_GB. Some rare languages also have
> three letter language codes.
> If you want English with a set LINGUAS, it is suggested to list it with
> the desired country code, in case the default is not the usual en_US.
> It is also common to list "en" then, in case a package is natively
> written in a different language, but does provide an English translation
> for whichever country.
> A list of LINGUAS language codes is available at
> http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes
> 
> Note that LINGUAS affects build time, and thus filters what ends up
> in binary packages. If you are building generic binary packages that
> should support all available language, you should not set LINGUAS.

After such a long explanation of how LINGUAS works, you almost
naturally except explanation of what goes into L10N and how it works.

And while at it, you might also give a little suggestion that with new
enough Portage you can do exclusive INSTALL_MASK and how it does not
affect binary packages.

> If you have per-package customizations of LINGUAS USE_EXPAND, you
> should also rename those from LINGUAS to L10N. This typically means
> renaming linguas_* to l10n_*.
> 
> https://wiki.gentoo.org/wiki/Localization/Guide has also been updated
> to reflect this change.

...or alternatively, reduce the news item to a paragraph on each,
and direct to wiki (and info gettext) for more detailed explanations.

-- 
Best regards,
Michał Górny



pgpTYPZP7LUd9.pgp
Description: OpenPGP digital signature