Re: [gentoo-user] LINGUAS make.conf variable being ignored?

[Mart Raudsepp]

On Fri, 2018-01-05 at 18:53 +, Grant Edwards wrote:
> I haven't changed LINGUAS or L10N for ages, but I've noticed that
> suddely other packages are being rebuild without linguas_en and
> linguas_en_us.
> 
> Is make.conf's LINGUAS variable no longer being expanded?

Correct.
See https://bugs.gentoo.org/643598
and maybe https://bugs.gentoo.org/643682#c1 for a more technically
explained temporary workaround to not lose language during this
(hopefully rather short) final transition period.

> How do you show the complete set of use flags including expanded
> ones?

LINGUAS is not expanded anymore.

Re: [gentoo-user] LINGUAS make.conf variable being ignored?

[Dale]

On 01/05/2018 12:53 PM, Grant Edwards wrote:

I tried to update today using my normal "emerge --sync; emerge -auvND
world" sequence and it's failing when it gets to iso-codes:


Emerging (1 of 1) app-text/iso-codes-3.75::gentoo

  * iso-codes-3.75.tar.xz BLAKE2B SHA512 size ;-) ...   
  [ ok ]

Unpacking source...
Unpacking iso-codes-3.75.tar.xz to /var/tmp/portage/app-text/iso-codes-3.75/work
Source unpacked in /var/tmp/portage/app-text/iso-codes-3.75/work
Preparing source in 
/var/tmp/portage/app-text/iso-codes-3.75/work/iso-codes-3.75 ...

  * Looking for new locales ... 
  [ ok ]
  * Preparing iso_15924 ...
  * ERROR: app-text/iso-codes-3.75::gentoo failed (prepare phase):
  *   USE Flag 'linguas_ar' not in IUSE for app-text/iso-codes-3.75
  *
  * Call stack:
  *  ebuild.sh, line  124:  Called src_prepare
  *environment, line 3054:  Called use 'linguas_ar'
  *   phase-helpers.sh, line  200:  Called die
  * The specific snippet of code:
  * die "USE Flag '${u}' not in IUSE for 
${CATEGORY}/${PF}"

I haven't changed LINGUAS or L10N for ages, but I've noticed that
suddely other packages are being rebuild without linguas_en and
linguas_en_us.

Is make.conf's LINGUAS variable no longer being expanded?

How do you show the complete set of use flags including expanded ones?

euse doesn't seem to show use flags generated from expanded variables.





Is this related:

https://www.gentoo.org/support/news-items/2016-06-23-l10n-use_expand.html

Most recent thread here:

https://archives.gentoo.org/gentoo-dev/message/29b00839ba5be715d883412011d8a421 



Dale

:-)  :-)

[gentoo-user] LINGUAS make.conf variable being ignored?

[Grant Edwards]

I tried to update today using my normal "emerge --sync; emerge -auvND
world" sequence and it's failing when it gets to iso-codes:

>>> Emerging (1 of 1) app-text/iso-codes-3.75::gentoo
 * iso-codes-3.75.tar.xz BLAKE2B SHA512 size ;-) ...
 [ ok ]
>>> Unpacking source...
>>> Unpacking iso-codes-3.75.tar.xz to 
>>> /var/tmp/portage/app-text/iso-codes-3.75/work
>>> Source unpacked in /var/tmp/portage/app-text/iso-codes-3.75/work
>>> Preparing source in 
>>> /var/tmp/portage/app-text/iso-codes-3.75/work/iso-codes-3.75 ...
 * Looking for new locales ...  
 [ ok ]
 * Preparing iso_15924 ...
 * ERROR: app-text/iso-codes-3.75::gentoo failed (prepare phase):
 *   USE Flag 'linguas_ar' not in IUSE for app-text/iso-codes-3.75
 * 
 * Call stack:
 *  ebuild.sh, line  124:  Called src_prepare
 *environment, line 3054:  Called use 'linguas_ar'
 *   phase-helpers.sh, line  200:  Called die
 * The specific snippet of code:
 * die "USE Flag '${u}' not in IUSE for 
${CATEGORY}/${PF}"

I haven't changed LINGUAS or L10N for ages, but I've noticed that
suddely other packages are being rebuild without linguas_en and
linguas_en_us.

Is make.conf's LINGUAS variable no longer being expanded?

How do you show the complete set of use flags including expanded ones?

euse doesn't seem to show use flags generated from expanded variables.

-- 
Grant Edwards   grant.b.edwardsYow! I'm a GENIUS!  I want
  at   to dispute sentence
  gmail.comstructure with SUSAN
   SONTAG!!

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Neil Bothwick wrote:
> On Sat, 25 Jun 2016 09:57:57 -0500, Dale wrote:
>
>>> The point of the news item is not to make it work now, it already
>>> does. The advice is there to help you get your system into a state
>>> where it won't stop working when the next stage of the switch occurs.
>> I get that but that didn't make much sense either.  I ended up using
>> trial and error to get the setting correct since the news item and the
>> link wasn't much help.  About all it did was let me know that there was
>> a change but as to helping understand that change, not much help there
>> if any. 
> It made sense to me. To paraphrase:
>
> Using LINGUAS sucks so we are phasing it out in favour of L10N.
>
> So set L10N to whatever LINGUAS is currently set to, with one change
>
> We are using newer style naming with country codes, so replace _ with -
> in things like en_GB.
>
> That's it. If the odd package wants to rebuild, it's because that package
> had already moved over to use L10N, so the last update would have built
> it with all languages.
>
>

Neil,

Keep in mind, I didn't start this thread.  I'm not the only one who read
the news item and it not make good sense.  I might add, I followed some
of the discussion on -dev and even that didn't help the news item and I
sort of had a general idea of what it was about.  If I wasn't already
somewhat aware of it, that news item wouldn't have been very little help. 

Dale

:-)  :-) 

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Neil Bothwick]

On Sat, 25 Jun 2016 09:57:57 -0500, Dale wrote:

> > The point of the news item is not to make it work now, it already
> > does. The advice is there to help you get your system into a state
> > where it won't stop working when the next stage of the switch occurs.

> I get that but that didn't make much sense either.  I ended up using
> trial and error to get the setting correct since the news item and the
> link wasn't much help.  About all it did was let me know that there was
> a change but as to helping understand that change, not much help there
> if any. 

It made sense to me. To paraphrase:

Using LINGUAS sucks so we are phasing it out in favour of L10N.

So set L10N to whatever LINGUAS is currently set to, with one change

We are using newer style naming with country codes, so replace _ with -
in things like en_GB.

That's it. If the odd package wants to rebuild, it's because that package
had already moved over to use L10N, so the last update would have built
it with all languages.


-- 
Neil Bothwick

Windoze95 Quote: Why is the Pentium 166 so fast? - Its for booting
faster, if Windows crashed again.


pgp2G5GlXtwPi.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Mick wrote:
> On Friday 24 Jun 2016 18:47:11 Dale wrote:
>> Alan McKinnon wrote:
>>> On 24/06/2016 17:40, Dale wrote:
 Peter Humphrey wrote:
> On Friday 24 Jun 2016 09:54:35 Dale wrote:
>> I agree that the news item was confusing.  The guide it linked to
>> wasn't
>> much better either.  In the end, I just fiddled with the setting
>> until I
>> found a setting that didn't change what I already have, in other
>> words,
>> I got a clean emerge -uvaDN world.  My first couple runs wanted to
>> remove things and I knew the setting wasn't right yet.  After it
>> was all
>> done, this is what I ended up with:
>>
>> LINGUAS="en_US en"
>>
>> I left the LANG setting as is for the moment.
> Didn't you set L10N as well? I read the news item as requiring it.
 As I said, the news item and even the guide the news item pointed to
 doesn't explain much.  When I run into a doc that doesn't give me enough
 info, or so much that it doesn't make sense, then I resort of trying
 settings until I get a output that tells me that the setting I tried
 works.  At first, I tried "en" but some packages were going to be
 rebuilt.  Then I tried "en-US" and that caused other packages to want to
 be rebuilt.  Then I put in both and I got what I expected, a clean
 emerge output that showed it wasn't going to change anything from what I
 already had.

 I guess when L10N starts causing packages to build differently, I'll add
 it . As it is, I'm not real sure what if anything it does that
 affects me.
>>> Right now it does nothing, it is only setting the groundwork for
>>> something in the near future.
>>>
>>> LINGUAS in the environment is a really bad idea, GNU gettext uses it
>>> to decide what translated messages to generate, but does it poorly and
>>> packages use it inconsistently. Gentoo uses it to decide what
>>> localization to use, which often includes which language packs to
>>> download and install - something that gettext's LINGUAS never goes near.
>>>
>>> So the choice of name on Gentoo's part is really poor. What really
>>> needs to happen is that a dedicated variable L10N replaces what
>>> LINGUAS does in ebuilds, and when the whole tree is converted LINGUAS
>>> as a USE_EXPAND goes away. What you do right now is do what the news
>>> item says to do which is copy LINGUAS to L10N in make.conf, then it is
>>> done and you can go on your merry way confident that all will be fine.
>>>
>>> Really, it's all there in the news item clear as daylight and
>>> completely unambiguous.
>>>
>>> You fellows really like over-complicating news items and asking way
>>> too many "what if?" questions. Y'all need to knock that crap off now :-)
>> I tried to comment out each one one at a time.  Whenever I do, emerge
>> wants to remove some of the languages, en to be more precise.  I don't
>> know if maybe some ebuilds or something else is a little behind or what
>> but I guess I'll leave it as is until I know it won't change something
>> that I need.  Each way that I try it, it affects different packages.
>>
>> I read the news item and was confused.  I read it again and was even
>> more confused.  After the third time, I didn't see any point in reading
>> it again so I went to the link, hoping it would be better.  Well, not
>> really.  So, I just started messing with it until I got a setting that
>> worked.  Hey, it's in there and it works.  Now the news item and the
>> howto don't matter.  lol
>>
>> Dale
>>
>> :-)  :-)
> Did you read *all* the URLs in the news item?  Even if the URL on language 
> tags and gettext were TL;DR, the last URL pointing you to the gentoo Wiki 
> page 
> on localization should be straight forward to follow.
>

That was actually the one I went to.  I noticed it was the Gentoo wiki
and figured it would be easier to figure out.  Maybe I should have tried
the others looking back with hindsight. 

Dale

:-)  :-) 

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Neil Bothwick wrote:
> On Fri, 24 Jun 2016 18:47:11 -0500, Dale wrote:
>
>> I read the news item and was confused.  I read it again and was even
>> more confused.  After the third time, I didn't see any point in reading
>> it again so I went to the link, hoping it would be better.  Well, not
>> really.  So, I just started messing with it until I got a setting that
>> worked.  Hey, it's in there and it works.  Now the news item and the
>> howto don't matter.  lol 
> The point of the news item is not to make it work now, it already does.
> The advice is there to help you get your system into a state where it
> won't stop working when the next stage of the switch occurs.
>
>

I get that but that didn't make much sense either.  I ended up using
trial and error to get the setting correct since the news item and the
link wasn't much help.  About all it did was let me know that there was
a change but as to helping understand that change, not much help there
if any. 

Dale

:-)  :-)

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Neil Bothwick]

On Fri, 24 Jun 2016 18:47:11 -0500, Dale wrote:

> I read the news item and was confused.  I read it again and was even
> more confused.  After the third time, I didn't see any point in reading
> it again so I went to the link, hoping it would be better.  Well, not
> really.  So, I just started messing with it until I got a setting that
> worked.  Hey, it's in there and it works.  Now the news item and the
> howto don't matter.  lol 

The point of the news item is not to make it work now, it already does.
The advice is there to help you get your system into a state where it
won't stop working when the next stage of the switch occurs.


-- 
Neil Bothwick

Tell me, and I will forget. Show me, and I will remember. Involve me, and
I will learn.


pgpLSgPyDh90R.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Mick]

On Friday 24 Jun 2016 18:47:11 Dale wrote:
> Alan McKinnon wrote:
> > On 24/06/2016 17:40, Dale wrote:
> >> Peter Humphrey wrote:
> >>> On Friday 24 Jun 2016 09:54:35 Dale wrote:
>  I agree that the news item was confusing.  The guide it linked to
>  wasn't
>  much better either.  In the end, I just fiddled with the setting
>  until I
>  found a setting that didn't change what I already have, in other
>  words,
>  I got a clean emerge -uvaDN world.  My first couple runs wanted to
>  remove things and I knew the setting wasn't right yet.  After it
>  was all
>  done, this is what I ended up with:
>  
>  LINGUAS="en_US en"
>  
>  I left the LANG setting as is for the moment.
> >>> 
> >>> Didn't you set L10N as well? I read the news item as requiring it.
> >> 
> >> As I said, the news item and even the guide the news item pointed to
> >> doesn't explain much.  When I run into a doc that doesn't give me enough
> >> info, or so much that it doesn't make sense, then I resort of trying
> >> settings until I get a output that tells me that the setting I tried
> >> works.  At first, I tried "en" but some packages were going to be
> >> rebuilt.  Then I tried "en-US" and that caused other packages to want to
> >> be rebuilt.  Then I put in both and I got what I expected, a clean
> >> emerge output that showed it wasn't going to change anything from what I
> >> already had.
> >> 
> >> I guess when L10N starts causing packages to build differently, I'll add
> >> it . As it is, I'm not real sure what if anything it does that
> >> affects me.
> > 
> > Right now it does nothing, it is only setting the groundwork for
> > something in the near future.
> > 
> > LINGUAS in the environment is a really bad idea, GNU gettext uses it
> > to decide what translated messages to generate, but does it poorly and
> > packages use it inconsistently. Gentoo uses it to decide what
> > localization to use, which often includes which language packs to
> > download and install - something that gettext's LINGUAS never goes near.
> > 
> > So the choice of name on Gentoo's part is really poor. What really
> > needs to happen is that a dedicated variable L10N replaces what
> > LINGUAS does in ebuilds, and when the whole tree is converted LINGUAS
> > as a USE_EXPAND goes away. What you do right now is do what the news
> > item says to do which is copy LINGUAS to L10N in make.conf, then it is
> > done and you can go on your merry way confident that all will be fine.
> > 
> > Really, it's all there in the news item clear as daylight and
> > completely unambiguous.
> > 
> > You fellows really like over-complicating news items and asking way
> > too many "what if?" questions. Y'all need to knock that crap off now :-)
> 
> I tried to comment out each one one at a time.  Whenever I do, emerge
> wants to remove some of the languages, en to be more precise.  I don't
> know if maybe some ebuilds or something else is a little behind or what
> but I guess I'll leave it as is until I know it won't change something
> that I need.  Each way that I try it, it affects different packages.
> 
> I read the news item and was confused.  I read it again and was even
> more confused.  After the third time, I didn't see any point in reading
> it again so I went to the link, hoping it would be better.  Well, not
> really.  So, I just started messing with it until I got a setting that
> worked.  Hey, it's in there and it works.  Now the news item and the
> howto don't matter.  lol
> 
> Dale
> 
> :-)  :-)

Did you read *all* the URLs in the news item?  Even if the URL on language 
tags and gettext were TL;DR, the last URL pointing you to the gentoo Wiki page 
on localization should be straight forward to follow.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Alan McKinnon wrote:
> On 24/06/2016 17:40, Dale wrote:
>> Peter Humphrey wrote:
>>> On Friday 24 Jun 2016 09:54:35 Dale wrote:
>>>
 I agree that the news item was confusing.  The guide it linked to
 wasn't
 much better either.  In the end, I just fiddled with the setting
 until I
 found a setting that didn't change what I already have, in other
 words,
 I got a clean emerge -uvaDN world.  My first couple runs wanted to
 remove things and I knew the setting wasn't right yet.  After it
 was all
 done, this is what I ended up with:

 LINGUAS="en_US en"

 I left the LANG setting as is for the moment.
>>> Didn't you set L10N as well? I read the news item as requiring it.
>>>
>>
>>
>> As I said, the news item and even the guide the news item pointed to
>> doesn't explain much.  When I run into a doc that doesn't give me enough
>> info, or so much that it doesn't make sense, then I resort of trying
>> settings until I get a output that tells me that the setting I tried
>> works.  At first, I tried "en" but some packages were going to be
>> rebuilt.  Then I tried "en-US" and that caused other packages to want to
>> be rebuilt.  Then I put in both and I got what I expected, a clean
>> emerge output that showed it wasn't going to change anything from what I
>> already had.
>>
>> I guess when L10N starts causing packages to build differently, I'll add
>> it . As it is, I'm not real sure what if anything it does that
>> affects me.
>
> Right now it does nothing, it is only setting the groundwork for
> something in the near future.
>
> LINGUAS in the environment is a really bad idea, GNU gettext uses it
> to decide what translated messages to generate, but does it poorly and
> packages use it inconsistently. Gentoo uses it to decide what
> localization to use, which often includes which language packs to
> download and install - something that gettext's LINGUAS never goes near.
>
> So the choice of name on Gentoo's part is really poor. What really
> needs to happen is that a dedicated variable L10N replaces what
> LINGUAS does in ebuilds, and when the whole tree is converted LINGUAS
> as a USE_EXPAND goes away. What you do right now is do what the news
> item says to do which is copy LINGUAS to L10N in make.conf, then it is
> done and you can go on your merry way confident that all will be fine.
>
> Really, it's all there in the news item clear as daylight and
> completely unambiguous.
>
> You fellows really like over-complicating news items and asking way
> too many "what if?" questions. Y'all need to knock that crap off now :-)
>
>
>

I tried to comment out each one one at a time.  Whenever I do, emerge
wants to remove some of the languages, en to be more precise.  I don't
know if maybe some ebuilds or something else is a little behind or what
but I guess I'll leave it as is until I know it won't change something
that I need.  Each way that I try it, it affects different packages. 

I read the news item and was confused.  I read it again and was even
more confused.  After the third time, I didn't see any point in reading
it again so I went to the link, hoping it would be better.  Well, not
really.  So, I just started messing with it until I got a setting that
worked.  Hey, it's in there and it works.  Now the news item and the
howto don't matter.  lol 

Dale

:-)  :-) 

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Peter Humphrey]

On Friday 24 Jun 2016 22:33:38 Alan McKinnon wrote:

> ... all my posts in the last 30 minutes are redundant.

Er...

:-)

-- 
Rgds
Peter

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Alan McKinnon]

On 24/06/2016 20:58, Dale wrote:

Since Alan's post makes more sense to me than the docs, I added the L10N
to make.conf and I got a clean output.  So, that works.  Mine is what
Alan posted.  I guess I'm ready for the future now.;-)




And gmail helpfully delivered half my mail after me being out for 3 
hours, then delivered the other half after I's replied. Meaning all my 
posts in the last 30 minutes are redundant.


Oh the joys of mail :-)

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Alan McKinnon]

On 24/06/2016 22:09, Dale wrote:

allan gottlieb wrote:

On Fri, Jun 24 2016, Alan McKinnon wrote:


On 24/06/2016 16:06, allan gottlieb wrote:

Having read the latest news article and rereading parts of the
localization guide, it is not clear to me what action, if any, I need to
take.

My systems are US English only

/etc/portage/make.conf has
LINGUAS="en"

/etc/local.gen has just comments plus
en_US ISO-8859-1
en_US.UTF-8 UTF-8

Should I add
L10N="en-US"
to /etc/portage/make.conf ?

Should I run local-gen ?

Thanks
allan


Add

L10N="en" to make.conf

Thanks.  Done.  Update world just generated

[ebuild   R] app-text/texlive-2014  L10N="en*"

all seems well.  Thanks again.
allan




While I added what Alan posted, I also had to leave the others.  The
relevant part of my make.conf looks like this:

LANG="en_US"
LC_ALL="en_US.UTF8"
LINGUAS="en_US"
L10N="en en_US"


L10N="en en-US"


local derivatives of languages like en_GB, en_za have been tweaked 
according to the referenced new standard. Mostly it's little more than

s/_/-/g

LINGUAS and L10N must always logically match




I tried to comment out the others but emerge always came back wanting to
remove some language.

YMMV

Dale

:-)  :-)

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Alan McKinnon]

On 24/06/2016 17:40, Dale wrote:

Peter Humphrey wrote:

On Friday 24 Jun 2016 09:54:35 Dale wrote:


I agree that the news item was confusing.  The guide it linked to wasn't
much better either.  In the end, I just fiddled with the setting until I
found a setting that didn't change what I already have, in other words,
I got a clean emerge -uvaDN world.  My first couple runs wanted to
remove things and I knew the setting wasn't right yet.  After it was all
done, this is what I ended up with:

LINGUAS="en_US en"

I left the LANG setting as is for the moment.

Didn't you set L10N as well? I read the news item as requiring it.




As I said, the news item and even the guide the news item pointed to
doesn't explain much.  When I run into a doc that doesn't give me enough
info, or so much that it doesn't make sense, then I resort of trying
settings until I get a output that tells me that the setting I tried
works.  At first, I tried "en" but some packages were going to be
rebuilt.  Then I tried "en-US" and that caused other packages to want to
be rebuilt.  Then I put in both and I got what I expected, a clean
emerge output that showed it wasn't going to change anything from what I
already had.

I guess when L10N starts causing packages to build differently, I'll add
it . As it is, I'm not real sure what if anything it does that affects me.


Right now it does nothing, it is only setting the groundwork for 
something in the near future.


LINGUAS in the environment is a really bad idea, GNU gettext uses it to 
decide what translated messages to generate, but does it poorly and 
packages use it inconsistently. Gentoo uses it to decide what 
localization to use, which often includes which language packs to 
download and install - something that gettext's LINGUAS never goes near.


So the choice of name on Gentoo's part is really poor. What really needs 
to happen is that a dedicated variable L10N replaces what LINGUAS does 
in ebuilds, and when the whole tree is converted LINGUAS as a USE_EXPAND 
goes away. What you do right now is do what the news item says to do 
which is copy LINGUAS to L10N in make.conf, then it is done and you can 
go on your merry way confident that all will be fine.


Really, it's all there in the news item clear as daylight and completely 
unambiguous.


You fellows really like over-complicating news items and asking way too 
many "what if?" questions. Y'all need to knock that crap off now :-)

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

allan gottlieb wrote:
> On Fri, Jun 24 2016, Alan McKinnon wrote:
>
>> On 24/06/2016 16:06, allan gottlieb wrote:
>>> Having read the latest news article and rereading parts of the
>>> localization guide, it is not clear to me what action, if any, I need to
>>> take.
>>>
>>> My systems are US English only
>>>
>>> /etc/portage/make.conf has
>>>LINGUAS="en"
>>>
>>> /etc/local.gen has just comments plus
>>>en_US ISO-8859-1
>>>en_US.UTF-8 UTF-8
>>>
>>> Should I add
>>>L10N="en-US"
>>> to /etc/portage/make.conf ?
>>>
>>> Should I run local-gen ?
>>>
>>> Thanks
>>> allan
>>>
>> Add
>>
>> L10N="en" to make.conf
> Thanks.  Done.  Update world just generated
>
>[ebuild   R] app-text/texlive-2014  L10N="en*" 
>
> all seems well.  Thanks again.
> allan
>
>

While I added what Alan posted, I also had to leave the others.  The
relevant part of my make.conf looks like this:

LANG="en_US"
LC_ALL="en_US.UTF8"
LINGUAS="en_US"
L10N="en en_US"

I tried to comment out the others but emerge always came back wanting to
remove some language. 

YMMV

Dale

:-)  :-) 

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Alan McKinnon wrote:
> On 24/06/2016 16:06, allan gottlieb wrote:
>> Having read the latest news article and rereading parts of the
>> localization guide, it is not clear to me what action, if any, I need to
>> take.
>>
>> My systems are US English only
>>
>> /etc/portage/make.conf has
>>LINGUAS="en"
>>
>> /etc/local.gen has just comments plus
>>en_US ISO-8859-1
>>en_US.UTF-8 UTF-8
>>
>> Should I add
>>L10N="en-US"
>> to /etc/portage/make.conf ?
>>
>> Should I run local-gen ?
>>
>> Thanks
>> allan
>>
> Add
>
> L10N="en" to make.conf
>
> "en" has no tweaks to be made to the new naming style so that's all you
> do. Other folks who use, for example, Brazilian Portuguese, will need to
> make tweaks and look up the correct value in the file the news item
> references.
>
> For now LINGUAS and L10N will work in parallel and the devs will do the
> heavy lifting. For the moment all changes will be light touch, the big
> tasks will happen later.
>
> One day you will need to remove LINGUAS from make.conf entirely, but
> that day is not today.
>
> And all of this is necessary because making a USE_EXPAND env var called
> LINGUAS was a really stupid idea from day one.
>
>

Since Alan's post makes more sense to me than the docs, I added the L10N
to make.conf and I got a clean output.  So, that works.  Mine is what
Alan posted.  I guess I'm ready for the future now.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[allan gottlieb]

On Fri, Jun 24 2016, Alan McKinnon wrote:

> On 24/06/2016 16:06, allan gottlieb wrote:
>> Having read the latest news article and rereading parts of the
>> localization guide, it is not clear to me what action, if any, I need to
>> take.
>> 
>> My systems are US English only
>> 
>> /etc/portage/make.conf has
>>LINGUAS="en"
>> 
>> /etc/local.gen has just comments plus
>>en_US ISO-8859-1
>>en_US.UTF-8 UTF-8
>> 
>> Should I add
>>L10N="en-US"
>> to /etc/portage/make.conf ?
>> 
>> Should I run local-gen ?
>> 
>> Thanks
>> allan
>> 
>
> Add
>
> L10N="en" to make.conf

Thanks.  Done.  Update world just generated

   [ebuild   R] app-text/texlive-2014  L10N="en*" 

all seems well.  Thanks again.
allan

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

Peter Humphrey wrote:
> On Friday 24 Jun 2016 09:54:35 Dale wrote:
>
>> I agree that the news item was confusing.  The guide it linked to wasn't
>> much better either.  In the end, I just fiddled with the setting until I
>> found a setting that didn't change what I already have, in other words,
>> I got a clean emerge -uvaDN world.  My first couple runs wanted to
>> remove things and I knew the setting wasn't right yet.  After it was all
>> done, this is what I ended up with:
>>
>> LINGUAS="en_US en"
>>
>> I left the LANG setting as is for the moment.
> Didn't you set L10N as well? I read the news item as requiring it.
>


As I said, the news item and even the guide the news item pointed to
doesn't explain much.  When I run into a doc that doesn't give me enough
info, or so much that it doesn't make sense, then I resort of trying
settings until I get a output that tells me that the setting I tried
works.  At first, I tried "en" but some packages were going to be
rebuilt.  Then I tried "en-US" and that caused other packages to want to
be rebuilt.  Then I put in both and I got what I expected, a clean
emerge output that showed it wasn't going to change anything from what I
already had. 

I guess when L10N starts causing packages to build differently, I'll add
it . As it is, I'm not real sure what if anything it does that affects me. 

Dale

:-)  :-) 

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Alan McKinnon]

On 24/06/2016 16:06, allan gottlieb wrote:
> Having read the latest news article and rereading parts of the
> localization guide, it is not clear to me what action, if any, I need to
> take.
> 
> My systems are US English only
> 
> /etc/portage/make.conf has
>LINGUAS="en"
> 
> /etc/local.gen has just comments plus
>en_US ISO-8859-1
>en_US.UTF-8 UTF-8
> 
> Should I add
>L10N="en-US"
> to /etc/portage/make.conf ?
> 
> Should I run local-gen ?
> 
> Thanks
> allan
> 

Add

L10N="en" to make.conf

"en" has no tweaks to be made to the new naming style so that's all you
do. Other folks who use, for example, Brazilian Portuguese, will need to
make tweaks and look up the correct value in the file the news item
references.

For now LINGUAS and L10N will work in parallel and the devs will do the
heavy lifting. For the moment all changes will be light touch, the big
tasks will happen later.

One day you will need to remove LINGUAS from make.conf entirely, but
that day is not today.

And all of this is necessary because making a USE_EXPAND env var called
LINGUAS was a really stupid idea from day one.


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Peter Humphrey]

On Friday 24 Jun 2016 09:54:35 Dale wrote:

> I agree that the news item was confusing.  The guide it linked to wasn't
> much better either.  In the end, I just fiddled with the setting until I
> found a setting that didn't change what I already have, in other words,
> I got a clean emerge -uvaDN world.  My first couple runs wanted to
> remove things and I knew the setting wasn't right yet.  After it was all
> done, this is what I ended up with:
> 
> LINGUAS="en_US en"
> 
> I left the LANG setting as is for the moment.

Didn't you set L10N as well? I read the news item as requiring it.

-- 
Rgds
Peter

Re: [gentoo-user] LINGUAS, L10N, and local-gen

[Dale]

allan gottlieb wrote:
> Having read the latest news article and rereading parts of the
> localization guide, it is not clear to me what action, if any, I need to
> take.
>
> My systems are US English only
>
> /etc/portage/make.conf has
>LINGUAS="en"
>
> /etc/local.gen has just comments plus
>en_US ISO-8859-1
>en_US.UTF-8 UTF-8
>
> Should I add
>L10N="en-US"
> to /etc/portage/make.conf ?
>
> Should I run local-gen ?
>
> Thanks
> allan
>
>

I agree that the news item was confusing.  The guide it linked to wasn't
much better either.  In the end, I just fiddled with the setting until I
found a setting that didn't change what I already have, in other words,
I got a clean emerge -uvaDN world.  My first couple runs wanted to
remove things and I knew the setting wasn't right yet.  After it was all
done, this is what I ended up with:

LINGUAS="en_US en" 

I left the LANG setting as is for the moment. 

Hope that helps.

Dale

:-)  :-) 

[gentoo-user] LINGUAS, L10N, and local-gen

[allan gottlieb]

Having read the latest news article and rereading parts of the
localization guide, it is not clear to me what action, if any, I need to
take.

My systems are US English only

/etc/portage/make.conf has
   LINGUAS="en"

/etc/local.gen has just comments plus
   en_US ISO-8859-1
   en_US.UTF-8 UTF-8

Should I add
   L10N="en-US"
to /etc/portage/make.conf ?

Should I run local-gen ?

Thanks
allan

Re: [gentoo-user] LINGUAS issue

[Florian Gamböck]

Hi Francisco,

On 2015-11-12 15:20, Francisco Ares wrote:
> Is there a way for specifying particular "LINGUAS" for individual
> packages?

Sure there is. In fact, "LINGUAS=pt_BR" is just syntactical sugar for
"USE=linguas_pt_BR". So for your specific case with tesseract, you would add a
line to packages.use, saying:

app-text/tesseract linguas_pt

Hope that helps!

--Flo

[gentoo-user] LINGUAS issue

[Francisco Ares]

Hi, all.

My locale language is "pt_BR" (Brazilian Portuguese), and many applications
now support native translations.

And there is the "pt" possible LINGUAS entry, and there is no "pt_PT"
(Portugal spoken Portuguese), for instance, neither any derivatives for
other Portuguese speaking countries, which possibly have their own regional
differences.

There are a few applications that do not distinguish "pt_BR" from "pt" and
treat Portuguese language as simply "pt". An example is the OCR program
"tesseract", that builds language specifics according to the LINGUAS
environment variable.

Is there a way for specifying particular "LINGUAS" for individual
packages?  I would not like to have to build dozens of applications to
include "pt" to my "LINGUAS" definition just to have "tesseract" to include
my native language support.  I've found some old messages about this on the
net, but did not get any real solution.

Or should I ask the "tesseract" package maintainer to add "pt_BR" to the
available options?

Thanks a lot for your time,
Francisco

Re: [gentoo-user] LINGUAS issue

[wabenbau]

Francisco Ares  wrote:

> Hi, all.
> 
> My locale language is "pt_BR" (Brazilian Portuguese), and many
> applications now support native translations.
> 
> And there is the "pt" possible LINGUAS entry, and there is no "pt_PT"
> (Portugal spoken Portuguese), for instance, neither any derivatives
> for other Portuguese speaking countries, which possibly have their
> own regional differences.

You can add locales by editing /etc/locale.gen and running locale-gen.
As i saw in /usr/share/i18n/SUPPORTED, pt_PT is supported.

> There are a few applications that do not distinguish "pt_BR" from
> "pt" and treat Portuguese language as simply "pt". An example is the
> OCR program "tesseract", that builds language specifics according to
> the LINGUAS environment variable.
> 
> Is there a way for specifying particular "LINGUAS" for individual
> packages?  I would not like to have to build dozens of applications to
> include "pt" to my "LINGUAS" definition just to have "tesseract" to
> include my native language support.  I've found some old messages
> about this on the net, but did not get any real solution.

You can define package specific environment variables for package 
builds in /etc/portage/env/

If you need package specific environment variables for runtime you
could create simple scripts to set the env and start the program.

#!/bin/sh
#
# start_tesseract.sh
#
LINGUAS="pt"
tesseract

Then modify the according menu entries / starter buttons to use the 
script.
 
> Or should I ask the "tesseract" package maintainer to add "pt_BR" to
> the available options?

That's a good idea.

--
Regards
wabe

Re: [gentoo-user] LINGUAS

[Andrea Conti]

 It's the official (as far as
 there is such a thing) place to store the list of gettext translations
 you want on your system, and most autotools-based builds and binary
 package managers also recognize it.

I didn't know that. Thanks for clarifying!

andrea

Re: [gentoo-user] LINGUAS

[Elmar Hinz]

2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
 Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar Hinz
 did opine thusly:

 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.

 What has LINGUAS todo with make? I would expect it in rc.conf near the
 UNICODE setting.


 It has nothing to do with make. It has everything to do with portage.


Even than, LINGUAS has rather to do with OpenOffice.

Has it anything to do with portage at all?

Re: [gentoo-user] LINGUAS

[Alan McKinnon]

Apparently, though unproven, at 13:48 on Thursday 19 August 2010, Elmar Hinz 
did opine thusly:

 2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
  Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar
  Hinz
  
  did opine thusly:
  The gentoo wiki suggests in different places to set the LINGUAS
  environment variable in make.conf.
  
  What has LINGUAS todo with make? I would expect it in rc.conf near the
  UNICODE setting.
  
  It has nothing to do with make. It has everything to do with portage.
 
 Even than, LINGUAS has rather to do with OpenOffice.
 
 Has it anything to do with portage at all?

It's in make.conf isn't it?

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] LINGUAS

[Nganon]

On 19 August 2010 14:48, Elmar Hinz oss.el...@googlemail.com wrote:

 2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
  Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar
 Hinz
  did opine thusly:
 
  The gentoo wiki suggests in different places to set the LINGUAS
  environment variable in make.conf.
 
  What has LINGUAS todo with make? I would expect it in rc.conf near the
  UNICODE setting.
 
 
  It has nothing to do with make. It has everything to do with portage.
 

 Even than, LINGUAS has rather to do with OpenOffice.

 Has it anything to do with portage at all?


It has something to with packages that has localization support,
thus everything to with portage.

Global linguas flags are set in make.conf as
LINGUAS=en de ru

and application specific ones can be set in package.use as
www-client/firefox linguas_en_GB
app-office/openoffice-bin linguas_en_GB linguas_de

Re: [gentoo-user] LINGUAS

[Graham Murray]

Elmar Hinz oss.el...@googlemail.com writes:

 2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
 Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar Hinz
 did opine thusly:

 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.

 What has LINGUAS todo with make? I would expect it in rc.conf near the
 UNICODE setting.


 It has nothing to do with make. It has everything to do with portage.


 Even than, LINGUAS has rather to do with OpenOffice.

 Has it anything to do with portage at all?

Several packages, not just OpenOffice, can include/support different
languages. Portage uses the value of LINGUAS to tell these packages
which languages to include/support.

Re: [gentoo-user] LINGUAS

[Florian CROUZAT]

On 19 août 2010, at 14:27, Graham Murray wrote:

 Elmar Hinz oss.el...@googlemail.com writes:
 
 2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
 Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar 
 Hinz
 did opine thusly:
 
 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.
 
 What has LINGUAS todo with make? I would expect it in rc.conf near the
 UNICODE setting.
 
 
 It has nothing to do with make. It has everything to do with portage.
 
 
 Even than, LINGUAS has rather to do with OpenOffice.
 
 Has it anything to do with portage at all?
 
 Several packages, not just OpenOffice, can include/support different
 languages. Portage uses the value of LINGUAS to tell these packages
 which languages to include/support.

I have access to this box where linguas=fr is set.
Check this output:
 $ type -a [
[ est une primitive du shell
[ est /usr/bin/[

[ is a shell built-in becomes est une primitive du shell
I can't see any use flags in coreutils/bash that informs me it will be emerged 
with the linguas support.
How do I know which package will be localized then ? Just curious, I don't 
tweak my linguas.


-
Florian.
/ For security reasons, all text in this mail 
  is double-rot13 encrypted. /

Re: [gentoo-user] LINGUAS

[Elmar Hinz]

 Even than, LINGUAS has rather to do with OpenOffice.

 Has it anything to do with portage at all?

 Several packages, not just OpenOffice, can include/support different
 languages. Portage uses the value of LINGUAS to tell these packages
 which languages to include/support.


When  Portage evaluates this variable it makes some sense.

On the other hand LINGUAS is still a general variable AFAIK and not
portage specific.

So shouldn't it be set in a general location like time and locales?

Al

Re: [gentoo-user] LINGUAS

[Arttu V.]

On 8/19/10, Elmar Hinz oss.el...@googlemail.com wrote:
 Even than, LINGUAS has rather to do with OpenOffice.

 Has it anything to do with portage at all?

 Several packages, not just OpenOffice, can include/support different
 languages. Portage uses the value of LINGUAS to tell these packages
 which languages to include/support.


 When  Portage evaluates this variable it makes some sense.

 On the other hand LINGUAS is still a general variable AFAIK and not
 portage specific.

 So shouldn't it be set in a general location like time and locales?

No, I think you're mixing up compile-time and run-time values -- and
also reading too much into the file names. make.conf should really
rather be called portage.conf. That would make much more sense IMHO.
:)

-- 
Arttu V. -- Running Gentoo is like running with scissors

Re: [gentoo-user] LINGUAS

[Arttu V.]

On 8/19/10, Florian CROUZAT gen...@floriancrouzat.net wrote:

 On 19 août 2010, at 14:27, Graham Murray wrote:

 Several packages, not just OpenOffice, can include/support different
 languages. Portage uses the value of LINGUAS to tell these packages
 which languages to include/support.

 I have access to this box where linguas=fr is set.
 Check this output:
  $ type -a [
 [ est une primitive du shell
 [ est /usr/bin/[

 [ is a shell built-in becomes est une primitive du shell
 I can't see any use flags in coreutils/bash that informs me it will be
 emerged with the linguas support.
 How do I know which package will be localized then ? Just curious, I don't
 tweak my linguas.

Check for the tell-tale USE=nls flag in the ebuilds.

Not all ebuild's bother listing explicitly out all of the LINGUAS
their sources actually support. coreutils is one of the lazy ones.

Just look at its sources: 39 different .po files, that's 39
localizations available. No point printing out such monstrous long
lists -- your localization is in there, period! ;)  But coreutils does
obey LINGUAS anyway. It only installs what you have in your LINGUAS
(check, e.g., with equery files coreutils).

Openoffice is a special case (surprise!). Its ebuild depends
dynamically on spell-check packages depending on the value of LINGUAS
-- so the poor Gentoo OOo maintainers must list out every supported
lingua in the ebuild. :)

-- 
Arttu V. -- Running Gentoo is like running with scissors

Re: [gentoo-user] LINGUAS

[David W Noon]

On Thu, 19 Aug 2010 13:50:02 +0200, Elmar Hinz wrote about Re:
[gentoo-user] LINGUAS:

2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
 Apparently, though unproven, at 23:25 on Wednesday 18 August 2010,
 Elmar Hinz did opine thusly:

 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.

 What has LINGUAS todo with make? I would expect it in rc.conf near
 the UNICODE setting.


 It has nothing to do with make. It has everything to do with portage.


Even than, LINGUAS has rather to do with OpenOffice.

Not really.

Has it anything to do with portage at all?

The LINGUAS variable is used by many packages that use
internationalization (i18n) or localization (l10n).  It is the standard
place for an ebuild to check what National Language Support (NLS) is
required for a package.  Check which packages you have installed that
have the nls USE flag.
-- 
Regards,

Dave  [RLU #314465]
==
dwn...@ntlworld.com (David W Noon)
==


signature.asc
Description: PGP signature

Re: [gentoo-user] LINGUAS

[Andrea Conti]

 On the other hand LINGUAS is still a general variable AFAIK and not
 portage specific.

LINGUAS is strictly portage-specific. It's used to control the
compile-time inclusion of languages and/or locales for packages which
have that kind of option (i.e. OpenOffice, KDE, Firefox and many
others); as such it is generally set in make.conf, although it can be
controlled on a per-package basis as others have said.

On the other hand, things like bash and coreutils usually have a nls
USE flag which controls the compile-time inclusion of *all* supported
localizations.

Packages built with support for multiple locales will usually pick the
right one at run-time by looking at the LANG and LC_* environment variables.
(See http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 for
more details)

andrea

Re: [gentoo-user] LINGUAS

[Elmar Hinz]

 No, I think you're mixing up compile-time and run-time values -- and
 also reading too much into the file names. make.conf should really
 rather be called portage.conf. That would make much more sense IMHO.
 :)


As long as the source is the documentation, it should be possible by
concept to read in filenames.

I think you are right, that portage.conf would be the natural name.

Al

Re: [gentoo-user] LINGUAS

[Elmar Hinz]

2010/8/19 Andrea Conti a...@alyf.net:
 On the other hand LINGUAS is still a general variable AFAIK and not
 portage specific.

 LINGUAS is strictly portage-specific.

Really?

Researching the web I understand it origins from gettext and portage
has implemented it. If I understand right, it would still matter if
you compile something without portage.

But is the following generalization correct?

* LINGUAS is the compile time setting (for multiple languages)
* LANG is the runtime setting (for the current language).

Al

Re: [gentoo-user] LINGUAS

[Bill Longman]

On 08/19/2010 05:37 AM, Florian CROUZAT wrote:
 
 On 19 août 2010, at 14:27, Graham Murray wrote:
 
 Elmar Hinz oss.el...@googlemail.com writes:

 2010/8/18 Alan McKinnon alan.mckin...@gmail.com:
 Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar 
 Hinz
 did opine thusly:

 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.

 What has LINGUAS todo with make? I would expect it in rc.conf near the
 UNICODE setting.


 It has nothing to do with make. It has everything to do with portage.


 Even than, LINGUAS has rather to do with OpenOffice.

 Has it anything to do with portage at all?

 Several packages, not just OpenOffice, can include/support different
 languages. Portage uses the value of LINGUAS to tell these packages
 which languages to include/support.
 
 I have access to this box where linguas=fr is set.
 Check this output:
  $ type -a [
 [ est une primitive du shell
 [ est /usr/bin/[
 
 [ is a shell built-in becomes est une primitive du shell
 I can't see any use flags in coreutils/bash that informs me it will be 
 emerged with the linguas support.
 How do I know which package will be localized then ? Just curious, I don't 
 tweak my linguas.

As others have said, it's the nls setting that does this. Specifically,
the string est une primitive du shell is part of the i18n that's in
the bash binary. When you set LANG or LC_MESSAGES to something
different, i.e., el_GR, you'll get the Greek translation. The man page
for locale has lots of info about this.

Re: [gentoo-user] LINGUAS

[Bill Longman]

On 08/19/2010 06:53 AM, Elmar Hinz wrote:
 2010/8/19 Andrea Conti a...@alyf.net:
 On the other hand LINGUAS is still a general variable AFAIK and not
 portage specific.

 LINGUAS is strictly portage-specific.
 
 Really?
 
 Researching the web I understand it origins from gettext and portage
 has implemented it. If I understand right, it would still matter if
 you compile something without portage.
 
 But is the following generalization correct?
 
 * LINGUAS is the compile time setting (for multiple languages)
 * LANG is the runtime setting (for the current language).

Yeah, but with the caveat that LANG is the generalization for all the
LC_* variables.

Re: [gentoo-user] LINGUAS

[Mike Edenfield]

On 8/19/2010 9:33 AM, Andrea Conti wrote:
 On the other hand LINGUAS is still a general variable AFAIK and not
 portage specific.
 
 LINGUAS is strictly portage-specific. It's used to control the
 compile-time inclusion of languages and/or locales for packages which
 have that kind of option (i.e. OpenOffice, KDE, Firefox and many
 others); as such it is generally set in make.conf, although it can be
 controlled on a per-package basis as others have said.

It's more accurate to say LINGUAS is build-time specific.  Portage is
not the only build process/package manager/configuration system/coffee
maker that knows what LINGUAS means.  It's the official (as far as
there is such a thing) place to store the list of gettext translations
you want on your system, and most autotools-based builds and binary
package managers also recognize it.

--Mike

Re: [gentoo-user] LINGUAS

[Mike Edenfield]

On 8/19/2010 9:53 AM, Elmar Hinz wrote:

 But is the following generalization correct?
 
 * LINGUAS is the compile time setting (for multiple languages)
 * LANG is the runtime setting (for the current language).

Yes, as long as you're aware that LINGUAS support is recommended, but
optional.  A package that simply installs every .po file it has will
still operate in the correct locale based on your LANG setting, it will
just waste a lot of space.

--Mike

[gentoo-user] LINGUAS

[Elmar Hinz]

The gentoo wiki suggests in different places to set the LINGUAS
environment variable in make.conf.

What has LINGUAS todo with make? I would expect it in rc.conf near the
UNICODE setting.

Al

Re: [gentoo-user] LINGUAS

[Alan McKinnon]

Apparently, though unproven, at 23:25 on Wednesday 18 August 2010, Elmar Hinz 
did opine thusly:

 The gentoo wiki suggests in different places to set the LINGUAS
 environment variable in make.conf.
 
 What has LINGUAS todo with make? I would expect it in rc.conf near the
 UNICODE setting.


It has nothing to do with make. It has everything to do with portage.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] $LINGUAS question

[Mick]

On Friday 23 May 2008, Neil Bothwick wrote:
 On Fri, 23 May 2008 17:02:19 +0100, Mick wrote:
  Despite my LINGUAS settings I have noticed that kcontrol only shows
  US English under languages.  Country  Region allows me to select
  UK, but the only option that I have/can add under languages is US.
  Spelling is en_US, although I would like to choose en_UK.  What
  control what languages can be added there?

 emerge kde-i18n

Just as was ready to reply I already have I found out that I have not . . . 
Ha!

Thank you very much.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] $LINGUAS question

[Neil Bothwick]

On Sat, 24 May 2008 07:17:35 +0100, Mick wrote:

  emerge kde-i18n  
 
 Just as was ready to reply I already have I found out that I have
 not . . . Ha!

I wonder if it should be a dependency of kdelibs if $LINGUAS is set to
anything but en_US.


-- 
Neil Bothwick

We've all heard that a million monkeys banging on a million
typewriters will eventually reproduce the works of Shakespeare.
Now, thanks to the Internet, we know this is not true.


signature.asc
Description: PGP signature

Re: [gentoo-user] $LINGUAS question

[Mick]

2008/5/22  [EMAIL PROTECTED]:
 On Wed, May 21, 2008 at 03:13:44PM +0100, Uwe Thiem wrote:

 Does it matter in which order languages are emerged?

 Mplayer emerge says it uses the first one as the default language, and
 one firefox emerge showed all help menus etc in some non-English
 language.  Wheteher anything else cares, I do not know.

Despite my LINGUAS settings I have noticed that kcontrol only shows
US English under languages.  Country  Region allows me to select
UK, but the only option that I have/can add under languages is US.
Spelling is en_US, although I would like to choose en_UK.  What
control what languages can be added there?
-- 
Regards,
Mick
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Neil Bothwick]

On Fri, 23 May 2008 17:02:19 +0100, Mick wrote:

 Despite my LINGUAS settings I have noticed that kcontrol only shows
 US English under languages.  Country  Region allows me to select
 UK, but the only option that I have/can add under languages is US.
 Spelling is en_US, although I would like to choose en_UK.  What
 control what languages can be added there?

emerge kde-i18n


-- 
Neil Bothwick

A wok is what you throw at a wabbit.


signature.asc
Description: PGP signature

Re: [gentoo-user] $LINGUAS question

[Mick]

On Monday 19 May 2008, Michał 'shpaq' Laszuk wrote:
 Dnia 2008-05-18, nie o godzinie 23:02 +0100, Graham Murray pisze:
  Michał 'shpaq' Laszuk [EMAIL PROTECTED] writes:
   The LINGUAS variable should be only en. en_US is a localization.
 
  In that case why do packages such as mozilla-firefox support (amongst
  others) linguas_en, linguas_en_GB and linguas_en_US? They use the
  LINGUAS variable to select which localised language packs to install. So
  'LINGUAS=en_US en' is perfectly valid.

 You're right. My fault.

Mine has been set to LINGUAS=en_GB el for many years now, but mplayer still 
shows up with scrambled characters on the terminal (aterm/rxvt).  However, 
when rebuilt like:

LINGUAS=en_US emerge -DV mplayer

no more scrambled messages!  This tells me that mplayer's translations are 
partial to the particular LINGUAS flags and probably affected by what 
character sets your terminal can show. 
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] $LINGUAS question

[felix]

On Wed, May 21, 2008 at 10:26:58AM +0100, Mick wrote:
 Mine has been set to LINGUAS=en_GB el for many years now, but mplayer still 
 shows up with scrambled characters on the terminal (aterm/rxvt).  However, 
 when rebuilt like:
 
 LINGUAS=en_US emerge -DV mplayer
 
 no more scrambled messages!  This tells me that mplayer's translations are 
 partial to the particular LINGUAS flags and probably affected by what 
 character sets your terminal can show. 

I have also found that when LINGUAS is set to multiple values, emerge
-pv sorts them when it shwos what it would do:

# LINGUAS=en_US en_GB en emerge -pv --nospinner mozilla-firefox-bin

These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild U ] www-client/mozilla-firefox-bin-3.0_rc1 [3.0_beta5-r1] 
USE=-restrict-javascript LINGUAS=en en_GB en_US 0 kB 

Total: 1 package (1 upgrade), Size of downloads: 0 kB

Whether or not this reported order is what it actually uses, I don't
know and don't know how to find out.

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Uwe Thiem]

On Wednesday 21 May 2008, [EMAIL PROTECTED] wrote:
 On Wed, May 21, 2008 at 10:26:58AM +0100, Mick wrote:
  Mine has been set to LINGUAS=en_GB el for many years now, but
  mplayer still shows up with scrambled characters on the terminal
  (aterm/rxvt).  However, when rebuilt like:
 
  LINGUAS=en_US emerge -DV mplayer
 
  no more scrambled messages!  This tells me that mplayer's
  translations are partial to the particular LINGUAS flags and
  probably affected by what character sets your terminal can show.

 I have also found that when LINGUAS is set to multiple values,
 emerge -pv sorts them when it shwos what it would do:

 # LINGUAS=en_US en_GB en emerge -pv --nospinner
 mozilla-firefox-bin

 These are the packages that would be merged, in order:

 Calculating dependencies ... done!
 [ebuild U ] www-client/mozilla-firefox-bin-3.0_rc1
 [3.0_beta5-r1] USE=-restrict-javascript LINGUAS=en en_GB en_US
 0 kB

 Total: 1 package (1 upgrade), Size of downloads: 0 kB

 Whether or not this reported order is what it actually uses, I
 don't know and don't know how to find out.

Does it matter in which order languages are emerged?

Uwe

-- 
Ignorance killed the cat, sir, curiosity was framed!
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[felix]

On Wed, May 21, 2008 at 03:13:44PM +0100, Uwe Thiem wrote:

 Does it matter in which order languages are emerged?

Mplayer emerge says it uses the first one as the default language, and
one firefox emerge showed all help menus etc in some non-English
language.  Wheteher anything else cares, I do not know.

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Neil Bothwick]

On Sun, 18 May 2008 16:28:07 -0700, [EMAIL PROTECTED] wrote:

  LINGUAS is a system-wide setting, it does not make choices for
  individual users, but it does control their range of choice.  
 
 Well, nice theory :-) but mplayer emerge says this --
 
 LOG: setup
 For MPlayer's language support, the configuration will
 use your LINGUAS variable from /etc/make.conf.  If you have more
 than one language enabled, then the first one in the list will
 be used to output the messages, if a translation is available.
 man pages will be created for all languages where translations
 are also available.
 
 and it certainly does not use the first one in the list.

Either you already have a different setting in your local or global
mplayer configuration (emerging previously with a different LINGUAS could
cause this) or you have found a bug.


-- 
Neil Bothwick

Shotgun wedding: A case of wife or death.


signature.asc
Description: PGP signature

Re: [gentoo-user] $LINGUAS question

[Stroller]

On 19 May 2008, at 00:02, [EMAIL PROTECTED] wrote:

...
I have had bad luck with LINGUAS.  I tried setting it to all the
languages I knew of --

LINGUAS=en_US af ar az bg bn br bs ca cs cy da de el en_GB eo  
es et eu fa fi fr fy ga gl he hi hr hu is it ja km ko lt lv mk mn  
ms nb nds nl nn pa pl pt pt_BR ro ru rw se sk sl sr [EMAIL PROTECTED] ss sv  
ta tg tr uk uz zh_CN zh_TW


out of curiousity, and mplayer, for one, picks something other than
en_US as the default -- all error messages come out like this --

AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
ÐапоÑва вÑзпÑоизвежданеÑо...
[h264 @ 0xb049c0]brainfart cropping not supported, this could look  
slightly wrong ...
VDec: заÑвка на vo config - 480 x 360 (preferred csp: Planar  
YV12)

VDec: using Planar YV12 as output csp (no 0)
ÐÑопоÑÑииÑе на Ñилма Ñа 1.33:1 - маÑабиÑане Ð 
´Ð¾ пÑавилниÑе пÑопоÑÑии .

VO: [xv] 480x360 = 480x360 Planar YV12
A:   2.2 V:   2.2 A-V:  0.005 ct:  0.023   0/  0 10%  2%  1.9% 1 0
Ðзлизане Ð¾Ñ Ð¿ÑогÑамаÑа... (ÐзÑод)
...


On 19 May 2008, at 00:28, [EMAIL PROTECTED] wrote:

Well, nice theory :-) but mplayer emerge says this --

LOG: setup
For MPlayer's language support, the configuration will
use your LINGUAS variable from /etc/make.conf.  If you have more
than one language enabled, then the first one in the list will
be used to output the messages, if a translation is available.
man pages will be created for all languages where translations
are also available.


My guess is that you should be using en only, not en_US or  
en_GB for mplayer. When it finds no en in your LINGUAS - and  
doesn't understand en_US - it uses the next in the list, instead  
(af? ar?).


I'd have thought that languages should be put in LINGUAS in order of  
preference - eg en_GB en_US en then the rest.


Stroller.
--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Michał 'shpaq' Laszuk]

Dnia 2008-05-18, nie o godzinie 23:02 +0100, Graham Murray pisze:
 Michał 'shpaq' Laszuk [EMAIL PROTECTED] writes:
 
  The LINGUAS variable should be only en. en_US is a localization.
 
 In that case why do packages such as mozilla-firefox support (amongst
 others) linguas_en, linguas_en_GB and linguas_en_US? They use the
 LINGUAS variable to select which localised language packs to install. So
 'LINGUAS=en_US en' is perfectly valid.

You're right. My fault. 

-- 
Nie istnieje bariera nieskończenie ostateczna,
Nie istnieje nic, co nie może się zmienić.


signature.asc
Description: To jest część	 wiadomości podpisana cyfrowo

[gentoo-user] $LINGUAS question

[»Q«]

I only need English support, but USan English is preferred.  I have in
make.conf

LINGUAS=en_US en

thinking that if an app supports en_US that will be used since it's
first.  Is that the way it works?

I guess this is just a trivia question -- I don't even know if there
are apps which could use en_US /and/ en.

-- 
»Q«
 Kleeneness is next to Gödelness.


--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Michał 'shpaq' Laszuk]

Dnia 2008-05-18, nie o godzinie 15:07 -0500, »Q« pisze:
 ng that if an app supports en_US that will be used since it's
 first.  Is that the way it works?

The LINGUAS variable should be only en. en_US is a localization.
-- 
Nie istnieje bariera nieskończenie ostateczna,
Nie istnieje nic, co nie może się zmienić.


signature.asc
Description: To jest część	 wiadomości podpisana cyfrowo

Re: [gentoo-user] $LINGUAS question

[Graham Murray]

Michał 'shpaq' Laszuk [EMAIL PROTECTED] writes:

 The LINGUAS variable should be only en. en_US is a localization.

In that case why do packages such as mozilla-firefox support (amongst
others) linguas_en, linguas_en_GB and linguas_en_US? They use the
LINGUAS variable to select which localised language packs to install. So
'LINGUAS=en_US en' is perfectly valid.
--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[felix]

On Sun, May 18, 2008 at 11:02:07PM +0100, Graham Murray wrote:
 Micha?? 'shpaq' Laszuk [EMAIL PROTECTED] writes:
 
  The LINGUAS variable should be only en. en_US is a localization.
 
 In that case why do packages such as mozilla-firefox support (amongst
 others) linguas_en, linguas_en_GB and linguas_en_US? They use the
 LINGUAS variable to select which localised language packs to install. So
 'LINGUAS=en_US en' is perfectly valid.

I have had bad luck with LINGUAS.  I tried setting it to all the
languages I knew of --

LINGUAS=en_US af ar az bg bn br bs ca cs cy da de el en_GB eo es et eu fa 
fi fr fy ga gl he hi hr hu is it ja km ko lt lv mk mn ms nb nds nl nn pa pl pt 
pt_BR ro ru rw se sk sl sr [EMAIL PROTECTED] ss sv ta tg tr uk uz zh_CN zh_TW

out of curiousity, and mplayer, for one, picks something other than
en_US as the default -- all error messages come out like this --

AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
 ???...
[h264 @ 0xb049c0]brainfart cropping not supported, this could look slightly 
wrong ...
VDec: ???  vo config - 480 x 360 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
?  ? ??? 1.33:1 - ??  
?? ??? .
VO: [xv] 480x360 = 480x360 Planar YV12 
A:   2.2 V:   2.2 A-V:  0.005 ct:  0.023   0/  0 10%  2%  1.9% 1 0 
??? ??? ?... ()

If I remerge it with LINGUAS=en_US, it shows this:

AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
[h264 @ 0xb00a40]brainfart cropping not supported, this could look slightly 
wrong ...
VDec: vo config request - 480 x 360 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [xv] 480x360 = 480x360 Planar YV12 
A:   5.1 V:   5.1 A-V: -0.000 ct:  0.023   0/  0 10%  1%  1.2% 1 0 
Exiting... (Quit)

One merge of firefox beta picked some language other then en for its
messages, menus, etc.

What is LINGUAS supposed to do?

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Neil Bothwick]

On Sun, 18 May 2008 16:02:25 -0700, [EMAIL PROTECTED] wrote:

 What is LINGUAS supposed to do?

Tell portage which languages you want support for when building an
application. It does not set the default language for that application,
which is either handled by the locale environment variables or the
program's own settings.

LINGUAS is a system-wide setting, it does not make choices for individual
users, but it does control their range of choice.


-- 
Neil Bothwick

If your VCR still flashes 12:00 - then Linux is not for you.


signature.asc
Description: PGP signature

Re: [gentoo-user] $LINGUAS question

[felix]

On Mon, May 19, 2008 at 12:22:45AM +0100, Neil Bothwick wrote:
 On Sun, 18 May 2008 16:02:25 -0700, [EMAIL PROTECTED] wrote:
 
  What is LINGUAS supposed to do?
 
 Tell portage which languages you want support for when building an
 application. It does not set the default language for that application,
 which is either handled by the locale environment variables or the
 program's own settings.
 
 LINGUAS is a system-wide setting, it does not make choices for individual
 users, but it does control their range of choice.

Well, nice theory :-) but mplayer emerge says this --

LOG: setup
For MPlayer's language support, the configuration will
use your LINGUAS variable from /etc/make.conf.  If you have more
than one language enabled, then the first one in the list will
be used to output the messages, if a translation is available.
man pages will be created for all languages where translations
are also available.

and it certainly does not use the first one in the list.

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] $LINGUAS question

[Volker Armin Hemmann]

On Sonntag, 18. Mai 2008, »Q« wrote:
 I only need English support, but USan English is preferred.  I have in
 make.conf

 LINGUAS=en_US en

 thinking that if an app supports en_US that will be used since it's
 first.  Is that the way it works?

no. It installs the en_US and en language files.

Set something like LC_ALL=en_US
--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] LINGUAS

[Michael George]

On 7/29/06, Michael George [EMAIL PROTECTED] wrote:
The docs I found on gentoo localization indicate that I can set LINGUAS
in make.conf and build for just the languages I desire.  I set it to:
LINGUAS=en_US
but all that does is prepend en_US to the beginning of the string above.

Thanks to all who responded to my questions.  I now have a better
understanding of this variable, USE flags, and emerge in general.

-- 
-M

There are 10 kinds of people in this world:
Those who can count in binary and those who cannot.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LINGUAS

[Alexander Skwar]

Michael George schrieb:

I am building OOo 2.0.3 and I happened to notice in the verbose emerge
output that there is a long list of languages listed in the LINGUAS
variable:

 LINGUAS=-af% -ar% -be_BY% -bg% -bn% -bs% -ca% -cs% -cy% -da% -de% -el%
 -en% -en_GB% -en_US% -en_ZA% -es% -et% -fa% -fi% -fr% -gu_IN% -he%
 -hi_IN% -hr% -hu% -it% -ja% -km% -ko% -lt% -mk% -nb% -nl% -nn% -nr%
 -ns% -pa_IN% -pl% -pt% -pt_BR% -ru% -rw% -sh_YU% -sk% -sl% -sr_CS% -st%
 -sv% -sw_TZ% -th% -tn% -tr% -ts% -vi% -xh% -zh_CN% -zh_TW% -zu%

Does this mean that NONE of those languages will be built in or that ALL
of them will be?


If all of them have a - before, then yes, none will be built.


The docs I found on gentoo localization indicate that I can set LINGUAS
in make.conf and build for just the languages I desire.  I set it to:
LINGUAS=en_US
but all that does is prepend en_US to the beginning of the string above.


How? What's shown?


Where are those settings coming from?


make.conf

Alexander Skwar
--
The one sure way to make a lazy man look respectable is to put a fishing
rod in his hand.
--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LINGUAS

[Richard Fish]

On 7/29/06, Michael George [EMAIL PROTECTED] wrote:

The docs I found on gentoo localization indicate that I can set LINGUAS
in make.conf and build for just the languages I desire.  I set it to:
LINGUAS=en_US
but all that does is prepend en_US to the beginning of the string above.


Look closer; it should put en_US at the begining of the string, and
remove the -en_US from the middle.  The normal configuration of
portage is to display set USE flags first, followed by the unset
flags, and each group is sorted alphabetically.

-Richard
--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LINGUAS

[Benno Schulenberg]

Michael George wrote:
  LINGUAS=-af% -ar% -be_BY% -bg% -bn% -bs% -ca% -cs% -cy% -da%
 -de% -el% -en% -en_GB% -en_US% -en_ZA% -es% -et% -fa% -fi% -fr%
 -gu_IN% -he% -hi_IN% -hr% -hu% -it% -ja% -km% -ko% -lt% -mk% -nb%
 -nl% -nn% -nr% -ns% -pa_IN% -pl% -pt% -pt_BR% -ru% -rw% -sh_YU%
 -sk% -sl% -sr_CS% -st% -sv% -sw_TZ% -th% -tn% -tr% -ts% -vi% -xh%
 -zh_CN% -zh_TW% -zu%

 Does this mean that NONE of those languages will be built in or
 that ALL of them will be?

None, as they all start with a minus sign.

 I set it to: LINGUAS=en_US
 but all that does is prepend en_US to the beginning of the string
 above.

Not quite: it also removes the -en_US.  It makes no difference, 
though, as the ebuild uses en_US by default when LINGUAS is empty.

 Where are those settings coming from?

From the ebuild: it specifies that it can handle LANGS=af ar 

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LINGUAS

[Alexander Skwar]

Michael George schrieb:

On Sat, Jul 29, 2006 at 05:20:13PM +0200, Alexander Skwar wrote:

Michael George schrieb:
I am building OOo 2.0.3 and I happened to notice in the verbose emerge
output that there is a long list of languages listed in the LINGUAS
variable:

 LINGUAS=-af% -ar% -be_BY% -bg% -bn% -bs% -ca% -cs% -cy% -da% -de% -el%
 -en% -en_GB% -en_US% -en_ZA% -es% -et% -fa% -fi% -fr% -gu_IN% -he%
 -hi_IN% -hr% -hu% -it% -ja% -km% -ko% -lt% -mk% -nb% -nl% -nn% -nr%
 -ns% -pa_IN% -pl% -pt% -pt_BR% -ru% -rw% -sh_YU% -sk% -sl% -sr_CS% -st%
 -sv% -sw_TZ% -th% -tn% -tr% -ts% -vi% -xh% -zh_CN% -zh_TW% -zu%

Does this mean that NONE of those languages will be built in or that ALL
of them will be?

If all of them have a - before, then yes, none will be built.


Okay, that's what I figured it meant.


The docs I found on gentoo localization indicate that I can set LINGUAS
in make.conf and build for just the languages I desire.  I set it to:
LINGUAS=en_US
but all that does is prepend en_US to the beginning of the string above.

How? What's shown?


If I put LINGUAS=en_US into make.conf, then the LINGUAS line reads:

LINGUAS=en_US% -af% -ar% -be_BY% -bg% -bn% -bs% -ca% -cs% -cy% -da% -de%
-el% -en% -en_GB% -en_ZA% -es% -et% -fa% -fi% -fr% -gu_IN% -he%
-hi_IN% -hr% -hu% -it% -ja% -km% -ko% -lt% -mk% -nb% -nl% -nn% -nr%
-ns% -pa_IN% -pl% -pt% -pt_BR% -ru% -rw% -sh_YU% -sk% -sl% -sr_CS% -st%
-sv% -sw_TZ% -th% -tn% -tr% -ts% -vi% -xh% -zh_CN% -zh_TW% -zu%

en_US is put on the front and -en_US disappears from the list.  


See, it works just like a USE flag. Means: You now enabled the en_US linguas.


Where are those settings coming from?

make.conf


Any that I specify to be built are in make.conf, but there is nothing in
make.conf that specifies the - entries


Of course not - just like there's (mostly) nothing in your make.conf
or package.use, which specifies - USE flags.

Alexander Skwar
--
MSDOS is not dead, it just smells that way.
-- Henry Spencer
--
gentoo-user@gentoo.org mailing list

[gentoo-user] LINGUAS

[Benno Schulenberg]

Matthias Bethke wrote:
 on Wednesday, 2006-04-05 at 14:50:29, you wrote:
  Just put LINGUAS=fr en.  I'm unsure whether en-us is
  recognized.

 The Localization Guide isn't very clear about the syntax of
 these, nor how to get a list of available codes. I guess the
 basic ones are the two-letter ISO codes as for locales, but is it
 en-us, en_US or something?

The latter.  Grepping through the ebuilds for LINGUAS shows that 
it checks in some places for codes like pt_BR and zh_CN.  So the 
original poster could use LINGUAS=fr en en_US.

Benno
-- 
gentoo-user@gentoo.org mailing list